9:12 a.m.
On 2/4/20 9:04 AM, Laurent Pellegrino wrote:
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
Sure but you could script up the same thing.
podman pull images related to pod.
Then stop/destroy the pod/containers. Recreate the pod/containers.
I am not against your idea, but it brings in the Human element, I want
to automate this process which is why I suggested a cron job.
In your case the admin needs to realize that one of the containers in
the Pod uses an image that has been updated, and now triggers the service.
I would prefer to just have the system figure out whether an update is
needed.
The main point is about updating the service/pod without an outage.
[1] https://kubernetes.io/docs/tasks/run-application/rolling-update-replication-controller/#updating-the-container-image
Le mar. 4 févr. 2020 à 14:46, Daniel Walsh <dwalsh(a)redhat.com
<mailto: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(a)redhat.com
> <mailto:dwalsh@redhat.com>> a écrit :
>
> On 2/1/20 3:28 AM, laurent.pellegrino(a)gmail.com
> <mailto: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(a)lists.podman.io
> <mailto:podman@lists.podman.io>
> > To unsubscribe send an email to
> podman-leave(a)lists.podman.io
> <mailto: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(a)lists.podman.io
> <mailto:podman@lists.podman.io>
> To unsubscribe send an email to podman-leave(a)lists.podman.io
> <mailto:podman-leave@lists.podman.io>
>
>
> _______________________________________________
> Podman mailing list -- podman(a)lists.podman.io
<mailto:podman@lists.podman.io>
> To unsubscribe send an email to podman-leave(a)lists.podman.io
<mailto:podman-leave@lists.podman.io>
_______________________________________________
Podman mailing list -- podman(a)lists.podman.io
<mailto:podman@lists.podman.io>
To unsubscribe send an email to podman-leave(a)lists.podman.io
<mailto:podman-leave@lists.podman.io>