I am using docker-compose to deploy an application combining a number of different images.
Using Docker version 18.09.2, build 6247962
Docker-compose 1.117
Primarily, I have
ZooKeeper
Kafka
MYSQLDb
I notice a strange problem where i could not start my application with docker-compose up due to port already being assigned. I then checked docker stats and saw that there were three containers named "test_ZooKeeper.1slehgaior"
"test_Kafka.kgjdorgsr"
"test_MYSQLDB.kgjdorgsr"
I have tried kill the containers, removing them and pruning the system. When ever I kill one of these containers, it instantly restarts and I cannot for the life of me determine where they are being created from!
Please help :)
If you look into your docker-compose.yaml I'm pretty sure you'll find a restart:always somewhere. If you want to correctly shut down a running docker container managed by docker-compose, one way is to use docker-compose down from the directory where your yaml sits.
More information on the subject:
https://docs.docker.com/config/containers/start-containers-automatically/
Otherwise, you might try out to stop a single running container instead of killing it, which according to my memory tells docker not to restart it again, while a killed container looks to the service like it just has crashed. Not too sure about the last part though.
Related
I have a docker compose yml file with a few containers defined:
database
web-service
I have 'depends_on' defined in 'web-service' to start after 'database'. Both containers are defined with 'restart always'.
I've been googling and cannot find clear info on container startup order on system reboots. Does the docker daemon read the docker-compose yml file and start the database and then web-service? Or how does it work?
If you want to start the containers on system startup you have to setup a some kind of "scheduled" job using e.g. Linux's CRON daemon.
Docker daemon itself is not responsible for waking-up containers, restart entry in compose file refers to e.g. restarting on crash of app in the container, after ending a job (which terminates terminal) and so on.
Please find the restarts explanation of docker docs https://docs.docker.com/config/containers/start-containers-automatically/#restart-policy-details
containers are started according to depends_on contraints.
on reboot too.
but you should not rely on it too much.
you can just let your web service crash when he has no acces to the db. docker will restart it automatically and it will retry. (it's cheap)
if you want to deal with it more safely/precisely, you can also wait for the port to be accessible using a script like this one.
https://github.com/vishnubob/wait-for-it
docker explains it in his documentation : https://docs.docker.com/compose/startup-order/
that way you garanty way more than depends_on. because depends only ganranty order, not that to service is ready or even working.
I'm new to docker-compose. Before, when I started containers manually, after a host reboot I had to start the containers manually.
Today I found that -after a host reboot- I had 4 containers running. Those were previously started with docker-compose.
But docker-compose does not work well unless you are in the proper directory with the docker-compose.yml.
Question
How can I know what docker-compose.yml or (which path) was used to launch the docker containers that I find already started as soon as I login after a reboot?
I tried
docker inspect xxxxx
but I could not find any clue on what docker-compose.yml was used to launch.
docker-compose is not starting anything.
The Docker daemon is starting containers on which you have set a restart policy (possibly in one of your docker-compose.yaml files). You can simply remove these containers (docker container rm ...) if you don't need them anymore, or you can reset the restart policy using docker container update --restart=no <image_name_or_id>.
You can read more about restart policies here.
But docker-compose does not work well unless you are in the proper directory with the docker-compose.yml.
Since docker-compose isn't involve at this stage (it may have been responsible for creating the containers but it is not responsible for restarting them), this isn't a problem. Setting an appropriate restart policy on your containers via your docker-compose.yml is the correct way to enable containers to start at boot.
You can set a restart policy when you start a container using docker run by including the appropriate --restart=<policy> option on the command line.
in compose file use restart: always to run after machine is rebooted
services:
service1:
image: serice1:latest
restart: always
I use docker-compose to start a set of unrelated docker containers. I use docker-compose for that because of the ease of configuration via docker-compose.yaml and the centralized configuration this file brings.
One problem I have is the update of images, or actually of containers after an image update. I update them via docker-compose pull but the containers previously spawned do not restart by themselves. I have two possible solutions, both doable but none ideal:
restart all the containers after a pull. This would introduce unavailability which is not a critical thing in my home environment but still (especially Home Assistant restarting is a pain as the lights are reset)
write some code to check which images IDs have changed during the pull and restart the relevant containers (removing them first). This is the solution I will be using if there is nothing better.
I was wondering if there was a better soution.
This is a home environment so I would like to avoid heavy duty solutions such as Kubernetes.
Swarm mode could work but I just read about it and it looks more like a solution to ensure state more than a containers manager (in the sense that it would restart containers based on the freshness of the image they were spawned from).
After you docker pull image, docker-compose -f "docker-compose.yml" up -d will only restart the containers for which there is a new version of the image after the docker pull. It will not impact the containers whose image stays the same. This setup works fine for me.
docker-compose up --force-recreate -d
if there are existing containers for a service, and the service’s
configuration or image was changed after the container’s creation,
docker-compose up picks up the changes by stopping and recreating the
containers (preserving mounted volumes). To prevent Compose from
picking up changes, use the --no-recreate flag.
If you want to force Compose to stop and recreate all containers, use
the --force-recreate flag.
docker-compose up -CLI
NOTE:Recreate containers even if their configuration and image haven't changed.
When starting a docker container (not developed by me), docker says a network has not been found.
Does this mean the problem is within the container itself (so only the developer can fix it), or is it possible to change some network configuration to fix this?
I'm assuming you're using docker-compose and seeing this error. I'd recommend
docker-compose up --force-recreate <name>
That should recreate the containers as well as supporting services such as the network in question (it will likely create a new network).
shutdown properly first, then restart
docker-compose down
docker-compose up
I was facing this similar issue and this worked for me :
Try running this
- docker container ls -a and remove the container id by docker container rm ca877071ac10 (this is the container id ).
The problem was there were some old container instances which were not removed. Once all the old terminated instances get removed, you can start the container with docker-compose file
This can be caused by some old service that has not been killed, first add
--remove-orphans flag when bringing down your container to remove any undead services running, then bring the container back up
docker-compose down --remove-orphans
docker-compose up
This is based in this answer.
In my case the steps that produced the error where:
Server restart, containers from a docker-compose stack remained stopped.
Network prune ran, so the network associated with stack containers where deleted.
Running docker-compose --project-name "my-project" up -d failed with the error described in this topic.
Solved simply adding force-recreate, in this way:
docker-compose --project-name "my-project" up -d --force-recreate
This possibly works because with this containers are recreated linked with the also recreated network (previously pruned as described in the pre conditions).
Apparently VPN was causing this. Turning off VPN and resetting Docker to factory settings has solved the problem in two computers in our company. A third, personal computer that did not have VPN never showed the problem.
Amongst other things docker system prune will remove 'all networks not used by at least one container' allowing them to be recreated next docker-compose up
More precisely docker network prune can also be used.
I'm trying to teach myself about Docker and using the docker-compose.yml to play around with images and the compose file. I've got the Wordpress image up and running using successfully docker-compose.yml up -d via the tutorial here... https://docs.docker.com/compose/wordpress/), but as soon as I make changes to the compose file and docker-compose.yml up -d again I can't access the changes again and have to completely delete images/containers/docker machine's to get my changes to work.
What am I doing wrong, what's the process to restart/delete the minimum amount to see my docker-compose.yml changes so I can play around with docker-compose.yml?
docker-compose stop to stop the stack
docker-compose start to start the stack
Both above will not remove your container, but rather shutdown and start them again, without any loses, even on the container filesystem, not only the volumes
docker-compose down will remove the containers of your services and all anonymous volumes assigned to them.
Be aware, not all changes in the docker-compose file can be applied using start/stop, rather most of the time, you have to do a down/up. Things like volumes/ports cannot be hot-applied like this.