Can I update labels on a container using docker-compose without restarting the container?
Ideal scenario:
- change labels in docker-compose.yml
- save docker-compose.yml
- run a command to update the labels without restarting the container
As a general rule, changing the settings or code running inside a container involves deleting and restarting the container. This is totally normal, and docker-compose up will do it for you when necessary. (Remember to make sure any data you care about is stored outside the container.)
At a Docker API level, there are only a limited set of things that can be changed in the Update a container call, and labels aren’t one of those. That means anything that manages a container, whether direct docker commands or Docker Compose, must always delete and recreate a container to change its labels.
Related
I'm trying to run a program called Isaac-Sim from inside of an outer docker container (called container A for reference), but Isaac-Sim already runs in its own docker container. The end goal is to modify this to use Isaac output, but for now I just need to make a basic container that can run Isaac inside of it to get started. In addition to needing access to the specific image, it also has a lot of volumes that mount files from the main OS it needs to properly work. I'm pretty unfamiliar with docker and have tried looking stuff up, but am just not quite sure where to start.
From my understanding so far, I would need to mount the volumes Isaac needs inside of container A and define the volumes for the Isaac container relative to the container A file path rather than the main OS. I would also need to make a volume in container A -v /var/run/docker.sock:/var/run/docker.sock. This should allow me to run a docker run command inside of container A and have it start a parrallel container. However, what I'm not sure of is how to get access to the actual image for the Isaac container inside of container A. It's a rather lengthy installation process, so I don't want to reinstall it on container A every time I run it, I'd rather just volumize where it already is...but I'm not quite sure where that is.
I have several loose containers, including for example a rabbitmq container, that I am using for development. I have started migrating all of these loose containers to a docker-compose file for easier management and spinning up/down when testing. Unfortunately, there is a lot of configuration in these containers that I would rather not have to spend time setting up again.
As such, I was wondering if it was possible to adopt a docker container into a new docker-compose file.
I tried starting the compose file with just using the same name as the loose container, but I get cannot create container for service rabbitmq: Conflict. The container name "/rabbitmq" is already in use by container "<ID>". You have to remove (or rename) that container to be able to reuse that name
If you expect that when you run "docker compose" it will not start a new container if there is one already running with that name and it will just reuse that, it doesn't work that way.
You should define any configurations that you used when running the stand-alone container in your docker-compose file.
I want to update the docker-compose.yml file for a service of mine to change restart: "no" for restart: unless-stopped.
I used restart: "no" originally to debug the container, but now it's working I had data that I don't won't to erase; so I would like to edit the docker-compose.yml file to keep the change reflected in it (for future reference) and apply the change.
Can I just stop the container without removing it and then apply a docker-compose up? Or docker-compose up is only meant for "fresh created" containers and I have to use another docker command after editing docker-compose.yml?
Deleting and recreating containers is extremely routine, and there are many settings you can only change by deleting and recreating a container. If nothing else you'll have to delete and recreate a container to update the image it runs on, when there is inevitably a bug fix or security update.
You should reconfigure your container to use some sort of volume, either a named volume or a bind mount, to hold your application data. Anything that's not in a volume will get lost.
For this particular change, it looks like the docker container update command can modify the restart policy. You'll have to find the Docker name of the container from docker ps, it will be named something like directory_service_1. But you can't use this command to change the image, environment variables, command, port mappings, or volume mounts; changing any of these things requires deleting and recreating the container.
I use docker-compose to start a set of unrelated docker containers. I use docker-compose for that because of the ease of configuration via docker-compose.yaml and the centralized configuration this file brings.
One problem I have is the update of images, or actually of containers after an image update. I update them via docker-compose pull but the containers previously spawned do not restart by themselves. I have two possible solutions, both doable but none ideal:
restart all the containers after a pull. This would introduce unavailability which is not a critical thing in my home environment but still (especially Home Assistant restarting is a pain as the lights are reset)
write some code to check which images IDs have changed during the pull and restart the relevant containers (removing them first). This is the solution I will be using if there is nothing better.
I was wondering if there was a better soution.
This is a home environment so I would like to avoid heavy duty solutions such as Kubernetes.
Swarm mode could work but I just read about it and it looks more like a solution to ensure state more than a containers manager (in the sense that it would restart containers based on the freshness of the image they were spawned from).
After you docker pull image, docker-compose -f "docker-compose.yml" up -d will only restart the containers for which there is a new version of the image after the docker pull. It will not impact the containers whose image stays the same. This setup works fine for me.
docker-compose up --force-recreate -d
if there are existing containers for a service, and the service’s
configuration or image was changed after the container’s creation,
docker-compose up picks up the changes by stopping and recreating the
containers (preserving mounted volumes). To prevent Compose from
picking up changes, use the --no-recreate flag.
If you want to force Compose to stop and recreate all containers, use
the --force-recreate flag.
docker-compose up -CLI
NOTE:Recreate containers even if their configuration and image haven't changed.
Trying to make sure I understand the proper usage of docker volumes. If I have a container running MongoDB that I plan to start and stop do I need a volume configured with I "docker run" the first time? My understanding is that if use Docker run once, then docker stop/start my data is saved inside the container. The volume is more useful if multiple containers want access to the data. Is that accurate or am I misunderstanding something?
Starting and stopping a container will not delete the container specific data. However, you upgrade containers by replacing them with new containers. Any changes to the container specific read/write layer will be lost when that happens, and the new container will go back to it's initial state. If there are files inside your container that you want to preserve when the container is replaced, then you need to store those files in a volume, and then mount that same volume in the new container.