Docker Commands

Using Docker commands

Mistakes can be made when typing Docker commands. You may want to consider a system backup.

Compose CLI (docker-compose) and Docker CLI (docker)

  • For additional reference see Compose command-line reference and Docker commands
  • You can also see this information by running docker-compose [SUBCOMMAND] --help from the command line

    You will need to be in your GroundWork Monitor 8 installation directory (e.g., gw8) before executing commands.


docker psList running Docker containers
docker ps -aList all Docker containers
docker versionShow Docker version
docker volume lsList all volumes
docker container lsList all containers
docker container logs [Options] {ContainerID}Enter command with option and container ID.
e.g., docker container logs --tail 10 48d2eeca14c6
docker-compose --versionShow Compose version
docker-compose psCheck status of GroundWork containers
docker-compose downStop GroundWork system
Stop and remove containers, networks, volumes, images created by docker-compose up
docker-compose up -dStart GroundWork system
Start containers in the background and leave running, be certain to add the -d for detached mode background output
docker-compose kill <container name>Stop individual container
Stop the named container, e.g., docker-compose kill cloudhub
docker-compose up -d <container name>Start individual container
Start the named container, e.g., docker-compose up -d cloudhub
docker-compose logsDisplay log output from services
docker-compose logs -fDisplay and follow log output from services
docker-compose logs <service>Display log output for a service, e.g., cloudhub
Service names are the short names for the containers as listed in gw8/docker-compose.yml
docker-compose logs -f <service>Display and follow log output for a service, e.g., cloudhub. Remember docker-compose ps to list containers, and for docker-compose service names are the short names for the containers as listed in gw8/docker-compose.yml e.g., docker-compose logs -f nagios. Note: The .yml file should not be edited.
docker container logs [Options] {ContainerID}Enter command with option and container ID
e.g., docker container logs --tail 10 48d2eeca14c6
docker-compose exec <service>Enable logging on all containers
By default, access logging is disabled on all containers. However, there are docker commands that can be issued to enable them temporarily for diagnostic reasons. As logging is more expensive with the ELK stack integrated, access logs should not be left on during normal operation. Containers log independently, so any combination of the containers below can be enabled/disabled. Normally, revproxy access logging is sufficient to debug client/server communications. Issue commands from the installation directory, e.g., gw8.

# main rail, (revproxy)
docker-compose exec revproxy /src/ enableAccessLogging
docker-compose exec revproxy /src/ disableAccessLogging

# dalek
docker-compose exec dalek /src/ enableAccessLogging
docker-compose exec dalek /src/ disableAccessLogging

# monarch
docker-compose exec monarch /src/ enableAccessLogging
docker-compose exec monarch /src/ disableAccessLogging

# rstools
docker-compose exec rstools /src/ enableAccessLogging
docker-compose exec rstools /src/ disableAccessLogging

# nedi
docker-compose exec nedi /src/ enableAccessLogging
docker-compose exec nedi /src/ disableAccessLogging

# nagios-ui
docker-compose exec nagios-ui /src/ enableAccessLogging
docker-compose exec nagios-ui /src/ disableAccessLogging

Advanced mode

Configuring the details

In many cases, no additional configuration beyond what is possible in the user interface will be needed. There are, however, some areas of the system that support customizations and tuning. If you are an advanced user, you will need to access these to get the most out of your system. To use these customizations and make tuning changes, you will need to edit some of the files the system uses to control the applications, settings, and parameters.

For example, we ship the NeDi application with no access to the database snapshot interface. If you want to use it, you must change the following line (un-comment) in the file /usr/local/groundwork/config/nedi/nedi.conf:


#module System Database db adm


module System Database db adm

The file should then be saved, and the permissions should be left at -rw-rw-r-- 1 nedi nedi. That is, owned by the nedi user.

Such changes are preserved across upgrades.

NOT preserved

Additions of files and deletions of files are NOT preserved, but will be reverted on upgrades. This ensures we can provide you with a secure, functional system with minimal instability.

While we are working on adding more ways to configure GroundWork Monitor to the user interface, we expect for the foreseeable future some aspects will require command line editing of configuration files, and possibly the restarting of containers. The following instructions are provided to enable you to make these changes safely and without having to master too many new commands.

Generally speaking, you will want to have your GroundWork Monitor 8 system running, and use a docker feature called docker exec to make changes in the containers. Don't try to go around the containers and access the files directly on the file system. The containers are there for your protection, and will help you to be efficient in your editing.

So, to make the change described above, type:

cd gw8
docker-compose exec -u 1000 nedi bash

This will place you at a shell in the container as the nedi user, e.g.,:


Change to the mounted configuration volume directory for nedi:

cd /usr/local/groundwork/config/nedi

Edit the file with vi:

vi nedi.conf

Make the change(s) and save the file. It is then good practice to check that it is still at the native permissions:

ls -la nedi.conf

You should see something like this:

-rw-rw-r-- 1 nedi nedi 21706 Dec 3 21:32 /usr/local/groundwork/config/nedi/nedi.conf

Leave the shell:


NeDi makes immediate use of the changes you make to its settings file. There's no need to restart the container in this case. You are done!

Using similar procedures, you can access the nagios and noma_daemon containers, for example:

docker-compose exec -u 1000 nagios bash


docker-compose exec -u 1000 noma_daemon bash

Using the -u 1000 option puts you in the container as the container's default user (nedi, nagios, noma, etc.). If you leave it out, you will get a root shell, which is not recommended, since you can easily make a change that will leave your container (and perhaps the entire monitoring system) inoperable.

The directories you can access will vary by container.

For NoMa:


contains the NoMa.Yaml file that can be customized to add custom methods, for example.

For the Nagios container, the directories:


are useful for testing, and custom settings, though we caution against adding custom plugins to your system. They will vanish on upgrade!

A better way is to use GDMA (see GDMA documentation).

The global settings can be configured by making changes to the files in /usr/local/groundwork/config.

Configuration files available:

  • check_cacti.conf
  • cloudhub-log4j.xml
  • cloudhub-logback.xml
  • event-feeder.conf
  • foundation-log4j.xml
  • groundwork.lic
  • log-archive-receive.conf
  • log-archive-send.conf
  • menu.json
  • register_agent_by_discovery.conf
  • statistics-feeder.conf
  • cloudhub-docker-3.xml

In addition, there are subdirectories that contain more files and templates that you can manage:

  • /certs
  • /cloudhub
  • /migrations
  • /nedi
  • /profiles
  • /rstools
  • /vema

Comments and backups

The thing to remember is that changing these settings files can affect multiple aspects of the system. Make sure you comment your changes so they are easily reversible, and make regular backups of the system so you can revert the whole thing if you make a catastrophic change.