There are numerous reasons why many users would want to operate software in a Docker container. Checkmk in version VERSION[1.6.0] can also officially be used in a Docker environment. One application case may be to monitor a dynamically-created container group and to make Checkmk a part of this group. Should the container group no longer be needed the Checkmk instance can also be removed.
Important: Even it is possible and very easy to integrate Checkmk into a containerized infrastructure, it is not always the best solution. Since you get a reduced performance with every virtualization also your monitoring in general should have a minimum of physical dependencies, it is not a good solution to use a Checkmk container to monitor your complete infrastructure. But it may be a good one, to integrate a Checkmk container in a self-contained container cluster, because in this case you would be able to monitor this cluster from the inside. So verify expecially in this case if the tool Docker/Container is the best to fit your actual requirements.
In order to make the setting-up as easy as possible for you, we supply each Checkmk-Edition inclusive of its own specific image. In addition to Checkmk as the Linux operating system, Debian 9 (Stretch) is also included. These are sourced as follows:
Checkmk Raw Edition
Checkmk Enterprise Editions
In this article we will guide you through the installation of Checkmk in Docker, and show a few tricks that will make life with Checkmk in Docker easier.
Further detailed information to running Checkmk in a Docker container can be found in the article Checkmk server in a Docker container.
Getting started with the Checkmk Raw Edition in Docker is easy. You
can get a suitable image directly from the Docker Hub. This is done with just a
single command on the command line.
With this command not only will a Docker container with Checkmk be created, but also a monitoring instance named
cmk is set up and started. This instance will be immediately available for a login as the
root@linux# docker container run -dit -p 8080:5000 --ulimit nofile=1024 --tmpfs /opt/omd/sites/cmk/tmp:uid=1000,gid=1000 -v monitoring:/omd/sites --name monitoring -v /etc/localtime:/etc/localtime:ro --restart always checkmk/check-mk-raw:1.6.0-latest Unable to find image 'checkmk/check-mk-raw:1.6.0-latest' locally 1.6.0-latest: Pulling from checkmk/check-mk-raw 8f91359f1fff: Pull complete 3d794619eec5: Pull complete 1468b0cb296b: Pull complete 787a36ef0a12: Pull complete 159fac9366a1: Pull complete fefc9fe50b26: Pull complete Digest: sha256:153b6a6b4002cc0e02c17e127f582fa54a539803960d36d265802426c0066aa8 Status: Downloaded newer image for checkmk/check-mk-raw:1.6.0-latest 511cd26bdc2847ee5b430a1c0c52ff4489b3556775d07878b0533df077b67a83
Some more information on the available options:
By default the container’s web server listens on port 5000. In this example port 8080 of the Docker node will be bound to the port of the container so that it is accessible from outside. If you do not have another container or process using the standard HTTP port 80, you can also tie the container to it. In such a case the option will look like this:
By manually-setting the user limit (ulimit) for ‘nofile’, you are able to reduce the amount of file descriptors a process is able to open. That is especially useful in this case, as Checkmk still uses Python 2 which uses a very high default. This can significantly slow the process down.
From version VERSION[1.6.0] for optimal performance you can use a temporary file system directly in the RAM of the Dockernode. The path of this file system is specified with this option. If you change the instance ID this path must also be adjusted accordingly.
This option binds the data from the instance in this container to a persistent location in the Docker node’s file system. The data is not lost if the container is deleted. The code before the colon determines the name — in this way you can clearly identify the storage location later, for example, with the
This defines the name of the container. This name must be unique and may not be used again on the Docker node.
This option allows you to use the same time zone in the container as that used in the Docker node — at the same time the file is integrated as read only (ro).
A container does not normally restart automatically after it has been stopped. With this option you can ensure that it always starts again automatically.
The Checkmk-Image in Repository:Tag format; the exact labels can be read out with the command
After all needed files have been loaded and the container has been started, you should access the GUI in Checkmk via
You can now log in for the first time
and try Checkmk out. You will find the provisional password for the
account in the logs that are written for this container (the output is
abreviated to the essential information here in this example):
root@linux# docker container logs monitoring Created new site cmk with version 1.6.0.cre. The site can be started with omd start cmk. The default web UI is available at http://c395cfe2d50d/cmk/ The admin user for the web applications is cmkadmin with password: erYJR0IT (It can be changed with 'htpasswd -m ~/etc/htpasswd cmkadmin' as site user.)
If you are sure that the data in the Checkmk container instance should only be available in this special container, you can either refrain from assigning a persistent data storage to the container, or you can automatically remove this storage when the container is stopped. To go without persistent storage, simply omit the
-v /omd/sites option. To create a persistent storage and remove it automatically when the container stops, use the following command:
root@linux# docker container run --rm -dit -p 8080:5000 --tmpfs /opt/omd/sites/cmk/tmp:uid=1000,gid=1000 --ulimit nofile=1024 -v /omd/sites --name monitoring -v /etc/localtime:/etc/localtime:ro checkmk/check-mk-raw:1.6.0-latest 3d7f04bc7d0a1ded5fb5ab49e3c72894615a2058c5df2d7af11e20f4662b5c09
This command — unlike the one above — has only two other options:
--rmoption at the start to pass the command that the data storage for the container should also be removed when the container stops. This saves you having to tidy-up manually if you have many short-lived Checkmk containers. Note: When stopping, the container itself is completely removed!
-v /omd/sitesoption is altered compared to the above. It no longer contains a self-assigned name, otherwise the data storage will not be deleted correctly.
You can also run the Enterprise Editions in a Docker container. These are not freely-available through Docker Hub. You can currently download the desired version from our Download page, and load its image in Docker:
root@linux# docker load -i check-mk-enterprise-docker-1.6.0p18.demo.tar.gz 333e2cb4c707: Loading layer [==================================================>] 58.49MB/58.49MB bbfed64bbcfc: Loading layer [==================================================>] 2.048kB/2.048kB 9404c04f9b0e: Loading layer [==================================================>] 262.2MB/262.2MB d0dbf2463465: Loading layer [==================================================>] 146.5MB/146.5MB c614fb908387: Loading layer [==================================================>] 686.7MB/686.7MB 5fb3a3a79488: Loading layer [==================================================>] 5.632kB/5.632kB Loaded image: checkmk/check-mk-enterprise:1.6.0p18.demo
After the download you can start the container with a very similar command to that
described above. Just take care to specify the Standard Edition or Managed Services Edition image in this case
root@linux# docker container run -dit -p 8080:5000 --ulimit nofile=1024 --tmpfs /opt/omd/sites/cmk/tmp:uid=1000,gid=1000 -v monitoring:/omd/sites --name monitoring -v /etc/localtime:/etc/localtime:ro --restart always checkmk/check-mk-enterprise:1.6.0p18.demo 6aef65edaa7f1409d218c3259d1009c1abdd424494a169565eac342bd5e1a29b
You can also find the password here in the logs.