I don't know about internals so it may not apply but regarding the use case I described briefly, I know what pod to update and what new image to use. Also, the image is available at the time the update must be performed.
Taking Kubernetes as an example [1], from a CLI point of view, I would see something like this:
> podman rolling-update PODNAME --image=IMAGE:TAG
The main point is about updating the service/pod without an outage.
Le mar. 4 févr. 2020 à 14:46, Daniel Walsh <dwalsh@redhat.com> a écrit :
On 2/4/20 7:28 AM, Laurent Pellegrino
wrote:
Thanks for the information.
Just to understand, why are you considering a periodic job?
We don't know when the image that the container is based on will be
updated. So checking once a day seems like a reasonable thing to
do. How else would you suggest we do this?
> This however would not maintain the the connections.
OK, so for now, the only solution seems to deploy a proxy
that supports dynamic configurations with no restarts?
Le lun. 3 févr. 2020 à 19:28,
Daniel Walsh <dwalsh@redhat.com> a écrit :
On
2/1/20 3:28 AM, laurent.pellegrino@gmail.com
wrote:
> 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
> _______________________________________________
> Podman mailing list -- podman@lists.podman.io
> To unsubscribe send an email to podman-leave@lists.podman.io
We are actually investigating this workflow. But have not
taken as far
as you want. The idea would be to be running a container, and
then have
a job start periodically that would see if their was an update
to the
image that the container was running on. It would pull the
image down
and restart the container service, which would destroy the old
container
and create a new container with the same params. This however
would not
maintain the the connections.
_______________________________________________
Podman mailing list -- podman@lists.podman.io
To unsubscribe send an email to podman-leave@lists.podman.io