Changing a port is difficult without editing docker-compose.yml (Updating via git pull is difficult)

[LEv145]

Due to the fact that docker-compose specifies ports for all profiles:

stable-diffusion-webui-docker/docker-compose.yml

Lines 4 to 5 in 445f3f8

	ports:
	- "7860:7860"

it is difficult to launch multiple profiles with different ports

And if you specify ports in docker-compose.override.yml, then they are not overridden, but merged:
docker-compose.override.yml:

services:
  invoke:
    ports:
      - "7861:7860"

Result:

services:
  invoke:
    ...
    ports:
      - "7860:7860"
      - "7861:7860"

https://docs.docker.com/compose/extends/#adding-and-overriding-configuration

[LEv145]

Сan specify different ports for each profile in docker-compose.yml:

services:
  auto: &automatic
    ...
    profiles: ["auto"]
    ports: ["7860:7860"]

  invoke:
    ...
    profiles: ["invoke"]
    ports: ["7861:7860"]

[AbdBarho]

running multiple UIs in parallel is not the intended use-case for this repo. and there might be a lot of cases where race conditions happen where one UI is reading and the other is writing, and TBH, I am not sure what is the use case.

[LEv145]

Maybe there are problems, but this function is convenient and it still works for me
But if I create multiple instances of stable-diffusion-webui-docker, then I won't be able to change the port without changing docker-compose.yml

[LEv145]

@AbdBarho I thought that if a port 7860 is busy on my computer, then I will not redefine it in any way without changing docker-compose.yml
So the problem is more that you can't change the port, and not in the profiles

[AbdBarho]

you can remove the ports from the original docker-compose.yml file and have them only in the docker-compose.override.yml.

[LEv145]

you can remove the ports from the original docker-compose.yml file and have them only in the docker-compose.override.yml.

Thx
I did so, but this option is not convenient to update via git pull
I don't know if there is a better option
I need to combine my docker-compose.yml and new

[LEv145]

nano docker-compose.yml  # Change ports

Now it is necessary to update so:

mv docker-compose.yml tmp.yml
git pull
cat tmp.yml  # Read file with ports
nano docker-comoose.yml  # Change ports
rm -Rf tmp.yml

[DevilaN]

After 7 years, functionality to really override something in docker-compose.yml file is coming, but still not yet on production.
compose-spec/compose-spec#340 will come with next release and we can use !reset to remove section of original docker-compose.yml file...
Until then you are condemned to do it manually.

My suggestion here would be to change ports section in docker-compose.yml to look like this:

ports:
  - "${WEBUI_PORT:-7860}:7860"

This will be backward compatible, as not specifying WEBUI_PORT will use default value 7860, but if user has .env file with:

WEBUI_PORT=12345

Then 12345 will be used here.

Also .env file should be gitignored. Those are two small changes and should be enough right now to specify it in .env file once and upgrade everything without worrying about doing changes manually. @AbdBarho, will you make changes?

[DevilaN]

If somebody want to make mess, then you probably cannot stop that anyway. Why would you put anything else in .env-invoke file anyway?

[wookiefriseur]

Oh, didn't see this discussion before making the draft PR #481

After 7 years, functionality to really override something in docker-compose.yml file is coming, but still not yet on production. compose-spec/compose-spec#340 will come with next release and we can use !reset to remove section of original docker-compose.yml file... Until then you are condemned to do it manually.

If docker-override.yml is how it should be done I can just wait for the docker compose update and then use override instead. I would have thought that .env is best practice though, because it is more obvious to the user and allows passing variables when starting containers.

We can have .env.example that people could copy and rename, but it is easy to have an outdated .env that influences the build without knowing it.

.env.example could be auto generated from docker-compose.yml if the variables will really change that often. The worst thing that can happen regarding outdating is that a user sets a variable that doesn't exist anymore. An outdated docker-override.yml on the other side though can actually break.

[DevilaN]

.env file allows to pass vairables to to docker compose environment and use that variables when processing docker-compose.ymlfile. This gives you some flexibility with variables that services depends on without need to actually change docker-compose.yml file at all (and this makes git pull a lot easier as there are no conflicts.
docker-compose.override.yml allows to add services / modify existing ones (like adding more volumes, etc). This is intended for different use than .env. And principle is the same. No conflicts when doing git pull :-)

Looking at history of this repository, there are not many changes to variables being used by docker-compose.yml so most of the time this will be not a problem at all.

[LEv145]

@DevilaN New release
https://github.com/docker/compose/releases/tag/v2.19.0

But spec mentions the ability to remove elements, not overwrite them
docker/compose#3729 (comment)

[DevilaN]

@LEv145 Yeah. Developers don't use software like users and don't try to understand problems behind posted issues. So basically this is unusable for us :(

There is workaround, but it requires some additional setup. using !reset for port section releases port publishing by docker container which allows to run more than one instance. You need only web entrypoint server to handle this properly. Ping me if you are interested in my solution.

[DevilaN]

docker compose --env-file .env-invoke --profile invoke up # this uses WEBUI_PORT value from .env-invoke file
docker compose --profile auto up # this uses default / .env WEBUI_PORT value.
So you should be able to use different WEBUI_PORT values for different services. Also to save some typing you can prepare some aliases / commands to run it that way with one click or one command like "start-auto" and "start-invoke" which will run proper command with parameters needed.

My machine is too weak to run multiple webui interfaces, so still - there might be some problems with sharing same graphics card memory by two different apps in the same time. It's up to you checking it! :)