- Podman - Podman List Archives

Re: Please give feedback on: Add support to auto-update containers running in systemd units as
by Karl Quinsland 14 Mar '20

14 Mar '20

I am of two minds on this. I am happy to see the functionality come to podman, but am concerned that there's no way to make this feature robust enough for all but the simplest of use cases without sinking a *ton* of time into it. Tl;DR: "reload this service when there's a new version" is a lot more complicated than it appears unless the service in question is low stakes or otherwise purposefully designed to be highly stateless and all consumers of the service are equally well equipped to deal with a service that may suddenly speak a slightly updated version of the protocol... etc. If this is a feature that is in demand, then please do keep building it! As implemented now, I can think of a few common scenarios where it will be immediately useful, but beyond them, I see quite a few things that'll need to be added to make it useful in more sophisticated/legacy environments. I would use this auto-update functionality on a few containers that I deploy around the house because those containers all run on systemd hosts and the workloads that the containers have is not sensitive to (slightly) out of date containers. Nor is a manual rollback of any container the end of the world. I can't use this at work, though because various workloads have elaborate gates around their rollout or otherwise need to be rolled out as soon as a new release is available... not (up to) 24h later. --- I've implemented something similar internally that does not suffer from some of the same drawbacks. It's is quite a bit more flexible, but at the cost of some additional overhead/infrastructure. Chiefly: - Would work with any init system that supports some form of "additional configuration" faculty. In my case, though, we're primarily - but not exclusively - a systemd shop. - Is not limited to daily checks for updates. Within seconds of the "switch being flipped" - so to speak - the new version of the container can be running. - Supports rollbacks and other release gates Internally, we use the *excelent* Consul Key/Value storage system to manage which workloads use which versions of a container, but any key/value storage system that allows a daemon to monitor or 'learn' about a change to a value for a given key will work. That is: I use consul to pull this off, you could absolutely make EtcD or ZooKeeper work here, too. Through a process that's not relevant here, a key/value path is updated. E.G.: path: /service/in-field-c/version value: 1.28 where in-field-hardware-controller is an illustrative example, as is the value stored @ that key. On every container host, there's a daemon that watches the /service/in-field-hardware-controller/version path in consul. Depending on the workload, we use the simple but powerful consul-template program or a more sophisticated internal daemon. Consul-Template is a small golang based binary that can be run as a daemon to watch a specific consul key, but the consul API is open and there are a variety of daemons out there that support monitoring a given path. The critical bit here is that the daemon has the ability to execute system commands when a change is observed: When the monitoring daemon notices a change to the value @ the key, it renders out a file that is then read by systemd and "exposed" to the ExecStart= directive as an environment variable. The file that is rendered out would be placed in: /etc/systemd/systemd/in-field-hardware-controller.service.d/10-version.conf and would look like this: [Service] Environment=WORKLOAD_IMAGE_VERSION=1.28 The daemon that writes out the file then consults some internal logic to see when to *apply* this change. In simple cases, the daemon (consul-template) will immediately run systemctl daemon-reload; systemctl restart hardware-controller.service which will immediately apply the change. In other cases, the daemon (not consul-template) will run additional scripts to sanity check other dependencies and provide additional 'gates' on the roll out. These scripts check up and down-stream dependencies, database/stateful data versions and - in some cases - require an engineer to be the "second man" (see 'two man rule' on wikipedia) in a version roll out. If the updated container does not start to publish an expected payload to a pre-defined endpoint, we consider the container to be unhealthy and consult additional internal logic about weather to revert or exponentially backoff on the restart attempts. The portion of the hardware-controller.service file that plugs the env-var into the run command looks like this ExecStart=/usr/bin/podman run --name=hardware-controller <...snip...> some-registry/hw-controller:${WORKLOAD_IMAGE_VERSION} I will be the first to acknowledge that our solution has many knobs and sliders that increase the complexity of our "dynamic" version configuration setup. Some of these knobs are necessary to support features that are absolutely critical for our needs: rollouts within seconds unless additional gates and relatively painless rollbacks (where possible). For my personal/at-home workloads, those needs are not critical and so the many knobs/sliders are not needed. Happy to clarify anything! -K

