Update setup.rst

[a-waider]

In my installation environment the setup didn't work. I think running docker exec instead of docker-compose run is more error free. Or is there any specific reason why docker-compose run is used?

[torwag]

According to the answers on a similar question on
almighty stackoverflow

docker-compose exec: will run docker exec to start a new process/command inside an existing, running container

docker-compose run: starts a new container for interactively executing the specified command, i.e. executing docker run

docker-compose exec is basically identical to docker exec. It is a debugging tool that can run an additional command inside a running container. It runs in the same environment as the container's main process, with the same container-private filesystem. It is not a child process of the main process, and if the main process has an entrypoint wrapper script that sets environment variables, it won't get to see those. The additional command is frequently a debugging shell, and docker-compose exec defaults to the docker exec -it options.

# Get a debugging shell in a running container:
docker-compose exec app bash

# Basically equivalent to:
docker exec -it project_app_1 bash

Which leaves the question if identical, why does one work for you and not the other?

[mskg]

Your description contains the answer. Exec allows you to connect to a running container, run creates a new container before running.

The image is a daemon (webserver, 3 services for processing files, database, ...) . You start it (docker-compose up -d), and can run commands inside using exec.

[torwag]

Yeah, I just came here again to say this...
Things get mixed up.... docker-compose vs. docker and exec vs. run.
If I understand the setup documentation correctly, you need to use "exec" and not run, as you want to create the superuser stuff inside the already existing container. Unlike whatever the script does, changes stuff on the same volume share. But yeah, "exec" should be more save.

[mskg]

Yes and no. Because you map out all files that are required to rerun it in a specific state it will also work. And if there is not other container running, it is totally valid to do it like that (use run).

[mskg]

I checked the change you did. As he starts the container three steps before it, one should use exec here. There is some other places where the container needs to be stopped before the commands are execute, there the run is OK.

[mskg]

As the container is already up in step 1, exec should be used.