[Bug]: container_name prevents replication.

[chrisbecke]

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

[Aniketh999]

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

[josselinlbe]

Interested!

[vanWittlaer]

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!

[Thytu]

Would be interesting to see if the same happens with a raw Docker Compose

[vanWittlaer]

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

[Thytu]

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.

[HarleySalas]

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?

[terijaki]

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. (#2824 (comment)).
The reason for this is beyond my Coolify/Docker knowledge but I hope this is being looked into.