3 2

Please give feedback on: Add support to auto-update containers running in systemd units as
by Daniel Walsh 12 Mar '20

12 Mar '20

We are working on a new feature of Podman that allows you to run a service within a container and then have the container automatically updated when a new image is pushed to a registry. The full description is given below. We would love to have community feedback on the ideas, and have people play with it. ``` Add support to auto-update containers running in systemd units as generated with |podman generate systemd --new|. |podman restart --auto-update| looks up container with a specified "io.containers.autoupdate" label (i.e., the auto-update policy). If the label is present and set to "image", Podman reaches out to the corresponding registry to check if the image has been updated. We consider an image to be updated if the digest in the local storage is different than the one of the remote image. If an image must be updated, Podman pulls it down and restarts the container. Note that the restarting sequence relies on systemd. At container-creation time, Podman looks up the "PODMAN_SYSTEMD_UNIT" environment variables and stores it verbatim in the container's label. This variable is now set by all systemd units generated by |podman-generate-systemd| and is set to |%n| (i.e., the name of systemd unit starting the container). This data is then being used in the auto-update sequence to instruct systemd (via DBUS) to restart the unit and hence to restart the container. Note that this implementation of auto-updates relies on systemd and requires a fully-qualified image reference to be used to create the container. This enforcement is necessary to know which image to actually check and pull. If we used an image ID, we would not know which image to check/pull anymore. Fixes: #3575 <https://github.com/containers/libpod/issues/3575> Signed-off-by: Valentin Rothberg rothberg(a)redhat.com <mailto:rothberg@redhat.com> ------------------------------------------------------------------------ https://github.com/containers/libpod/pull/5480

1 0

Podman for MacOS - Valid Approach ?
by Ezequiel Aguilar 21 Feb '20

21 Feb '20

Hello Guys, Is this a valid approach for running Podman in MacOS ? https://developers.redhat.com/blog/2020/02/12/podman-for-macos-sort-of/ It seems similar to Docker Machine, and it works well for me. Any thoughts? Regards, Ezequiel

4 6

max open files
by bryan.hepworth＠gmail.com 19 Feb '20

19 Feb '20

Hi all Some of my users have bumped up against max open files when trying to commit a container image with podman. Does anyone know where this is set in rhel 8.1? Thanks Bryan

3 4

httpd install failure
by Seth Kenlon 19 Feb '20

19 Feb '20

Since Fedora 31, I can't seem to get a web server to install successfully into an image. I get failure with Nginx and Apache, and it "feels" like the failure is probably a post-install action because the RPM gets installed by dnf, it just ends in failure: ``` $ buildah run centos-working-container-6 dnf install nginx -y Installed: [...] nginx-all-modules-1:1.14.1-9.module_el8.0.0+184+e34fea82.noarch nginx-filesystem-1:1.14.1-9.module_el8.0.0+184+e34fea82.noarch nginx-mod-http-image-filter-1:1.14.1-9.module_el8.0.0+184+e34fea82.x86_64 nginx-mod-http-perl-1:1.14.1-9.module_el8.0.0+184+e34fea82.x86_64 nginx-mod-http-xslt-filter-1:1.14.1-9.module_el8.0.0+184+e34fea82.x86_64 nginx-mod-mail-1:1.14.1-9.module_el8.0.0+184+e34fea82.x86_64 nginx-mod-stream-1:1.14.1-9.module_el8.0.0+184+e34fea82.x86_64 [...] Failed: nginx-1:1.14.1-9.module_el8.0.0+184+e34fea82.x86_64 Error: Transaction failed ``` Installing pretty much anything else works: ``` $ buildah run centos-working-container-6 dnf install lua -y [...] Installed: lua-5.3.4-11.el8.x86_64 Complete! ``` I assume I've forgotten something "obvious" whilst setting up for rootless containers, or redirecting ports, or something of that nature?

2 2

podman & pi, architecture confusion
by Brian Fallik 11 Feb '20

11 Feb '20

Hi, I've been actively following the work to package Podman for Debian for eventual installation on my raspberry pi nodes. I noticed the installation docs recommended using the Kubic project packaging and so I used that to successfully (and easily!) install podman on my raspi. Hooray! However now I'm having trouble pulling arm images. All my attempts result in amd64: # podman pull coredns/coredns:latest Trying to pull docker.io/coredns/coredns:latest... Getting image source signatures Copying blob c6568d217a00 done Copying blob 89d2da39cc12 done Copying config b52ee75a77 done Writing manifest to image destination Storing signatures b52ee75a7749dc470ec4dacf990c26733c1477371f190e2748d653b8834c3f48 # podman image inspect b52ee75a7749d | jq '.[0].Architecture' "amd64" and then again with override-arch: # podman image rm b52ee75a7749d Untagged: docker.io/coredns/coredns:latest Deleted: b52ee75a7749dc470ec4dacf990c26733c1477371f190e2748d653b8834c3f48 # podman pull --override-arch=arm coredns/coredns:latest Trying to pull docker.io/coredns/coredns:latest... Getting image source signatures Copying blob c6568d217a00 done Copying blob 89d2da39cc12 done Copying config b52ee75a77 done Writing manifest to image destination Storing signatures b52ee75a7749dc470ec4dacf990c26733c1477371f190e2748d653b8834c3f48 # podman image inspect b52ee75a7749d | jq '.[0].Architecture' "amd64" podman info: # podman version Version: 1.8.0 RemoteAPI Version: 1 Go Version: go1.11.6 OS/Arch: linux/arm Any tips on how to convince podman to pull arm images within rasbian? Thanks in advance, brian

2 5

Rolling updates with Podman
by laurent.pellegrino＠gmail.com 05 Feb '20

05 Feb '20

Hi there! I discovered Podman recently and started to use it as a great alternative to Docker. My question is about application updates. Let's say you have a pod running and you want to update the code for the app in that pod. Is there a simple manner to manage something similar to a Kubernetes rolling update? By rolling update, I mean performing an update with no service interruptions (i.e. starting a new pod running the new app version, switch the network traffic to the new pod and terminate the old pod). Kind Regards, Laurent Pellegrino

4 8

Attention any Python Fans
by Daniel Walsh 04 Feb '20

04 Feb '20

We are kicking off the Podman-py package to be used for binding against the new Podman APIV2. We basically have a skeleton at this point, but we are looking for contributions to help build out the bindings. Any contributors looking to write python code and ESPECIALLY contribute tests cases to work with the API, would be greatly appreciated. This is your chance to get in on the ground floor and start contributing. Thanks for your consideration.

1 0

Podman hanging on start, ps, and erroring out with slirp4netns on run
by Eric Gustavsson 03 Feb '20

03 Feb '20

Hi all, I have unit file generated by podman running, though as soon as I run it there's issues with running any other command that needs to do something with containers. podman ps for example will be completely unresponsive and not return anything, even after waiting minutes. Not only that, but even running podman start x by itself will hang or creating new containers This is with Fedora 30 and Kernel 5.1.8-300.fc30.x86_64 spytec@KeyraGuest1:~$ podman --version podman version 1.7.0 spytec@KeyraGuest1:~$ podman start bitwarden -a ^C spytec@KeyraGuest1:~$ sudo systemctl start bitwarden ^C spytec@KeyraGuest1:~$ sudo systemctl status bitwarden [... output omitted...] Jan 31 13:53:14 KeyraGuest1 systemd[1]: Starting Podman container-bitwarden.service... spytec@KeyraGuest1:~$ sudo systemctl stop bitwarden spytec@KeyraGuest1:~$ podman ps ^C spytec@KeyraGuest1:~$ ps auxww | grep podman spytec 1097 0.0 0.8 62816 33808 ? S 13:52 0:00 podman spytec 1171 0.0 1.3 681944 55064 ? Ssl 13:53 0:00 /usr/bin/podman start bitwarden spytec 1178 0.0 1.4 755824 56680 ? Sl 13:53 0:00 /usr/bin/podman start bitwarden spytec 1224 0.0 0.0 9360 880 pts/0 S+ 13:54 0:00 grep --color=auto podman spytec@KeyraGuest1:~$ journalctl -u bitwarden | tail -n 5 Jan 31 13:51:50 KeyraGuest1 systemd[1]: bitwarden.service: Failed with result 'exit-code'. Jan 31 13:51:50 KeyraGuest1 systemd[1]: Failed to start Podman container-bitwarden.service. Jan 31 13:53:14 KeyraGuest1 systemd[1]: Starting Podman container-bitwarden.service... Jan 31 13:54:26 KeyraGuest1 systemd[1]: bitwarden.service: Succeeded. Jan 31 13:54:26 KeyraGuest1 systemd[1]: Stopped Podman container-bitwarden.service. spytec@KeyraGuest1:~$ ps auxww | grep podman spytec 1097 0.0 0.8 62816 33808 ? S 13:52 0:00 podman spytec 1171 0.0 1.3 682008 55064 ? Ssl 13:53 0:00 /usr/bin/podman start bitwarden spytec 1178 0.0 1.4 755824 56680 ? Sl 13:53 0:00 /usr/bin/podman start bitwarden spytec 1235 0.0 0.0 9360 816 pts/0 S+ 13:55 0:00 grep --color=auto podman spytec@KeyraGuest1:~$ kill 1181 spytec@KeyraGuest1:~$ kill 1097 spytec@KeyraGuest1:~$ podman ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES baa2f3d6ed39 docker.io/bitwardenrs/server:latest /bitwarden_rs 3 weeks ago Created 0.0.0.0:8080->8080/tcp bitwarden And creating a whole new container spytec@KeyraGuest1:~$ podman run -d --name test postgres Trying to pull docker.io/library/postgres... [... output omitted...] Writing manifest to image destination Storing signatures Error: slirp4netns failed: "/usr/bin/slirp4netns: unrecognized option '--netns-type=path'\nUsage: /usr/bin/slirp4netns [OPTION]... PID TAPNAME\nUser-mode networking for unprivileged network namespaces.\n\n-c, --configure bring up the interface\n-e, --exit-fd=FD specify the FD for terminating slirp4netns\n-r, --ready-fd=FD specify the FD to write to when the network is configured\n-m, --mtu=MTU specify MTU (default=1500, max=65521)\n--cidr=CIDR specify network address CIDR (default=10.0.2.0/24)\n--disable-host-loopback prohibit connecting to 127.0.0.1:* on the host namespace\n-a, --api-socket=PATH specify API socket path\n-6, --enable-ipv6 enable IPv6 (experimental)\n-h, --help show this help and exit\n-v, --version show version and exit\n" Thanks, Eric Gustavsson, RHCSA He/Him/His Software Engineer Red Hat <https://www.redhat.com> IM: Telegram: @SpyTec E1FE 044A E0DE 127D CBCA E7C7 BD1B 8DF2 C5A1 5384 <https://www.redhat.com>

3 8

Re: podman upgrade from 1.4 to 1.7 on Redhat 7.7
by James Cassell 01 Feb '20

01 Feb '20

The packages shipped by Red Hat tend to lag the latest upstream version, almost by design. Last I checked, 1.4.4 was the latest available in RHEL 7. V/r, James Cassell On Sat, Feb 1, 2020, at 9:46 AM, José Osorio R. wrote: > > Hello All, > > I'm struggling to upgrade the podman version I installed in Redhat > 7.7, whici is 1.4. > > Is there a way to upgrade it? I can not find the latest rpm for redhat. > > Thanks > > > Regards > > Jose Osorio > _______________________________________________ > Podman mailing list -- podman(a)lists.podman.io > To unsubscribe send an email to podman-leave(a)lists.podman.io >

1 0