monit on docker with arm support

Henning Bopp

I would not see a real benefit of this, since (for me) monit should be as close to your init service as possible. Two reasons:

If you run monit as a container, monit will not be able to monitor (nor control) the container daemon itself. So if your docker goes down, your monit goes down as well and will not be able to do anything about it. If your monit is on the same level as dockerd, it could restart the daemon in case of an error.

Secondly, your monit will not easily be able to interact with any kind of service on your docker host (or any other container), nor have access to storage, net, or anything close to the bare metal. So you could for sure use monit to ping a website, but in order to enable monit to handle anything on the host system itself, you have to manually weaken the docker security or (that would be funny) log in to your host using a SSH connection. Doesn't really sound like something one should do. ;)

But since I'm not (only ^^) here to question your decision, a dockerized monit can be made easily with a Dockerfile like

FROM alpine
RUN apk --no-cache add monit
CMD ["monit","-I"]

When starting your container, you need to provide the monitrc (and, optionally, monit's id file):

docker build -t my/monit .
docker run -d \
    -v /path/to/monitrc:/etc/monitrc \
    -v /path/to/.monit.id:/root/.monit.id \
    my/monit

Keep in mind, that the monitrc file may not have permissions above 0700, nor should the id file (0400 should be the way to go in this case). If you have configured monit to use a state file this file should be on tmpfs or manually deleted in case the daemon shutdown was harsh.

Hope that helps.

2021-01-27T20:27:34+00:00

Comments (2)

Henning Bopp
I would not see a real benefit of this, since (for me) monit should be as close to your init service as possible. Two reasons:

If you run monit as a container, monit will not be able to monitor (nor control) the container daemon itself. So if your docker goes down, your monit goes down as well and will not be able to do anything about it. If your monit is on the same level as dockerd, it could restart the daemon in case of an error.

Secondly, your monit will not easily be able to interact with any kind of service on your docker host (or any other container), nor have access to storage, net, or anything close to the bare metal. So you could for sure use monit to ping a website, but in order to enable monit to handle anything on the host system itself, you have to manually weaken the docker security or (that would be funny) log in to your host using a SSH connection. Doesn't really sound like something one should do. ;)

But since I'm not (only ^^) here to question your decision, a dockerized monit can be made easily with a Dockerfile like
```
FROM alpine
RUN apk --no-cache add monit
CMD ["monit","-I"]
```
When starting your container, you need to provide the monitrc (and, optionally, monit's id file):
```
docker build -t my/monit .
docker run -d \
    -v /path/to/monitrc:/etc/monitrc \
    -v /path/to/.monit.id:/root/.monit.id \
    my/monit
```
Keep in mind, that the monitrc file may not have permissions above 0700, nor should the id file (0400 should be the way to go in this case). If you have configured monit to use a state file this file should be on tmpfs or manually deleted in case the daemon shutdown was harsh.

Hope that helps.
- 2021-01-27T20:27:34+00:00
Tildeslash repo owner
- changed status to closed
We don’t plan to maintain a docker image ourselves currently. The recipe by Henning is great.
- 2021-02-01T17:53:20+00:00
Log in to comment