techsvast.blogg.se - Monit docker containers

Monit docker containers update#
Monit docker containers code#

In practice I've tidied up the policy change code into its own script, but this will give the general idea: #!/bin/bash

I therefore reset the restart policy on those containers prior to starting new ones.įor example, here is how I start the Docker Tidy container itself, on the host. RUN chmod +x /etc/periodic/daily/docker-tidy.shĭocker rm -v $(docker ps -a -q -f status=exited)įinally, one drawback with my solution is that if the host is rebooted prior to a stopped container cleanup, those containers seem to restart as well. Of course, I used Docker for this here's the Dockerfile: # Docker build script for Docker TidyĬOPY bin/docker-tidy.sh /etc/periodic/daily/ In fact, the second option was much cleaner, and this was amplified by the fact that stopped container clean-up is not actually a priority - it is just to keep things tidy.

However, it started to feel like the wrong solution, since I'd be working around the core problem that it cannot cleanly get a Docker container process list. I started on the first of these, with the idea that the process supervisor Monit would be nice to use, partly because it is lightweight, and partly because I am familiar with it.

Use the Docker restart policy, and set up my own container deletion system.

Use the container auto-delete feature in Docker, and set up my own restart system.

Thus, I set out to resolve this problem in a simple fashion. One of my engineering principles is to know when one has reached a cognitive limit for stuffing in new information! I was advised in the comments to try Minikube, and although undoubtedly this can be spun up quickly, I feared that this would be a rabbit-hole of learning that would get me stuck in tar for weeks. I have an answer that is suitable for my current understanding of Docker. That's a bit hacky, but is something that I can understand easily if there is a problem with it. I could then scan that file using grep and the Monit CHECK PROGRAM system check. Off the top off my head, I could write a shell loop to write docker ps to a file every five seconds for a minute, and then run that on a Cron every minute. As indicated, I would like to find out the answer to whether a process supervisor like Monit would work. I would still quite like to see more lightweight solutions proposed, so I have a range of answers to choose from. Seeking a range of answersĪ very helpful comment has suggested I should look into Minikube, which apparently simplifies the setup of Kubernetes, even to the degree a suitably skilled individual can be up and running in five minutes. I could periodically clean old ones up using some sort of cron job, but that feels a bit hacky given that Docker can do it for me.

Monit docker containers update#

I suppose I could use docker update -restart never on old containers to prevent this happening, but then when my container stops, I am left with it lying around, and I'd just as soon have it auto-delete. I found that after rebooting the box, I would have 15 or so slightly-differing versions of the app running simultaneously, which is not the intention.

This means that Docker is being notified of a restart policy for each container. The reason why I want -rm is that during the Dockerisation process, I stop the currently running container, load a new version of the image, and re-run the above script. For example, I find Supervisor a bit heavyweight, but if that is more able to work with Docker, I am willing to use it. I'd be happy to use another tool if it proves robust. Can I get it to exec docker ps periodically, and match lines in the output? However, that checks the system process table, and not docker ps, and so it won't find something matching the specified string. START PROGRAM = "/root/docker/jonblog/host-start.sh" Could I use Monit here? I was hoping to be able to do something like: CHECK PROCESS jonblog MATCHING jonblog So, I thought I should drop the -restart flag, and then use a process manager to stop and start Docker containers. Containers should be immutable anyway - any state I wish to preserve, like media files and logs, will be written to volumes. If it dies then I expect the container to be removed, and a new fresh one created from the base image. I think my meaning is clear: if a container is not running (e.g. There are several Docker tickets that say this is sensible, but I don't understand it. A WordPress container looks like this: #!/bin/bashĮxport DOCKER_HOSTIP=`ifconfig docker0 | grep "inet addr" | cut -d ':' -f 2 | cut -d ' ' -f 1`Įcho "Connecting to database on Docker host $" There will be around 5-6 containers on it, and very little else, so the box can be trivially rebuilt as required.įor each app I have a start script. I have a general purpose VPS, and am Dockerising the apps on it.