coolify
coolify copied to clipboard
coollabsio
[Bug]: container_name prevents replication.
Description
It is not possible to deploy Docker compose files with "replicas:" other than 1.
Minimal Reproduction (if possible, example repository)
Create a Docker Compose resource and attach the following compose.yaml
services:
my:
image: 'nginx:latest'
deploy:
replicas: 3
Exception or Error
Saved configuration files to /data/coolify/services/iokgo8w.
Creating Docker network.
Starting service.
Pulling images.
services.deploy.replicas: can't set container_name and my as container name must be unique: invalid compose project
Version
v4.0.0-beta.270
To resolve this issue, you need to ensure that each replica has a unique container name. You can achieve this by using the container_name option in your service configuration. Here's an example of how you can modify your Docker Compose file:
services: my: image: 'nginx:latest' deploy: replicas: 3 container_name: my_container_1 deploy: replicas: 3 container_name: my_container_2 deploy: replicas: 3 container_name: my_container_3
To resolve this issue, you need to ensure that each replica has a unique container name. You can achieve this by using the container_name option in your service configuration. Here's an example of how you can modify your Docker Compose file:
services: my: image: 'nginx:latest' deploy: replicas: 3 container_name: my_container_1 deploy: replicas: 3 container_name: my_container_2 deploy: replicas: 3 container_name: my_container_3
@Aniketh999 Sorry I somehow can't get this to work with your answer. Complains about duplicate "deploy:" What am I getting wrong? Would you mind posting a properly formatted example? Thanks!
The problem is inherent to coolify generating the container names and not knowing about replicas. So rather a feature than a bug :-).
I can get by with this workaround:
services:
worker-1: &worker
image: vanwittlaer/some-image:latest
restart: unless-stopped
...
worker-2: *worker
worker-3: *worker
The problem is inherent to coolify generating the container names and not knowing about replicas. So rather a feature than a bug :-).
I can get by with this workaround:
services: worker-1: &worker image: vanwittlaer/some-image:latest restart: unless-stopped ... worker-2: *worker worker-3: *worker
Smart! Unfortunately it might only solve half the problem, not having real replica prevents the rolling update features, meaning the service will experience down-time at each update.
It would be genuinely a very nice experience to just write:
services:
myapp:
build:
context: ./apps/myapp
dockerfile: Dockerfile
environment:
- SERVICE_FQDN_MYAPP
deploy:
replicas: ${MYAPP_REPLICAS}
and have coolify be able to take over and just handle this. Is there anything that inherently prevents this from being possible, or is it something that we might be able to have in the future? Perhaps the restriction that images must be built beforehand?
It would be genuinely a very nice experience to just write:
services: myapp: build: context: ./apps/myapp dockerfile: Dockerfile environment: - SERVICE_FQDN_MYAPP deploy: replicas: ${MYAPP_REPLICAS}and have coolify be able to take over and just handle this. Is there anything that inherently prevents this from being possible, or is it something that we might be able to have in the future? Perhaps the restriction that images must be built beforehand?
Coolify adds its own container name after it reads the docker-compose file, preventing replicas and rolling updates. (https://github.com/coollabsio/coolify/discussions/2824#discussioncomment-10528223). The reason for this is beyond my Coolify/Docker knowledge but I hope this is being looked into.
