This will be a really short talk, just in minutes to take your attention, not much.
And it's going to be an easy thing that probably some people already do, but I'm not like a
container, I'm not the man when talking about containers.
So what I think that this is kind of an interesting thing for all the people that like me, try
to play with containers with home setup mostly.
So the motivation for this talk is basically that I have like a server and I am experimenting
with rootless containers at home.
So I am trying with automating with Ansible, which is not an overkill, I even copy my .files
with Ansible just because, you know.
And then I like to learn by breaking stuff.
So why don't you break stuff at home?
So this talk is about, again, my personal setup.
I will share all the code later on, but just to meet my home server, it's called Morla.
Does anybody know who Morla is?
321 Morla is this, beautiful creatures.
And it really resembles my...
There's a problem with your slides.
Oh my God.
Maybe you can just reconnect it.
Let's go.
It's not that I only have Morla.
Yeah.
It's so...
And it's...
It remembers everything.
It's like a NAS.
I store all the things there.
It's heavy and dusty like my home and it's a turtle like my home server, which is not
a turtle, but whatever.
So first setup, I used Portainer and Docker Compose.
It's really convenient, but it had some issues that I'm discussing right now.
If you use Portainer, Docker Compose, you're my friend, but I just don't use it anymore.
And why is that?
Well, it's easy to install on some machines like on OpenMediaVault, which I was running
before.
It's rootless.
Well, I don't know if it's rootless right now, but it wasn't at the time.
It only supported Docker and I didn't like to give all the root privileges around and
it's heavily dependent on GUI.
So these are the three things that I will try to resolve with just using Podman and Ansible.
And so this is Portainer, if you don't know.
Again, very convenient, but also I don't need this GUI.
And Linux server images, if you're familiar with them, they're really simple and they
all have this kind of workaround for running some services that you're not supposed to
run as root inside the container because, I mean, you're not really sure that things
can get out of the container.
So just to work around this, they implement this feature that you just specify your UAD
and your GAD inside the container and that when you run it as root, you're good to go
because outside you will have that user.
But that's not the case with Podman, right?
So yeah, this is what happens with Podman.
Basically if you run that configuration, this is for Pwigo, it's for sharing pictures.
I want to be able to mount my volumes in the container using the same users, like outside.
I don't want to have some weird mapping of namespacing because then it will be inconvenient
if I just drop stuff in and out.
So again, this would be really easy to solve if you just run inside stuff with root, but
again, it's not, again, the case for all the images.
So what you could do is, of course, to just run, like if you want to touch a file in some
volume that you configured, it will give you permission tonight.
So you just do Podman and share, you do what you have to do and then you have your file
there.
For me, again, it's inconvenient because I store their media files and I just want to
drag them in and out quickly and I don't want to just do unshare all the time.
So again, this is what we are facing.
Basically the red part is what we care.
So when we have a non-privileged user outside and a non-privileged user inside, to make
it clear when you run any command, the un-privileged user inside will be remapped.
I'm not sure that, like, I am not that familiar to talk about it.
So this was just to explain myself how things work.
So to make it even more clear, user inside and user outside not privileged, when you
see the process of the user, you will see that outside you will have somebody.
It's like 1-0-0-9-8.
I don't know who you are.
It's, well, if you don't have to manage stuff, it works, but if you want to take stuff in
and out, then you have to deal with that.
So what do you do?
This is what you do.
And this is why I call it, like, juggling.
Because basically the way Podman works in root and non-root management, it allows you to
remap the user IDs and the GIDs.
So both works for groups and users inside and outside the container.
And it's kind of complicated-ish syntax.
But what basically happens is that you want to take the UID that you are running in the
container.
It could be, like, whatever UID, like a fake UID, they even call it, and you basically
remap it on the host.
So now comes the reason why I did this presentation, which is juggling.
And as you see, you have to run this command three times, because you're dealing with a
user ID inside the container with a fake user ID and a user ID outside the container that
you really want to map to one another the correct way.
So there we go.
Let's run the first command.
OK.
You don't get lost.
This is faster than the I. You can bet now on where's the UID now.
You couldn't have guessed.
OK.
But anyway, back to serious stuff.
The real example is this one.
I am running all my Linux server images with a fake user ID, which is 911, because help
me in case of...
911 is the fake user ID that goes inside and actually want to fake it, like if root
is running inside.
It's the same result that I want to obtain.
So that outside I actually have my normal user ID.
If you actually check into the container in the UID map, which is where actually the UIDs
are defined, how they are mapped inside and outside, you will see that it's taking my
ranges, as I'm specifying.
Please don't ask me much details about it.
We don't have time, but we'll talk about it later.
And then the result is that when you mount stuff, you have it configured for your user.
And there's another convenient option, but I don't have it on my server.
If you just do one command, it's easier, but I don't use it in my server, so you can either
shuffle or just use this one liner, and it will do just fine.
OK.
And then about Ansible.
So running this command all the time is quite inconvenient if you have many, many containers,
it's hard to maintain or it's a lot of scripting.
And plus, I think that Ansible goes really well with Podman containers because first,
the model is great.
And second, it really enables you to have much more control on, for example, config files,
templates that you need to put in the container when you boot it, and whatsoever.
And what I do with Ansible, and I advise you to take a look if you've ever tried, but
it's kind of cool.
You can have your configuration and just store everything in what's in the main configuration
file that will store all the necessary variables, like parts to expose, volumes to mount, all
the users that you want to shuffle with, whatever.
And then you can basically copy paste what's a generic container configuration or setup
if you do things right.
Let's take a look, for example, this is, again, the same configuration.
OK, I just kind of find what's the main name of the container, what I want to be the display
name, where to pull the image from, parts, a database, for example, because I'm running
pods with that.
And it's basically all just copy paste as you were doing with Docker Compose images,
but this way you're actually controlling much more what's happening because you can
also control configuration files, setup, mounting stuff here and there and whatsoever, you name
it.
And of course, well, this I was highlighting random stuff in case you're interested.
Yeah, this is the volume configuration.
Don't forget to put the capital Z if you are in an IC Linux environment, of course.
And let's go to the setup now.
So this is my control panel, by the way, it's really convenient.
It's like container.
You can just specify variables to say, run this, this, this and that container, and it's
all finally replaced the name, and it will just work.
So it's just simpler, in my opinion.
And then I think if I lost, oh, yeah, I wanted to show you the setup as well.
So no more scripting, right?
If I need to create a config directory, I can just create it with Ansible, right?
And it's really nice that also the container creation, this is the same shuffling that
we did before.
So the fake ID shuffles with IDs 0 and range 1 and et cetera, et cetera.
And this is all predefined in all the setup files that Ansible can provide you.
So I'll just finish up because I have a few minutes.
Oh, this is also very convenient for containers.
If you're booting many, many containers with Ansible, never did that.
It's good because it will just say, OK, things are good.
This thing, I don't need to check it because it's already there.
Again, it was a big thing for me.
You may be familiar with that, but if you're not, try it out.
And in the end, no mistakes.
Of course, I'm also not doing a demo because it would break.
And very quickly, tags are also great to manage containers.
I think they really go very well.
You can just say, set up this, this, and that and tag all the files that you need.
And then we just go up.
Takeaways, go rootless, automate the stuff, and try to overcomplicate things at all times
to oversimplify things.
Thank you.
That is my presentation.
If you want to.