0

TLDR: When using docker compose, I can simply recreate a container by changing its configuration and/or image in the docker-compose.yml file along with running docker-compose up. Is there any generic equivalent for recreating a container (to apply changes) which was created by a bare docker create/run command?

Elaborating a bit:

The associated docker compose documentation states:

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).

I'm having troubles to understand which underlaying steps are actually performed during this recreation, as e.g. the docker (without compose) documentation doesn't really seem to use the recreate term at all.

Is it safe to simply run docker container rm xy and then docker container create/run (along with passing the full and modified configuration)? Or is docker compose actually doing more under the hood?

I already found answers about applying specific configuration changes like e.g. this one about port mappings, but I'm still wondering whether there is a more general answer to this.

Johnson_145
  • 1,994
  • 1
  • 17
  • 26

3 Answers3

2

I'm having troubles to understand which underlaying steps are actually performed during this recreation, as e.g. the docker (without compose) documentation doesn't really seem to use the recreate term at all.

docker-compose is a high level tool; it performs in a single operation what would require multiple commands using the docker cli. When docker-compose says, "docker-compose up picks up the changes by stopping and recreating the containers", it means it is doing the equivalent of:

docker stop <somecontainer>
docker rm <somecontainer>
docker run ...

(Where ... represents whatever configuration is implied by the service definition in your docker-compose.yaml).

larsks
  • 277,717
  • 41
  • 399
  • 399
  • Are you sure it's that simple? I can use either or approach equivalently without missing any extra magic? – Johnson_145 May 25 '22 at 13:22
  • @Johnson_145, Docker compose is pulling the container creation arguments from the YAML file. There's no magic apart from reading the YAML. – JonShipman Dec 19 '22 at 18:39
0

Let's say it recognizes a change in container1 it does (not really, working via API):

docker compose rm -fs container1
docker compose create (--build) container1
docker compose start container1

What is partially close to (depending on your compose-config):

docker rm -f projectname_container1
(docker build --flags)
docker create --allDozensOfAttributes projectname_container1
docker start  projectname_container1
docker network connect (--flags) projectname_networkname projectname_container1
and maybe more..

so i would advise to use the docker compose commands for single services instead of docker cli if suitable..

araisch
  • 1,727
  • 4
  • 15
0

The issue is that the variables and settings are not exposed through any docker apis. It may be possible by way of connecting directly to the docker socket, parsing the variables, and then stopping/removing the container and recreating it.

This would be prone to all kinds of errors and would require lots of debugging to get these values.

What I do is to simply store my docker commands in a shell script. You can just save the command you need to run into a text file, name it .sh, set the -x on the file, then run it. Then when you stop/delete the container, you can just rerun the shell script.

Another thing you can do would be to replace the docker command with a function (in something like your ~/.bashrc) that stores the arguments to a text file and rechecks that text file with a passed argument (like "recreate" followed by a name). However, I'm more a fan of doing docker containers in their own shell scripts as its more portable.

JonShipman
  • 530
  • 4
  • 8