8:04 a.m.
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.
[1]
https://kubernetes.io/docs/tasks/run-application/rolling-update-replicati...
Le mar. 4 févr. 2020 à 14:46, Daniel Walsh <dwalsh(a)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(a)redhat.com> a écrit :
> On 2/1/20 3:28 AM, laurent.pellegrino(a)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(a)lists.podman.io
> > To unsubscribe send an email to podman-leave(a)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(a)lists.podman.io
> To unsubscribe send an email to podman-leave(a)lists.podman.io
>
_______________________________________________
Podman mailing list -- podman(a)lists.podman.io
To unsubscribe send an email to podman-leave(a)lists.podman.io
_______________________________________________
Podman mailing list -- podman(a)lists.podman.io
To unsubscribe send an email to podman-leave(a)lists.podman.io