Over the weekend I decided it was time to test the in-place upgrade on my Fedora 31 webserver to migrate over to Fedora 32. The process for in-place upgrades on Fedora is a fairly straightforward process and has been flawless ( at least in my experience) over the last few years.
If you are thinking about kicking the tires on the new Fedora check out the quick tutorial over at Fedora Magazine to learn how easy it is to perform the upgrade.
Moving this site to containers! – with Podman
I’m a long time container skeptic – I don’t understand exactly what problem I’m supposed to solve with containers, and I feel like they add a lot of complexity to systems that should be fairly simple. But maybe my suspicions are wrong, and I just don’t understand them very well.
In this case I guess the problem I am solving is my own ignorance around container ecosystems, and I have no doubt that my real job will require some container knowledge fairly soon, and I don’t want to get left behind.
It’s definitely true that I don’t understand containers very well. At least not at a practical level and not to the extent that I should understand them. In that regard there is no better way to learn than by doing, so I’ve taken the first baby steps toward moving this site into containers. I’ll update the blog as I go, passing along anything I learn along the way.
I’ve been using a recent post from @fatherlinux about how he migrated his WordPress installation to containers using Podman. The rough guide for how I will do my migration is from his article in “Crunch Tools” found here: http://crunchtools.com/moving-linux-services-to-containers/.
My migration plan is a bit different from his, as I intend to separate the database from the web server, and I’ll need to figure out how to incorporate letsencrypt into an Nginx reverse proxy. I actually host multiple websites, not all of which are mine. They will all need to be accessible on port 80 and 443 so I don’t have the luxury of choosing random ports to forward traffic to. – Luckily I personally know the people who I host sites for, and they don’t usually mind if I want to tinker with things.
Why podman instead of Docker, or LXC, or whatever your favorite container platform is? I chose to use Podman as my container engine or container tool or container something simply because it is the new native container tool that is provided by Red Hat. I have a weird neurosis where I feel that a tool provided natively with an OS always appears to be better than a comparative third-party tool, like Docker. I’m not saying that I’m always right about that, but it’s something that I can’t seem to shake. I figure if Red Hat is willing to provide it and stand behind it, then I should probably learn it. That is really all there is to it.
A rough outline of my plans as of now.
Right now I have a phased approach to moving this site into containers.
- Move the database for this WordPress site into a container.
- Hammer out the steps to build the database automagically and create a Containerfile/script to redeploy with minimal effort.
- Plan web server space.
- nginx reverse proxy with certbot.
- build templates for each web site vhost to be in apache container.
- Create systemd unit files for each container.
- Spend some time doubting myself.
- Cut over – Probably some major downtime.
- Start plotting how to move the containers into “pods” using the podman toolkit.
How’s the migration going so far?
After the upgrade to Fedora 32, and doing my normal validation after an upgrade (Did the home page and the admin page load? – Yep, time to celebrate my victory!), I went ahead and installed Podman and started reading the man pages.
Right away I ran into a bit of a problem just trying to run the base fedora image from https://registry.fedoraproject.org. After building a basic image with MariaDB and trying to run the container I hit a snag with what I thought was a permissions issue. One of my goals in this project is to run the whole operation with non-root, unprivileged containers.
The error I was struggling with for a while was this:
Failed to create /init.scope control group: Permission denied Failed to allocate manager object: Permission denied [!!!!!!] Failed to allocate manager object. Exiting PID 1…
As it turns out this is an SELinux induced message, I found a good Red Hat KB that pointed me to flipping a SELinux Bool called “container_manage_cgroup”: – I don’t know what this bool does at the moment, but it appears you have to change it to true if you want to run a container that has systemd.
setsebool -P container_manage_cgroup on
After checking my audit logs I can verify that in fact this will prevent a container from starting, at least if your container has systemd installed and managing services.
So, so far so good. My next step is to plan out exactly where I want to keep my database configuration – and then how I want that to be passed into the container. If you read this site over the next week or two (or more, I’m pretty lazy) don’t be surprised if it suddenly goes down for a little while, while I work out different issues that will certainly arise in the process.
If all goes well with the database migration, then I’ll start working on the reverse proxy and apache services.
If you have any tips or suggestions please pass them on – I need all the help I can get.