I´m having problems getting data volume containers running in docker-compose v3. As a test I´ve tried to connect two simple images like:
version: '3'
services:
assets:
image: cpgonzal/docker-data-volume
container_name: data_container
command: /bin/true
volumes:
- assets_volume:/tmp
web:
image: python:3
volumes:
- assets_volume:/tmp
depends_on:
- assets
volumes:
assets_volume:
I would expect that python:3 container can see /tmp of data_container. Unfortunately
docker-compose up
fails with
data_container exited with code 0
desktop_web_1 exited with code 0
What am I doing wrong?
Both of your containers exited because there's no command to keep it running.
Use these three options: stdin_open, tty, and command to keep it running.
Here's an example:
version: '3'
services:
node:
image: node:8
stdin_open: true
tty: true
command: sh
Related
docker-compose.yaml
version: '3.9'
services:
cloudsql-proxy: # doesnt work when ran by itself
container_name: cloudsql-proxy1
image: gcr.io/cloudsql-docker/gce-proxy:1.31.0
# tty: true
command: >
/cloud_sql_proxy --dir=/cloudsql
-instances=xyz=tcp:0.0.0.0:3306
-credential_file=/secrets/cloudsql/credentials.json
ports:
- 127.0.0.1:3306:3306
volumes:
- ../developer-sv-account-key.json:/secrets/cloudsql/credentials.json
restart: always
local-dev-db:
image: library/postgres:13-alpine
container_name: local-dev-db
depends_on:
cloudsql-proxy:
condition: service_started
When I try to connect to cloudsql-proxy db from local client
it works only when I run both services together - docker compose up
If I try docker compose run cloudsql-proxy I get connection error
cloudsql-proxy command when ran independently in terminal (instead of docker compose) works successfully.
I have a few systems where I use docker-compose and there is no problem.
However, I have one here where 'down' doesn't do anything at all.
'up' works perfectly though. This is on MacOS.
The project is nicknamed 'stormy', and here is the script:
version: '3.3'
services:
rabbitmq:
container_name: stormy_rabbitmq
image: rabbitmq:management-alpine
restart: unless-stopped
ports:
- 5672:5672
- 15672:15672
expose:
- 5672
volumes:
#- /appdata/stormy/rabbitmq/etc/:/etc/rabbitmq/
- /appdata/stormy/rabbitmq/data/:/var/lib/rabbitmq/
- /appdata/stormy/rabbitmq/logs/:/var/log/rabbitmq/
networks:
- default
settings:
container_name: stormy_settings
image: registry.gitlab.com/robinhoodcrypto/stormy/settings:latest
restart: unless-stopped
volumes:
- /appdata/stormy/settings:/appdata/stormy/settings
external_links:
- stormy_rabbitmq:rabbitmq
networks:
- default
capture:
container_name: stormy_capture
image: registry.gitlab.com/robinhoodcrypto/stormy/capture:latest
restart: unless-stopped
volumes:
- /appdata/stormy/capture:/appdata/stormy/capture
external_links:
- stormy_rabbitmq:rabbitmq
networks:
- default
livestream:
container_name: stormy_livestream
image: registry.gitlab.com/robinhoodcrypto/stormy/livestream:latest
restart: unless-stopped
volumes:
- /appdata/stormy/capture:/appdata/stormy/livestream
external_links:
- stormy_rabbitmq:rabbitmq
networks:
- default
networks:
default:
external:
name: stormy-network
the 'up' script is as follows:
[ ! "$(docker network ls | grep stormy-network)" ] && docker network create stormy-network
echo '*****' | docker login registry.gitlab.com -u 'gitlab+deploy-token-******' --password-stdin
docker-compose down
docker-compose build --pull
docker-compose -p 'stormy' up -d
and the 'down' is simply:
docker-compose down
version:
$ docker-compose -v
docker-compose version 1.24.1, build 4667896b
when I do 'down', here is the output:
$ docker-compose down
Network stormy-network is external, skipping
and I put a verbose log output at: https://pastebin.com/Qnw5J88V
Why isn't 'down' working?
The docker-compose -p option sets the project name which gets included in things like container names and labels; Compose uses it to know which containers belong to which Compose services. You need to specify it on all of the commands that interact with containers (docker-compose up, down, ps, ...); if you're doing this frequently, setting the COMPOSE_PROJECT_NAME environment variable might be easier.
#!/bin/sh
export COMPOSE_PROJECT_NAME=stormy
docker-compose build --pull
docker-compose down
docker-compose up -d
I'm building a dockerfile. But I meet a problem. It says that :
/bin/sh: 1: mongod: not found
My dockerfile:
FROM mongo:latest
FROM node
RUN mongod
COPY . .
RUN node ./scripts/import-data.js
Here is what happen when docker build:
Sending build context to Docker daemon 829.5MB
Step 1/8 : FROM rabbitmq
---> e8261c2af9fe
Step 2/8 : FROM portainer/portainer
---> 00ead811e8ae
Step 3/8 : FROM docker.elastic.co/elasticsearch/elasticsearch:6.5.1
---> 32f93c89076d
Step 4/8 : FROM mongo:latest
---> 5976dac61f4f
Step 5/8 : FROM node
---> b074182f4154
Step 6/8 : RUN mongod
---> Running in 0a4b66a77178
/bin/sh: 1: mongod: not found
The command '/bin/sh -c mongod' returned a non-zero code: 127
Any idea ?
The problem is that you are using two FROM instructions, which is referred to as a multi-stage build. The final image will be based on the node image that doesn't contain the mongo database.
* Edit *
here are more details about what is happening:
FROM mongo:latest
the base image is mongo:latest
FROM node
now the base image is node:latest. The previous image is just standing there...
RUN mongod
COPY . .
RUN node ./scripts/import-data.js
now you run mongod and the other commands in your final image that is based on node (which doesn't contain mongo)
It happens because multiple FROM instructions should be used for Multistage Build (check the documentation) and NOT for image creation contains all of present applications.
Multistage builds provide you possibility of delegation building process into container's environment without local application installation.
FROM rabbitmq
...some instructions require rabbitmq...
FROM mongo:latest
...some instructions require mongo...
In other words if you want to create an image with rabbitmq, mongo and other application you have to choose the image and install applications manually.
Use docker-compose (https://docs.docker.com/compose/install/) to run the images rather than attempting to build a new image from a collection of existing images. Your docker-compose.yml might look something like:
version: '3.7'
services:
portainer:
image: 'portainer/portainer'
container_name: 'portainer'
hostname: 'portainer'
domainname: 'example.com'
volumes:
- '/var/run/docker.sock:/var/run/docker.sock'
- 'portainer_data:/data'
ports:
- '9000:9000'
rabbitmq:
image: 'rabbitmq'
container_name: 'rabbitmq'
hostname: 'rabbitmq'
domainname: 'example.com'
volumes:
- 'rabbitmq_data:/var/lib/rabbitmq'
elasticsearch:
image: 'elasticsearch:7.1.1'
container_name: 'elasticsearch'
hostname: 'elasticsearch'
domainname: 'example.com'
environment:
- 'discovery.type=single-node'
volumes:
- 'elasticsearch_data:/usr/share/elasticsearch/data'
ports:
- '9200:9200'
- '9300:9300'
node:
image: 'node:12'
container_name: 'node'
hostname: 'node'
domainname: 'example.com'
user: 'node'
working_dir: '/home/node/app'
environment:
- 'NODE_ENV=production'
volumes:
- './my-app:/home/node/app'
ports:
- '3000:3000'
command: 'npm start'
mongo:
image: 'mongo'
container_name: 'mongo'
hostname: 'mongo'
domainname: 'example.com'
restart: 'always'
environment:
- 'MONGO_INITDB_ROOT_USERNAME=root'
- 'MONGO_INITDB_ROOT_PASSWORD=example'
volumes:
- 'mongo_data:/data/db'
volumes:
portainer_data:
rabbitmq_data:
elasticsearch_data:
mongo_data:
I see, quite simple
step1. create this Dockerfile:
FROM mongo:latest
step2. create image from this Dockerfile:
docker build . -t my_mongo_build
This is equal to docker run ..... mongo:latest, used for some strange scenario
I am using docker-compose up command to spin-up few containers on AWS AMI RHEL 7.6 instance. I observe that in whichever containers there's a volume mounting, they are exiting with status Exiting(1) immediately after starting and remaining containers remain up. I tried using tty: true and stdin_open: true, but it didn't help. Surprisingly, the set-up works fine in another instance which basically I am trying to replicate in this new one.
The stopped containers are Fabric v1.2 peers, CAs and orderer.
Docker-compose.yml file which is in root folder where I use docker-compose up command
version: '2.1'
networks:
gcsbc:
name: gcsbc
services:
ca.org1.example.com:
extends:
file: fabric/docker-compose.yml
service: ca.org1.example.com
fabric/docker-compose.yml
version: '2.1'
networks:
gcsbc:
services:
ca.org1.example.com:
image: hyperledger/fabric-ca
environment:
- FABRIC_CA_HOME=/etc/hyperledger/fabric-ca-server
- FABRIC_CA_SERVER_CA_NAME=ca-org1
- FABRIC_CA_SERVER_CA_CERTFILE=/etc/hyperledger/fabric-ca-server-config/ca.org1.example.com-cert.pem
- FABRIC_CA_SERVER_TLS_ENABLED=true
- FABRIC_CA_SERVER_TLS_CERTFILE=/etc/hyperledger/fabric-ca-server-config/ca.org1.example.com-cert.pem
ports:
- '7054:7054'
command: sh -c 'fabric-ca-server start -b admin:adminpw -d'
volumes:
- ./artifacts/channel/crypto-config/peerOrganizations/org1.example.com/ca/:/etc/hyperledger/fabric-ca-server-config
container_name: ca_peerorg1
networks:
- gcsbc
hostname: ca.org1.example.com
version: '3'
services:
db:
image: postgres
web:
build: .
command: python3 manage.py runserver 0.0.0.0:8000
volumes:
- .:/code
ports:
- "8000:8000"
depends_on:
- db
Why I don't lose data when running docker-compose build --force-em --no-cache. If this is normal, why do we need to create volume for data folder ?
When running the command docker-compose build --force-em --no-cache, this will only build the web Docker image from the Dockerfile which in your case is in the same directory.
This command will not stop the containers that you have previously started using this compose file, thus you want lose any data when running this command.
However, as soon as you remove the containers using docker-compose down or when containers are stopped docker-compose rm, you won't find the postgres data when you restart the container.
If you want to persist the data, and make the container pick it up when it is recreated, you need to give the postgres data volume a name as such.
version: '3'
services:
db:
image: postgres
volumes:
- pgdata:/var/lib/postgresql/data
web:
build: .
command: python3 manage.py runserver 0.0.0.0:8000
volumes:
- .:/code
ports:
- "8000:8000"
depends_on:
- db
Now the postgres data won't be lost when the containers are recreated.