is there a way to specify in docker-compose.yml that certain container should automatically be resurrected if it dies ? (e.g. if some internal issue killed container, docker-compose will up it again)
If this is not possible for individual containers how about global option for all containers (e.g. docker-compose up --restart-automaticly-or-something )
https://docs.docker.com/compose/compose-file/compose-file-v3#restart_policy
version: "3.9"
services:
web:
image: whatever:latest
deploy:
restart_policy:
condition: on-failure
delay: 5s
max_attempts: 3
window: 120s
Related
When trying to deploy my app on Docker swarm I have two services: NGINX to serve static files and app to compile some static files. To run static files compilation I'm using entrypoint in Compose file.
docker-compose.yml:
version: "3.9"
services:
nginx:
image: nginx
healthcheck:
test: curl --fail -s http://localhost:80/lib/tether/examples/viewport/index.html || exit 1
interval: 1m
timeout: 5s
retries: 3
volumes:
- /www:/usr/share/nginx/html/
deploy:
mode: replicated
replicas: 1
placement:
constraints:
- node.role == manager
ports:
- "8000:80"
depends_on:
- client
client:
image: my-client-image:latest
restart: "no"
deploy:
mode: replicated
replicas: 1
placement:
constraints:
- node.role == manager
volumes:
- /www:/app/www
entrypoint: /entrypoint.sh
entrypoint.sh
./node_modules/.bin/gulp compilescss
I tried adding restart: "no" in my service, but service is restarted on entrypoint completion anyway
Docker 23.0.0 is now out. As such you have two options:
stack files now support swarm jobs. Swarm understands that these run to completion. i.e. mode: replicated-job.
Docker Compose V3 Reference makes it clear that "restart:" applies to compose and "deploy.restart_policy.condition: on-failure" is the equivalent swarm statement.
Running rundeck from docker (default backend), but noticed there are no logs. This documentation seems not complete / not valid for docker deployment: https://docs.rundeck.com/docs/administration/maintenance/logs.html
All the logs inside docker:/home/rundeck/server/logs have 0 size.
How to review the logs when running as a docker ?
Thanks,
The execution logs are stored at the /home/rundeck/var/logs/rundeck path, so, a good idea is to mount it as a volume (to see them in your local filesystem), take a look at this docker-compose example:
version: '3'
services:
rundeck:
image: rundeck/rundeck:4.2.1
environment:
RUNDECK_GRAILS_URL: http://localhost:4440
RUNDECK_DATABASE_DRIVER: org.mariadb.jdbc.Driver
RUNDECK_DATABASE_USERNAME: rundeck
RUNDECK_DATABASE_PASSWORD: rundeck
RUNDECK_DATABASE_URL: jdbc:mariadb://mysql/rundeck?autoReconnect=true&useSSL=false&allowPublicKeyRetrieval=true
RUNDECK_LOGGING_STRATEGY: FILE
volumes:
- ./data/logs/:/home/rundeck/var/logs/rundeck/
ports:
- 4440:4440
tty: true
mysql:
image: mysql:8
expose:
- 3306
environment:
- MYSQL_ROOT_PASSWORD=root
- MYSQL_DATABASE=rundeck
- MYSQL_USER=rundeck
- MYSQL_PASSWORD=rundeck
The service.log is available in the docker logs command, to see it just do docker logs <container_id> -f.
I am trying to use ecs-cli to push a two container docker compose file up to FARGATE ECS. This is for a preview environment only. The first container is postgres:12 and the second is hasura/graphql-engine:v1.3.3
The docker-compose.yml looks like the following
version: '3'
services:
postgres:
image: postgres:12
ports:
- "5432:5432"
restart: always
volumes:
- db_data:/var/lib/postgresql/data
environment:
POSTGRES_PASSWORD: postgrespassword
logging:
driver: awslogs
options:
awslogs-group: tutorial
awslogs-region: us-east-1
awslogs-stream-prefix: postgres
graphql-engine:
image: hasura/graphql-engine:v1.3.3
ports:
- "80:80"
depends_on:
- "postgres"
restart: always
environment:
HASURA_GRAPHQL_DATABASE_URL: postgres://postgres:postgrespassword#127.0.0.1:5432/postgres
## enable the console served by server
HASURA_GRAPHQL_ENABLE_CONSOLE: "true" # set to "false" to disable console
## enable debugging mode. It is recommended to disable this in production
HASURA_GRAPHQL_DEV_MODE: "true"
HASURA_GRAPHQL_ENABLED_LOG_TYPES: startup, http-log, webhook-log, websocket-log, query-log
## uncomment next line to set an admin secret
# HASURA_GRAPHQL_ADMIN_SECRET: myadminsecretkey
logging:
driver: awslogs
options:
awslogs-group: tutorial
awslogs-region: us-east-1
awslogs-stream-prefix: hasura
volumes:
db_data:
The ecs-params.yml looks like the following
version: 1
task_definition:
ecs_network_mode: awsvpc
task_role_arn: "arn:aws:iam::***:role/ecsTaskExecutionRole"
task_execution_role: "arn:aws:iam::***:role/ecsTaskExecutionRole"
task_size:
cpu_limit: "256"
mem_limit: "512"
run_params:
network_configuration:
awsvpc_configuration:
subnets:
- "subnet-***"
- "subnet-***"
security_groups:
- "sg-***"
assign_public_ip: "ENABLED"
I am using the following command line call to trigger the push
ecs-cli compose --file docker-compose.yml --ecs-params ecs-params.yml --debug service up --deployment-max-percent 100 --deployment-min-healthy-percent 0 --region us-east-1 --cluster "{ARN CLUSTER VALUE}" --create-log-groups --launch-type "FARGATE"
In ECS I can see the new service created and its 1 Fargate task is spinning up. If I open the task, the containers move from PENDING -> RUNNING. After some time, the application container moves to STOPPED and then eventually the database container moves to STOPPED as well. Once this happens the task stops and a new task goes through the same cycle.
Here is the log for the application container
Here is the log for the database container
In the docker-compose I have tried changing the environment variable for the PG database connection string to both postgres://postgres:postgrespassword#127.0.0.1:5432/postgres and postgres://postgres:postgrespassword#localhost:5432/postgres, both result in the same issue.
Any idea what might be going on here? This is inspired from this article: https://dev.to/raphaelmansuy/10-minutes-to-deploy-a-docker-compose-stack-on-aws-illustrated-with-hasura-and-postgres-3f6e
The only difference is that article uses EC2, not Fargate.
try and add
links:
- postgres
to your graphql-engine service instead of depends_on which doesn't seem to work with AWS ECS.
I have overlapping with default docker subnets, so I want to setup for some services custom network. docker-compose version:3
example of docker-compose.yml
version: '3'
services:
service1:
build:
dockerfile: Dockerfile
service2:
build:
dockerfile: Dockerfile1
service3:
build:
dockerfile: Dockerfile2
networks:
- net1
networks:
net1:
ipam:
driver: default
config:
- subnet: "172.101.0.0/24"
So when I execute the following command I got 2 networks :
docker-compose up --build -d service3
project_default and project_net1
But I need default network for other services so I can't change default settings.
What should I do to not create default network if it's not used for the service?
If you don't have a networks: specification for a given service, Docker Compose behaves as though you specified networks: [default]. In your example, service1 and service2 are on the default network and service3 is on the net1 network.
If you really need Docker Compose to not create the project_default network then you need to assign every container to some other network. From experimenting with a minimal docker-compose.yml file, explicitly adding networks: [net1] to the two services that don't already have it will cause the default network to not be created.
If your real issue is just around an IP address conflict, you're allowed to manually configure the default network and this might be easier.
version: '3'
services:
service1:
build: .
# with no networks:, so it gets the default
networks:
default:
ipam:
driver: default
config:
- subnet: "172.101.0.0/24"
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