I have a docker-compose file that looks like the following:
mongo:
image: mongo:3.6.12
container_name: mongo-${BUILD_ID}
app:
image: repo/my-image:latest
container_name: app-${BUILD_ID}
working_dir: /src
depends_on:
- mongo
I'm running this in a CI/CD pipeline to execute tests in parallel via a docker-compose run app run-test-1.sh but have noticed only one instance of a mongo container is created. This seems to result in the tests interfering with each other. Is it possible to docker-compose run such that it will create both the app service and the mongo service together and encapsulated from other docker-compose run containers so that they each have their own mongo instance?
I have tried the following to no avail:
Adding a container_name: mongo-${BUILD_ID} property in the docker-compose.yml
Adding the --name flag when executing the command. i.e. docker-compose run --name id1 app run-test-1.sh
Managed to figure this out. docker-compose has a flag --project-name which it will use instead of the default value (folder name).
Thus my docker-compose.yml looks like:
mongo:
image: mongo:3.6.12
app:
image: repo/my-image:latest
working_dir: /src
depends_on:
- mongo
and I can execute the following commands and each will be namespaced within their respective project names:
docker-compose --project-name project1 run app ./run-test1.sh.
docker-compose --project-name project2 run app ./run-test2.sh.
docker-compose --project-name project3 run app ./run-test3.sh.
I
Related
How can I implement the below docker-compose code, but using the docker run command? I am specifically interested in the depends_on part.
version: '2'
services:
db:
image: postgres
web:
build: .
command: python manage.py runserver 0.0.0.0:8000
volumes:
- .:/code
ports:
- "8000:8000"
depends_on:
- db
depends_on: doesn't map to a docker run option. When you have your two docker run commands you need to make sure you put them in the right order.
docker build -t web_image .
docker network create some_network
docker run --name db --net some_network postgres
# because this depends_on: [db] it must be second
docker run --name web --net some_network ... web_image ...
depends-on mean :
Compose implementations MUST guarantee dependency services have been started before starting a dependent service. Compose implementations MAY wait for dependency services to be “ready” before starting a dependent service.
Hence the depends on is not only an order of running
and you can use docker-compose instead of docker run and every option in docker run can be in the docker-compose file
I have an idea to up several similar instances with my docker-compose simple mini-project.
docker-compose file:
version: '3.1'
services:
postgres:
build:
context: .
dockerfile: postgres/Dockerfile
environment:
- POSTGRES_PASSWORD=postgres
- POSTGRES_USER=postgres
ports:
- "${PORT_NUMBER}:5432"
Dockerfile:
FROM postgres:9.6
In ./config/.env.dev file I set unique required port number (eg. 5435 for first instance,
5436 for second etc.)
When I up first instance with command:
docker-compose -p instance1 --env-file ./config/.env.dev up
it's OK and I see one new container and one new network instance1_default.
But when I try to up another new instance with command:
docker-compose -p instance2 --env-file ./config/.env.dev up
Docker stuck at this:
Creating network "instance2_default" with the default driver
.. and nothing happens. Yes, I changed port number in env-file before running new instance.
What's wrong with creating new network?
Docker version 20.10.8, build 3967b7d
docker-compose version 1.29.2, build 5becea4c
I've created a simple Sonatype API client in Elixir that returns the repositories and the components of the repositories.
I now need to create tests in Elixir so that I can verify the repo. I am using docker-compose to start the sonatype container. I need the tests to start with a fresh Docker(sonatype) repo to work with, via docker-compose up, then verify that it doesn't have any containers in it. Then from there add one or more images, then validate that the images I added are present. As cleanup, I could delete those images. It must be an automated set of tests that can run in CI or a user can run on their local machine.
My question is how would I be able to do that by either a .exs test file or bash script file?
You can build a docker-compose.yml file with something similar to this:
version: "2.2"
services:
my_app:
build:
context: .
ports:
- 4000:4000
command: >
bash -c 'wait-for-it -t 60 sonatype:1234
&& _build/prod/rel/my_app/bin/my_app start'
tests:
extends:
service: my_app
environment:
MIX_ENV: test
LOG_LEVEL: "warn"
working_dir: /my_app
depends_on:
- sonatype
command:
bash -c 'mix test'
sonatype:
image: sonatype/nexus3:3.19.1
ports:
- "1234:1234"
Then you have a bash script like test.sh:
docker-compose build tests
docker-compose run tests
EXIT=$?
docker-compose down --volumes
exit $EXIT
I'm not familiar with Sonatype, so this might not make sense, and you need to adapt.
I have a docker-compose.yml file which brings up several services (redis, db, mongo, app). I made a script to bring up Docker environment up, but forcing you to forward environment variable which will act as a subdomain for the app (which is a PHP web app).
So for the app container I have:
app:
build:
context: .
dockerfile: ./docker/app/Dockerfile
image: xxx:xxx
container_name:my-app-${ENV}
restart: always
depends_on:
...
Now what I would like is to be able to fire up several apps which all depend on already brought up containers (for example app1.com and app2.com using the same DB).
So I was trying to bring it up by using:
ENV=$1 VIRTUAL_HOST=$1.com docker-compose up -d --build app
(I am using nginx container to enable virtual hosts, and $1 comes from bash script). But what this does is just rebuilds already existing app container and adds a new name.
Can I run docker-compose while building completely new app container, leaving others intact if they already exist?
You can run docker-compose up -d [NEW APPNAME] to build/run a specific app in the compose file
try...
docker-compose build [appName]
docker-compose up --no-deps -d [appName]
The first command builds the new container with [appName]
The 2nd command stops, destroys, and recreates just the [appName] container.
The --no-deps flag prevents Compose from recreating any services which [appName] depends on
your apps have to have different names since compose is going to build, stop, create all containers with that name.
so your compose file should be similar to:
app:
build:
context: .
dockerfile: ./docker/app/Dockerfile
image: xxx:xxx
container_name:my-app-${ENV}
restart: always
depends_on: ...
app2:
build:
context: .
dockerfile: ./docker/app/Dockerfile
image: xxx:xxx
container_name:my-app2-${ENV}
restart: always
depends_on: ...
app3:
build:
context: .
dockerfile: ./docker/app/Dockerfile
image: xxx:xxx
container_name:my-app3-${ENV}
restart: always
depends_on: ...
the above is using the same Dockerfile for app containers.
to use different dockerfiles for each app just change path of dockerfile
I am trying to use Docker Compose (with Docker Machine on Windows) to launch a group of Docker containers.
My docker-compose.yml:
version: '2'
services:
postgres:
build: ./postgres
environment:
- POSTGRES_PASSWORD=mysecretpassword
frontend:
build: ./frontend
ports:
- "4567:4567"
depends_on:
- postgres
backend:
build: ./backend
ports:
- "5000:5000"
depends_on:
- postgres
docker-compose build runs successfully. When I run docker-compose start I get the following output:
Starting postgres ... done
Starting frontend ... done
Starting backend ... done
ERROR: No containers to start
I did confirm that the docker containers are not running. How do I get my containers to start?
The issue here is that you haven't actually created the containers. You will have to create these containers before running them. You could use the docker-compose up instead, that will create the containers and then start them.
Or you could run docker-compose create to create the containers and then run the docker-compose start to start them.
The reason why you saw the error is that docker-compose start and docker-compose restart assume that the containers already exist.
If you want to build and start containers, use
docker-compose up
If you only want to build the containers, use
docker-compose up --no-start
Afterwards, docker-compose {start,restart,stop} should work as expected.
There used to be a docker-compose create command, but it is now deprecated in favor of docker-compose up --no-start.