Unmark /opt/nagios/etc as a docker volume?

[luc-tielen]

At work we are migrating our nagios server to a dockerized setup using this docker container.
However, we are currently limited to an image without access to any external volumes.
This is giving us problems because docker undos all changes that are made to files located in a folder that is also marked as a volume (such as /opt/nagios/etc).

Would it be possible to unmark this folder as a volume?
Pro would be that the config could be copied / modified directly inside the docker container, reducing the complexity of the setup.
Con would be that existing users that already use a volume now would have to add a volume directive for /opt/nagios/etc in their Dockerfile.

[JasonRivers]

I would not recommend storing any data in the container itself, this is why the locations are volumes. The reason for this is whenever you come to upgrade your container to a newer version,m you'll have to copy all your configs in each time, If they're stored in a volume or with a bind-mount, then you're able to upgrade the nagios container without worrying about the configurations.

A better way to do this if you really can't use a bind mount would be to create the volume for the nagios config.

The compose would look like this:

version: '3'
services:
  nagios:
    image: jasonrivers/nagios:latest
    volumes:
    -  nagiosconfig:/opt/nagios/etc

volumes:
  nagiosconfig:

You could then copy whatever you want in to /opt/nagios/etc.

[crisp2u]

@JasonRivers I ended up forking your repo, i had the same issue. I removed the volume for etc, used this as a base image and created a container with all the .conf files that we need. The goal was to have all the configuration in a git repo, and build and redeploy the container on each change. We did not want to depend on deploying the configuration files on the host. So upgrading for us is rebuilding the base image. I'm not sure I understand your solution described in the compose file. Also, I know you are doing some "magic" at runtime to copy configs around but that did not worked for me either

[junoteam]

@JasonRivers @crisp2u Hi, we have the same issue here. And I personally think that you should unmark directories like: /opt/nagios/etc to be a volume.

It's directory not for data, it's more about configurations, and it's okay to store configurations inside a docker container.

In my case, we have GIT repo with bulk of docker containers congfigurations and Slack bot with Jenkins for CD. So when I add new server to be monitored by Nagios, I simply add newhost.cfg to servers/ directory and deploy Nagios docker with a bot. I use Swarm cluster, so all my dockers should not do any external mounts to host machine.

Like you know configs aren't really data. They can be persistent and stored inside docker containers, in my opinion.

[JasonRivers]

While I agree that /opt/nagios/etc is configuration, it is not, however, configuration for the application. This is configuration that is specific to ones network, It is vastly different between each user. The correct way to deal with these configurations is to use a volume container If you do not use a volume container and rely on copying your configuration in to the image, then you must do this process every time there is an upgrade to the image. When using a volume container you simply stop the old image and start the new one and all of your configuration is already in the new container from the mounted volume.

Please see https://docs.docker.com/storage/volumes for more information on volumes and volume containers.

[JasonRivers]

I don't see the /opt/nagios/etc being tagged as a volume being a problem even for the way you explain you wish to use this image. ran the following test:

#!/bin/bash

echo "Run container"
docker run -dit --name nagios-pr52-test jasonrivers/nagios

echo "current configuration:"
docker exec -it nagios-pr52-test ls -l /opt/nagios/etc
 
echo "use docker cp to copy configs in to container"

docker cp nagios-configuration/. nagios-pr52-test:/opt/nagios/etc/.

echo "check new configuration is in container"

docker exec -it nagios-pr52-test ls -l /opt/nagios/etc

echo "Stop the container"

docker stop nagios-pr52-test

echo "Start the container"
docker start nagios-pr52-test

echo "check new configuration is still correct"

docker exec -it nagios-pr52-test ls -l /opt/nagios/etc

The output is as follows:

