Instead of typing two commands (to stop and prune), you can force a stop/remove with a single command: podman rm -f webserver. Also, usually it's "podman stop container; podman rm container", prune is not advisable especially if you're working with other containers.
Thanks for the video. I personally prefer to run Podman in RHEL family distros (Fedora,RHEL,Rocky). They have podman-restart service which starts containers with the flag "restart: always" on reboot. They also have cockpit gui with podman.socket integration for management of pods and containers. Podman-compose and portainer works fine as well. For keeping containers up to date I use watchtower.
Yeah, that makes sense IBM is behind a lot of these things, which I still find surprising First time I came across them was to do with mainframes Last time it was a san Anyway, I'm going to hand this all over to Ansible...now who makes that again?
It's worth noting that the version of Podman you installed is a bit older (I also use Debian, so it's the version I'm on also) and in newer versions, Podman has replaced the systemd unit files with "quadlets" instead (you can still use the old way I think), which is a different way of writing the service files. You still use systemd to manage the containers, it's just a different file format that is easier to work with. I've begun replacing Docker with podman in my local environment, and have had no issues so far.
Thanks for sharing this, that looks to be a more useful method I stuck with a compose file to run everything as I got quite used to it and it would make it easier to migrate what I've already done in Docker But I've noticed that compose doesn't seem to be a preference for Podman, so I might have to move away from this at some point I am planning to hand this all over to Ansible, and these container files are more or less what I was going to do for building the compose file So this looks to be a better strategy
Well when I was first made aware of quadlets, I looked at a Red Hat web page which said it needed root access, so that put me off In which case, I used a rootless service account and compose file as I was already using compose for Docker Compose files can get quite large though so I handed that off to Ansible I now have one playbook which creates VMs, another installs and initialises Podman into a VM and another one manages the compose file and updates the containers So once Podman is up and running, I create a new service and volume file for a container and then run the maintenance playbook. It will generate a new compose file, upload it and shortly after the new container will be spun up If the config of an existing container needs changing, I'll update its config file(s) on the Ansible computer and the run that same playbook to push the change out and restart the container It works fine, but different service accounts for each container does seem to be the better strategy
I don't use Ubuntu but Podman may no longer be available for it The installation instructions mention Ubuntu, but I came across this askubuntu.com/questions/1498558/install-podman-on-ubuntu-20-04
I'm surprised how out of date it is I didn't realise until I recently wanted to customise the networking using 5.x features It's odd because the documentation says to use the repository
Instead of typing two commands (to stop and prune), you can force a stop/remove with a single command: podman rm -f webserver. Also, usually it's "podman stop container; podman rm container", prune is not advisable especially if you're working with other containers.
Thanks for sharing
Great explained 👍 Good examples ❤ Thank you
Appreciate the feedback and good to know the video was useful
Thanks for the video. I personally prefer to run Podman in RHEL family distros (Fedora,RHEL,Rocky). They have podman-restart service which starts containers with the flag "restart: always" on reboot. They also have cockpit gui with podman.socket integration for management of pods and containers. Podman-compose and portainer works fine as well. For keeping containers up to date I use watchtower.
Yeah, that makes sense
IBM is behind a lot of these things, which I still find surprising
First time I came across them was to do with mainframes
Last time it was a san
Anyway, I'm going to hand this all over to Ansible...now who makes that again?
It's worth noting that the version of Podman you installed is a bit older (I also use Debian, so it's the version I'm on also) and in newer versions, Podman has replaced the systemd unit files with "quadlets" instead (you can still use the old way I think), which is a different way of writing the service files. You still use systemd to manage the containers, it's just a different file format that is easier to work with.
I've begun replacing Docker with podman in my local environment, and have had no issues so far.
Thanks for sharing this, that looks to be a more useful method
I stuck with a compose file to run everything as I got quite used to it and it would make it easier to migrate what I've already done in Docker
But I've noticed that compose doesn't seem to be a preference for Podman, so I might have to move away from this at some point
I am planning to hand this all over to Ansible, and these container files are more or less what I was going to do for building the compose file
So this looks to be a better strategy
Fantastic content mate. Love your stuff.
Thanks and good to know the videos are useful
it's really a wonderful tutorial
Good to hear the video was helpful
as usual - perfect guide - thx
Thanks for taking the time to comment, always appreciated
FYI podman way is to use 'Containerfile' in place of 'Dockerfile'
That's one of the appeals of Podman, you can still use the names used with Docker
It actually makes it easier to migrate from Docker to Podman
Any reason for not using podman quadlet
Well when I was first made aware of quadlets, I looked at a Red Hat web page which said it needed root access, so that put me off
In which case, I used a rootless service account and compose file as I was already using compose for Docker
Compose files can get quite large though so I handed that off to Ansible
I now have one playbook which creates VMs, another installs and initialises Podman into a VM and another one manages the compose file and updates the containers
So once Podman is up and running, I create a new service and volume file for a container and then run the maintenance playbook. It will generate a new compose file, upload it and shortly after the new container will be spun up
If the config of an existing container needs changing, I'll update its config file(s) on the Ansible computer and the run that same playbook to push the change out and restart the container
It works fine, but different service accounts for each container does seem to be the better strategy
i use ubuntu, podman-compose not found or installable with apt
I don't use Ubuntu but Podman may no longer be available for it
The installation instructions mention Ubuntu, but I came across this
askubuntu.com/questions/1498558/install-podman-on-ubuntu-20-04
Podman is so much bother on Ubuntu due to out of date version in repository that I prefer to use Incus.
I'm surprised how out of date it is
I didn't realise until I recently wanted to customise the networking using 5.x features
It's odd because the documentation says to use the repository
+1