Docker Compose file to Create a container with multiple Images
I need to build a container using the following images.
Python
DotNetCore 2.0
have created a docker-compose.yml file as below. Am trying to create one container for each image and do linking between the containers. But its failing can you please correct me the compose file.
Also after the container is created how can i check what are the images inside the container.
…
version: “1.0”
services:
phython:
image: python
dotnetcore:
image: microsoft/aspnetcore:2.0
links:
phython:hub
Please suggest how to go ahead .
If you are able I would recommend using docker-compose 3.0 instead of 1.0. The 'links' attribute is deprecated in 3.0 which now favors just setting up a simple user-defined bridge network. Your docker-compose would be as follows:
version: 3.0
services:
phython:
image: python:latest
networks:
- my-net
dotnetcore:
image: microsoft/aspnetcore:2.0
networks:
- my-net
networks:
my-net:
driver: bridge
Related
I've been trying to launch a containerized mongoDB instance using docker-compose onto ECS w/ Fargate, here is my docker compose configuration:
mongo:
image: mongo:latest
restart: always
environment:
MONGO_INITDB_USERNAME: root
MONGO_INITDB_DATABASE: db-name
volumes:
- ./migration/init.js:/docker-entrypoint-initdb.d/mongo-init.js:ro
ports:
- "27017:27017"
Using docker compose version : 3
I'm getting the following error: FATA[0000] ClientException: Fargate compatible task definitions do not support sourcePath
Any ideas on what I'm doing wrong?
You can't mount a local file/folder (.migration/init.js) to a task in the cloud. I am not familiar with Mongo so I am not 100% sure what that file does but the easiest way to solve this would be to create a new docker image FROM mongo where the only line would be a ADD to add the init.js file where you need it inside the container (/docker-entrypoint-initdb.d/mongo-init.js ?). The "even easier" way to solve this would be to eliminate the volume directive in the compose (but I don't know what the ramifications of doing so would be for the mongo container you need to run).
I have a docker.compose.yml file that works as expected when I execute docker-compose up in its parent directory.
My problem is that it's an old version compose file, and I need to integrate its containers into another compose file. The old file has the following structure:
service1:
...
service2:
...
While the target docker-compose.yml has the following structure:
version: '2.3'
services:
service1:
...
service2:
...
So, my problem is that the old version file relies on parameter links. I don't quite understand what is its function. I see few documentation online, and all that the docs says is that the links are replaced by networks. Good, but what is the function of links? How could I replace it, so I don't use (about to get) deprecated features?
Links are not required to enable services to communicate - by default, any service can reach any other service at that service’s name.
You can just delete the link section of the old-version docker compose file and access the services from other container by their names.
You can optionally define networks in order to define which service will be available to the others by placing them in the same network. E.g. :
networks:
my_network_1:
driver: bridge
my_network_2:
driver: bridge
services:
service_1:
networks:
- my_network_1
service_2:
networks:
- my_network_1
service_3:
networks:
- my_network_2
I have two different docker-compose file having different services(project space) which I want to run on same swarm because I want to use traefik as reverse proxy how could I do that?
You have to use a common image registry and prebuild images before deploying to swarm:
first compose file:
services:
my_service:
build: ./my_service
image: my-registry-host/my_service:latest
...
second compose file:
services:
my_other_service:
build: ./my_other_service
image: my-registry-host/my_other_service:latest
...
my_service:
image: my-registry-host/my_service:latest
...
traefik:
image: traefik:v2.0
...
when you build the services in the first file they are uploaded to your common registry my-registry-host. An when you deploy the second file you will see that the image will be got from the common registry and stack runs as expected.
I am working on Node Js application, and for every new release I want to create a new Docker with new image (image name is pass as variable in Docker Compose), but without deleting the old one, as I want to do version controlling?
My Docker-Compose File is as
version: '3'
services:
web:
build: .
image: ${IMAGE_NAME}
container_name: ${CONTAINER_NAME}
ports:
- ${PORT}:8447
Command I run is docker-compose up -d but this will delete my old container and start a new one.
Its not ideal to have multiple versions of the container , but we can have updated version of images using tag.You can tag the image with the version number.Compose will build and tag it with a generated name, and use that image thereafter to create containers.
So whenever you have a new build you will a new image of the build with the tag and with that you can track the versions of the build versions.
Here below is the link which can help how to tag a image from Docker Compose:
How to tag docker image with docker-compose
But if you want to run multiple instances of the container with the same image , you can use scale:
docker-compose up -d --scale <imageName>=5
You can also do that using "replicas" inside your compose file itself.
deploy:
mode: replicated
replicas: 5
Source :
https://docs.docker.com/compose/compose-file/#replicas
I have a docker-compose.yml with multiple services using same Dockerfile (django, celery, and many more) When I use docker-compose build, it build my container multiple times.
It make my "apply changes and restart" process costly. Is there a good way to build the Dockerfile only once? Sould I build only one container and hope it updates all?
In my case I have 5 instance of a Dockerfile simply using a different commands, different volumes…
Using --build flag along with docker-compose up makes docker to build all containers. If you want to build only once then you can name the image which is built in one service and for other services, instead of using dockerfile, you can use that newly built image.
version: '3'
services:
wordpress-site-1:
image: wordpress:custom
build:
context: ./wordpress
dockerfile: wordpress.dockerfile
container_name: wordpress-site-1
links:
- mysql-database
depends_on:
- mysql-database
ports:
- 8080:80
wordpress-site-2:
image: wordpress:custom
container_name: wordpress-site-2
links:
- mysql-database
depends_on:
- mysql-database
- wordpress-site-1
ports:
- 8888:80
Note: build and image are used in first service and only image is used in the second service.
This is sample usage which generates two wordpress containers, one of which is built from the dockerfile which is specified in context and names the generated image as wordpress:custom and other is built from the image wordpress:custom. The container name is different but the image used is same in both the services. One service builds the image using build context and other uses that image. Being at safe side, you may remove any previous wordpress:custom image. So that wordpress-site-2 does not use cached image.
Edit 1: Extended answer to show how two containers are built using same image. Same container_name cannot be used.