./test-52.sh 
Run container
86e68731d8ca6f5ff88fb2e34d478c78263a4f39d0cc29714262606e9120ce40
current configuration:
total 76
-rw-r--r-- 1 root   root   11655 Feb 20 09:50 cgi.cfg
drwxr-xr-x 2 root   root    4096 Feb 20 10:06 conf.d
-rw-r--r-- 1 nagios nagios    46 Mar 15 11:11 htpasswd.users
drwxr-xr-x 2 root   root    4096 Feb 20 10:06 monitor
-rw-r--r-- 1 root   root   44603 Feb 20 10:07 nagios.cfg
drwxr-xr-x 2 root   root    4096 Feb 20 09:50 objects
-rw-rw---- 1 nagios nagios  1300 Feb 20 10:00 resource.cfg
use docker cp to copy configs in to container
check new configuration is in container
total 104
-rw-r--r-- 1 root root 11652 Mar 15 11:06 cgi.cfg
drwxr-xr-x 2 root root  4096 Mar 15 11:06 commands
drwxr-xr-x 2 root root  4096 Feb 20 10:06 conf.d
drwxr-xr-x 2 root root  4096 Mar 15 11:06 contacts
drwxr-xr-x 2 root root  4096 Mar 15 11:06 hosts
-rw-r--r-- 1 root root   139 Mar 15 11:06 htpasswd.users
drwxr-xr-x 2 root root  4096 Feb 20 10:06 monitor
-rw-r--r-- 1 root root 41341 Mar 15 11:06 nagios.cfg
drwxr-xr-x 2 root root  4096 Feb 20 09:50 objects
-rw-r--r-- 1 root root   449 Mar 15 11:06 resource.cfg
-rw-r--r-- 1 root root   242 Mar 15 11:06 resource.example.cfg
drwxr-xr-x 2 root root  4096 Mar 15 11:06 services
drwxr-xr-x 2 root root  4096 Mar 15 11:06 templates
-rw-r--r-- 1 root root   651 Mar 15 11:06 timeperiods.cfg
Stop the container
nagios-pr52-test
Start the container
nagios-pr52-test
check new configuration is still correct
total 104
-rw-r--r-- 1 root root 11652 Mar 15 11:06 cgi.cfg
drwxr-xr-x 2 root root  4096 Mar 15 11:06 commands
drwxr-xr-x 2 root root  4096 Feb 20 10:06 conf.d
drwxr-xr-x 2 root root  4096 Mar 15 11:06 contacts
drwxr-xr-x 2 root root  4096 Mar 15 11:06 hosts
-rw-r--r-- 1 root root   139 Mar 15 11:06 htpasswd.users
drwxr-xr-x 2 root root  4096 Feb 20 10:06 monitor
-rw-r--r-- 1 root root 41341 Mar 15 11:06 nagios.cfg
drwxr-xr-x 2 root root  4096 Feb 20 09:50 objects
-rw-r--r-- 1 root root   449 Mar 15 11:06 resource.cfg
-rw-r--r-- 1 root root   242 Mar 15 11:06 resource.example.cfg
drwxr-xr-x 2 root root  4096 Mar 15 11:06 services
drwxr-xr-x 2 root root  4096 Mar 15 11:06 templates
-rw-r--r-- 1 root root   651 Mar 15 11:06 timeperiods.cfg

Stopping and starting the container does not remove the configuration, The code in the container only copies example config to /etc if the directory is empty, if the directory is not empty it doesn't copy anything. As far as I can tell, the container will work exactly how you want it to with zero modifications.

[luc-tielen]

Except we don't do docker cp.
The problem occurs if you try to do "RUN ..." inside a Dockerfile that uses this a base image.
If the RUN command changes a file inside a directory marked as a volume (e.g. cp, sed, ...); then docker will discard changes..

More info at: https://docs.docker.com/engine/reference/builder/#volume

Changing the volume from within the Dockerfile: If any build steps change the data within the volume after it has been declared, those changes will be discarded.

[JasonRivers]

Please could you paste the contents of your Dockerfile. I'd like to understand why you're doing it this way.
The way this image was designed is to allow the user to include their own configuration, their own plugins, etc. So I'm having trouble understanding why you are using FROM.

[luc-tielen]

Sorry for delayed response.
A rather minimal example:

FROM jasonrivers/nagios:latest

# ... prepare container, copy files into right places ...

# Modify a file inside a volume, for example to change default nagios user:
RUN sed -i s/nagiosadmin/my_custom_user/g /opt/nagios/etc/cgi.cfg

# ... more config ...

This gives us a self-contained (pardon the pun) container, no need for volumes (which we can't use in our setup).
All we need to do is deploy the docker container and it will start running and do it's thing.

However, with current setup, the file will not be changed due to the reason I posted earlier.

[JasonRivers]

Closing as the recommended way is to use a volume container of mounted volume.