[DiscordArchive] Maybe it's safer to just remove the image to force it to pull again, no?
[DiscordArchive] Maybe it's safer to just remove the image to force it to pull again, no?
Original source
Maybe it's safer to just remove the image to force it to pull again, no?
rektbyfaith
06-03-2024, 12:59 PM #1Archived author: Dakeiz • Posted: 2024-06-03T12:59:31.779000+00:00
Original source
Maybe it's safer to just remove the image to force it to pull again, no?
Original source
Apparently there's a `docker service update --force servicename` command, too
rektbyfaith
06-03-2024, 01:02 PM #2Archived author: Dakeiz • Posted: 2024-06-03T13:02:56.055000+00:00
Original source
Apparently there's a `docker service update --force servicename` command, too
Original source
I put the build in there since the modules would need to be recompiled. If you already have the images built and tagged with something specific you can refer to, yeah, that step can be skipped.
removing the image doesn't necessarily guarantee that the desired image is the one that will be deployed if the old image and the new image have the same tag. If you want to be completely sure that that the old image is being replaced by a new image, it's best to ensure they have different tags.
rektbyfaith
06-03-2024, 01:04 PM #3Archived author: mynameismeat • Posted: 2024-06-03T13:04:06.068000+00:00
Original source
I put the build in there since the modules would need to be recompiled. If you already have the images built and tagged with something specific you can refer to, yeah, that step can be skipped.
removing the image doesn't necessarily guarantee that the desired image is the one that will be deployed if the old image and the new image have the same tag. If you want to be completely sure that that the old image is being replaced by a new image, it's best to ensure they have different tags.
Original source
Would `docker service update --force` do the trick, you think?
rektbyfaith
06-03-2024, 01:08 PM #4Archived author: Dakeiz • Posted: 2024-06-03T13:08:29.637000+00:00
Original source
Would `docker service update --force` do the trick, you think?
Original source
How do you do it with K8s?
rektbyfaith
06-03-2024, 01:08 PM #5Archived author: Dakeiz • Posted: 2024-06-03T13:08:36.300000+00:00
Original source
How do you do it with K8s?
Original source
if you do not build the image and change the tag, it will not update the image. `docker service update ...` should work but you'll first need to rebuild the containers (ie `docker compose build`) so they get updated. As far as I can tell, docker swarm doesn't expose any command for rebuilding containers
I use the standard docker compose file that's in the main repo as my deployment. I moreso meant that historically I've used k8s over swarm in work/other projects. But it's the same idea - if you don't build a new image with a new tag, you can't guarantee that the new build with the new changes is going to be deployed. You still need to rebuild the container one way or another, and this is almost always explicitly another step (or done with a flag like in `docker compose up -d --build`)
rektbyfaith
06-03-2024, 01:19 PM #6Archived author: mynameismeat • Posted: 2024-06-03T13:19:54.115000+00:00
Original source
if you do not build the image and change the tag, it will not update the image. `docker service update ...` should work but you'll first need to rebuild the containers (ie `docker compose build`) so they get updated. As far as I can tell, docker swarm doesn't expose any command for rebuilding containers
I use the standard docker compose file that's in the main repo as my deployment. I moreso meant that historically I've used k8s over swarm in work/other projects. But it's the same idea - if you don't build a new image with a new tag, you can't guarantee that the new build with the new changes is going to be deployed. You still need to rebuild the container one way or another, and this is almost always explicitly another step (or done with a flag like in `docker compose up -d --build`)
Original source
I'm really unfamiliar with this part of Docker... so sorry
Is it not enough for the container to recreate itself?
rektbyfaith
06-03-2024, 01:48 PM #7Archived author: Dakeiz • Posted: 2024-06-03T13:48:34.152000+00:00
Original source
I'm really unfamiliar with this part of Docker... so sorry
Is it not enough for the container to recreate itself?
Original source
no worries, this is definitely one of the parts where it gets confusing.
a "container" is an instance of an "image". You can create many containers off of the same image, but if you update that image (code updates, usually), you would need to update all of the containers since the underlying image has changed.
rektbyfaith
06-03-2024, 01:56 PM #8Archived author: mynameismeat • Posted: 2024-06-03T13:56:38.457000+00:00
Original source
no worries, this is definitely one of the parts where it gets confusing.
a "container" is an instance of an "image". You can create many containers off of the same image, but if you update that image (code updates, usually), you would need to update all of the containers since the underlying image has changed.
Original source
kinda like how you can create a virtual machine from an image, and if you update an image, you need to redeploy the VM in some way
rektbyfaith
06-03-2024, 01:57 PM #9Archived author: mynameismeat • Posted: 2024-06-03T13:57:09.969000+00:00
Original source
kinda like how you can create a virtual machine from an image, and if you update an image, you need to redeploy the VM in some way
Original source
It needs to rebuild the image because of the changes in the modules/ directory, right?
rektbyfaith
06-03-2024, 01:58 PM #10Archived author: Dakeiz • Posted: 2024-06-03T13:58:13.599000+00:00
Original source
It needs to rebuild the image because of the changes in the modules/ directory, right?
1 Guest(s)
1 Guest(s)