Having decided on a RedHat based distro for my new home server, I was originally decided on using RockyLinux. When CentOS Stream 9 came out however, and having softened up on the idea behind CentOS Stream, I decided to give it a try.
It wasn't all moonlight and roses though. My first attempt at installing CentOS Stream 9 was a failure apparantly because I had only allocated 500MiB to the /boot partition. The error wasn't very helpful:
DNF error: Error in POSTTRANS scriptlet in rpm package kernel-core
After upping that to 1GiB the installation went smoothly and the system booted with no issues. My first impressions were actually very good. Time to enable Cockpit:
sudo systemctl enable --now cockpit.socket
Cockpit offers a neat GUI for firewalld. Using that, I added the ethernet adapter to a "home" zone which automatically created allow rules for incoming connections to both Cockpit at port 9090 and SSH at port 22.
Now it was time to move my new server into the storage room, where it would sit headless, and connect it by an ethernet cable to the switch. Back at my laptop, I notice that it isn't being issued an IP address and not popping up on the topology map. Apparantly, I had to specifically tell the network adapter to "Connect automatically".
After these few hickups I was all set. Now I just had to move my docker-compose files to the new server and fire them up!
At the time of this writing, CentOS Stream 9 has only been out for just over 2 weeks and the Docker repositories have no packages for CentOS Stream 9. My first thought was to brute force install the Fedora 34 rpm's but I soon found myself in dependency problems. The package libcgroup was not available and the Fedora one wanted to replace some already existing file. That's when I came across Podman - thanks to the nice folks on the #centos-stream IRC channel.
I'll have to admit I had never heard of Podman before, either that or I had not bothered to memorize it. Turns out, Podman serves the same purpose. And if you create a docker alias for it you might not even notice that you are running a different tool. Apparantly, you can use docker-compose with Podman! A nice cherry on the top is that you can manage your Podman containers from within Cockpit. Sounds good and I can't wait to try!
Let's make an alias, just for fun.
alias docker=podman
On my system, Podman was already installed. For using docker-compose however, I had to yum install two packages; podman-docker and docker-compose. The first installed without issues while the latter does not exist in the CentOS Stream 9 repositories. Again, there was also no rpm available but since docker-compose is pretty much just a Python script I figured it would not be a big harm in using the Fedora 34 package. However, it came with some Python dependency issues that I didn't want to wrangle. Luckily, you can download prepared binaries from the docker-compose Github page.
An elegant solution is to download it directly to /usr/bin (if you install it to /usr/local/bin it won't be available using sudo):
sudo curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/bin/docker-compose
sudo chmod +x /usr/bin/docker-compose
At first I downloaded the latest version, 2.2.2 but it turned out it has some issues with Podman. The error message I got was:
Error response from daemon: fill out specgen: /data: duplicate mount destination
It seems that the issue was that the specific Docker I wanted to run had the same volume defined in two separate places. Docker doesn't seem to mind that but Podman is more strict with how containers are defined and considers this an error. While technically it is, this behavior is also a bit nit-picky. For some reason the older version of docker-compose works.
Having everything set up and ready to go I was eager to try some examples. Following the Using Podman and Docker Compose blog post from the RedHat blog I pulled the awesome-compose Github repository and cd'd into the gitea-postgres directory.
git pull https://github.com/docker/awesome-compose.git
cd awesome-compose/gitea-postgres
I issue the magic command ...
sudo docker-compose up
... but no, I get a weird error:
Error response from daemon: failed to resolve image name: short-name resolution enforced but cannot prompt without a TTY
What on earth does that mean? Well, turns out that the docker-compose.yaml file defines the container images using what is called a "short-name":
services:
gitea:
image: gitea/gitea:latest
...
db:
image: postgres:alpine
...
When Docker sees these short-names it automatically assumes that you want to download them from the Docker.io registry and prepends a docker.io/ to the image url. Podman however aims to be impartial to which registry you get your image from and instead wants you to specify the full url to the image you want. This seems to be partly for security reasons but also partly for political reasons. I understand the reasoning but it sure is a nuisance.
In Podman 3.4, which I am running, Podman seems to be slightly permissive with this however. It attempts to automatically find the image you request from a number of registries but since it is impartial to which registry you download from, it will prompt you to select a registry when the same image is found in more than one registry. When calling Podman within a script, as is the case with docker-compose, Podman is unable to prompt with a registry selector and returns this error. Apparantly, this behavior is to be fixed with Podman 4.0 but for now a workaround is required.
My first attempt was to specify a full image URL in the docker-compose.yaml file - but that didn't work, possibly because I was using a >2.0 version of docker-compose.
Podman 3.0 and above however has a way to go around this issue. If you manually pull a docker image and answer the prompt for which registry you want to pull the image from, Podman will store your choice for later in a config file:
$HOME/.config/containers/short-name-aliases.conf
If you run your container as sudo, make sure you pull the images as sudo too. An alternative is to use a registries.conf file. Both of these approaches are described in this article on the RedHat website. Additionally, there is work in progress to make a general registries.conf file with some commonly used shortnames.
My approach was quick and dirty though. I pulled the images manually as sudo and selected the docker.io repositories for both.
sudo podman pull gitea/gitea:latest
sudo podman pull postgres:alpine
Afterwards, I was able to run the containers successfully!
sudo docker-compose up
What about
dnf install podman-compose?