About linux : docker-compose-removes-sibling-container

I am using docker-compose along with the docker-compose.yml file as the final step of my ci/cd pipeline to create/re-create containers on a server.

Code example:

sudo docker-compose up --force-recreate --detach
sudo docker image prune -f --all --filter="label=is_image_disposable=true"

My goal is to deploy and keep several containers from the same repo but with a different tags on a single server.

The problem is that docker-compose seems to remove existing containers of my repo before it creates new ones, even tho the existing container has tag :dev, and the new one has tag :v3.

As an example: before docker-compose command has been executed I had a running container named

• my_app_dev container of the repo hub/my.app:dev,

and after the docker-compose command ran i have this

• my_app_v3 container of the repo hub/my.app:v3.

What I do want to see in the end is both containers are up and running:

• my_app_dev container of the repo hub/my.app:dev
• my_app_v3 container of the repo hub/my.app:v3

Can someone give me an idea how can I do that?

That is expected behaviour. Compose works based on the concept of projects.
As long as the two compose operations are using the same project name, the configurations will override each other.

You can do what you want to some degree by using a unique project name for each compose up operation.

docker compose --project-name dev up 
docker compose --project-name v3 up 

This leads to the containers being prefixed with that specific project name. i.e. dev-app-1 and v3-app-1.

If they need to be all on the same network, you could create a network upfront and reference it as an external network under the default network key.

networks:
  default:
    name: shared-network
    external: true