I was looking for delay start of last service in my docker-compose.yml but dont see a sleep option as it needs a restart if it fails on first time including depends_on
for using below restart : on-failure in version 3
version: '3'
restart: on-failure
from releases here see only 2.x but no 3.x ?
https://github.com/docker/compose/releases
Related
I have a docker-compose file for some services, among them an airflow-webserver. I realized that I can both add restart and deploy-restart_policy to the compose file. I tried searching for a difference between the two, but could only find posts discussing the individual settings (like on-failure or always).
What is the difference of setting the configuration?
Which should I use?
Is it a versioning issue, e.g. restart is from older versions and deploy-restart_policy is the newer one?
Example docker-compose.yml:
version: "3"
services:
airflow-webserver:
container_name: airflow_container
image: puckel/docker-airflow
ports:
- '8080:8080'
networks:
- dataworld
volumes:
- ./airflow/dags:/usr/local/airflow/dags
- ./airflow/logs:/usr/local/airflow/logs
deploy:
restart_policy:
condition: on-failure
restart: on-failure
The restart and deploy.restart_policy options configure the same thing but depend on the way you run your containers:
restart is used by Docker Compose
deploy.restart_policy is used by Docker Swarm
The deploy option is used for Docker Swarm only and is ignored by Docker Compose.
From the documentation on deploy.restart_policy:
Configures if and how to restart containers when they exit. Replaces restart.
And here about restart:
The restart option is ignored when deploying a stack in swarm mode.
Recently, I tried upgrading a version 2 docker-compose yaml file to version 3. Specifically, I was going from 2.1 to 3.4. Using docker-compose version 1.18.0 and docker version 18.06.01.
The first attempt caused docker-compose to abort because of the presence of the Version 2 option: mem_limit. Reading these Version 3 docs, it clearly states mem_limit was removed and to see "upgrading" to guide usage away from this option. These instruction tell you to use the deploy section with resources. Making these changes to the docker-compose.yml file and the system started normally.
Unfortunately, I missed the disclaimer in there where it states that deploy is ignored by docker-compose! My question: is there a way to use Compose file reference 3 and docker-compose while still enforcing a container memory limit?
No, there is not.
Between versions 2.x and 3.x...several options have been removed
...mem_limit, memswap_limit: These have been replaced by the resources key under deploy. deploy configuration only takes effect when using docker stack deploy, and is ignored by docker-compose.
See Compose: Upgrading from 2 to 3
And also you don't have to upgrade, you don't even have any reason to upgrade if you don't use swarm.
Sadly in the official docker docs, there is stated
Version 3 (most current, and recommended)
which isn't actually really true, if you use docker-compose without swarm, there is hardly any reason to switch or to use on new project v3. In the official repository you can see comments like this [2][3].
Also in the compatibility-matrix you can see that v2 is still upgraded even when v3 is out for quite some time. And only v1 is marked as deprecated.
Here's an example Docker Compose file version 3.8 with memory limitations:
version: '3.8'
services:
web:
image: nginx:latest
deploy:
replicas: 3
update_config:
parallelism: 2
delay: 10s
restart_policy:
condition: on-failure
resources:
limits:
memory: 256M
ports:
- "80:80"
volumes:
- type: volume
source: myapp-data
target: /var/www/html
networks:
- myapp-net
environment:
- NGINX_HOST=example.com
- NGINX_PORT=80
db:
image: mysql:latest
deploy:
replicas: 1
restart_policy:
condition: on-failure
resources:
limits:
memory: 512M
volumes:
- type: volume
source: myapp-db
target: /var/lib/mysql
networks:
- myapp-net
environment:
- MYSQL_ROOT_PASSWORD=root
- MYSQL_DATABASE=myapp
volumes:
myapp-data:
myapp-db:
networks:
myapp-net:
In my Docker-Compose.yml I have defined a Tomcat (including a .war-File) and MySQL-Server Image.
When I use docker-compose up - the MySQL-Server starts and is importing a SQL-Dump. The Tomcat is starting too.
Every time i run docker-compose up there can be other SQL-Skripts (due to a Jenkins-Build-Job which pulls scripts from a gitlab repo)
But I wish to have the Tomcat waiting for finishing the Import of all the SQL-Dumps to start.
Anybody knows how to do this?
Thanks for any help.
If you're using docker-compose version 2, you can specify a healthcheck for your mysql container, and then use condition: service_healthy in your depends_on section. e.g. something like
services:
db:
image: mysql:5.7
healthcheck:
test: mysql --protocol=socket -hlocalhost -uroot -p$$MYSQL_ROOT_PASSWORD -e 'SELECT 1'
tomcat:
image: tomcat
depends_on:
db:
condition: service_healthy
See https://docs.docker.com/compose/compose-file/compose-file-v2/#depends_on
This is unsupported in docker-compose 3, so we currently use docker-compose 2 to avoid this issue.
I looked thru the docs for docker-compose and I see that Version 3 has a deploy restart policy but it's only for swarm. I tried setting restart_policy on my service but got this error:
ERROR: The Compose file './docker-compose.yml' is invalid because:
Unsupported config option for services.web: 'restart_policy'
Is there any way to set a restart policy on services created using docker-compose outside of a swarm?
It looks like a gap in the documentation
In 3rd version, we can still use "restart" inside services same as before in v.2 (except for deploy into swarm)
version: '3'
services:
my-service:
restart: on-failure:5
https://docs.docker.com/compose/compose-file/compose-file-v3/#restart_policy
Version 2 supports restart policies, using the restart keyword, and should work fine for you if you don't need Swarm (which you said you don't need/want).
version: '2'
services:
web:
image: apache
restart: always
https://docs.docker.com/compose/compose-file/compose-file-v2/#restart
Compose format version 3 has a parameter called restart_policy, but so far as I can tell from documentation it is only valid as part of deploy, which is only used when deploying to a Swarm. So version 3 is probably not useful in your case.
Even if you're NOT in swarm mode, there is an option called --compatibility which will work with restart_policy, this will attempt to restart even if you're not deploying. The only glitch, is the sub-keys of 'delay' and 'window' will be ignored. Here is an example:
version: '3.7'
services:
build:
context: .
dockerfile: Dockerfile
container_name: example
deploy:
restart_policy:
condition: on-failure
max-attempts: 3
run this command:
docker-compose -f docker-compose.yml --compatibility up
I need to start multiple containers for the same image. If I create my compose file as shown below, it works fine.
version: '2'
services:
app01:
image: app
app02:
image: app
app03:
image: app
app04:
image: app
app05:
image: app
Is there an easy way for me to mention the number of instances for the compose instead of copy and pasting multiple times?
Updated answer (Oct 2017)
As others mentioned, the Docker API has changed. I'm updating my answer since it's the one most people will probably look at.
docker-compose up -d --scale app=5
Unfortunately, we cannot specify this in a docker-compose.yml file currently (as of version 3.5).
Details:
They did introduce the scale option for version 2.2 and 2.3 of docker-compose, but they removed it for version 3.0. Also, to use version 2.2 or 2.3 you would need to download an older version of the docker-compose tool. The current version does not support 2.2 or 2.3 (it does support 2.0 or 2.1 however).
There is also a new deploy section with replicas: 5 but it's only for swarm mode.
Old Answer
docker-compose scale app=5
See docker compose up.
Then you only need this docker-compose file:
version: '2'
services:
app:
image: app
You can do it with replica as mentioned in Compose specification:
version: '3'
services:
worker:
image: dockersamples/examplevotingapp_worker
networks:
- frontend
- backend
deploy:
mode: replicated
replicas: 6
One can use docker-compose --compatibility up to make Docker accept a deploy section without using swarm.
The scale command is now deprecated, and you should use up instead.
docker-compose up --scale app=2
More details are on docker compose up.
You can do this:
version: "3.4"
services:
service1: &service_1
image: app
service2:
<<: *service_1
service3:
<<: *service_1
For more information on <<, see What is the << (double left arrow) syntax in YAML called, and where's it specified?.
Works for me well:
version: "3.9"
services:
web:
image: redis:6.2-alpine
...
deploy:
mode: replicated
replicas: 3
and run the command then:
docker-compose --compatibility up