Docker Commands

REDIRECT: This URL has changed to https://support8.gwos.com/gw/gw8/latest/administration/docker-commands
Click the link above if you are not automatically redirected in 10 seconds.

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

  • Important! Mistakes can be made when typing Docker commands. You may want to consider a system backup.
  • 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.

Commands

GroundWork Monitor commonly used docker and docker-compose commands.

Containers

docker ps

Provides a list of all running containers in Docker, not only GroundWork containers.

Example:
CONTAINER ID: 014412a170d1
IMAGE: groundworkdevelopment/cloudhub:8.1.0-GA COMMAND: "java -DGROUNDWORK_C…"
CREATED: 2 days ago
STATUS: Up 2 days (healthy)
PORTS: 8090/tcp
NAMES: dockergw8_cloudhub_1

docker ps -a

List all containers (including not running)

docker-compose ps

Provides a list of running GroundWork containers (services) in the current docker-compose.yaml deployment.

Example:
NAME: dockergw8_cloudhub_1 
COMMAND: java -DGROUNDWORK_CONFIG=/ ...
STATE: Up (healthy)
PORTS: 8090/tcp

docker-compose down

This command will stop the GroundWork system, remove containers, networks, volumes, and images created by docker-compose up.

docker-compose up -d

This command will start the GroundWork system, it will start containers in the background and leave them running, be certain to add the -d for detached mode background output.

docker-compose stop <service>

Gracefully stops a container (service) through proper shutdown. (Use docker-compose kill <service> when stop is not working). Remember service names are the short names for the containers as listed in gw8/docker-compose.yml.

Example:
docker-compose stop cloudhub

docker-compose kill <service>

Forces the stopping of a container (service).  Remember service names are the short names for the containers as listed in gw8/docker-compose.yml.

Example:
docker-compose kill cloudhub

docker-compose up -d <service>

Start an individual named service. Remember, service names are the short names for the containers as listed in gw8/docker-compose.yml.

Examples: 
docker-compose up -d cloudhub
docker-compose up -d revproxy
docker-compose up -d elasticsearch

docker-compose restart <service>

Restart an individual named service. Remember, service names are the short names for the containers as listed in gw8/docker-compose.yml.

Example: 
docker-compose restart cloudhub

docker-compose exec

Executes a command running in the specified container. (-u 1000 option puts you in the container named as the container's default user). Remember, service names are the short names for the containers as listed in gw8/docker-compose.yml.

Example 1:
You can run bash as in:
docker-compose exec -u 1000 nagios bash
This logs into the nagios container and runs a shell in the container OS. 

Example 2:
You can run psql (the postgres client in the container) as in:
docker-compose exec -u 1000 pg psql

Logs

docker-compose logs --tail=<#> <service>

Display a log file for a service. Remember service names are the short names for the containers as listed in gw8/docker-compose.yml.

Examples:
docker-compose logs --tail=125 groundwork
docker-compose logs --tail=50 cloudhub
docker-compose logs --tail=100 nagios

docker-compose logs -f --tail=<#>  <service>

Display and follow a log file for a service. Remember docker-compose ps to list containers, and docker-compose service names are the short names for the containers as listed in gw8/docker-compose.yml. Note: The .yml file should not be edited.

Example:
docker-compose logs -f --tail=125 groundwork
docker-compose logs -f --tail=50 cloudhub
docker-compose logs -f --tail=100 nagios

docker container logs <option> <containerID>

Enter command with option and container ID. You can find the container ID with docker ps. Below lists 10 logs for the containerID specified.

Example:
docker container logs --tail 10 48d2eeca14c6

docker-compose exec <service>

By default, access logging is disabled on all containers. However, there are Docker commands to enable them temporarily for diagnostic reasons. As logging is more expensive with the ELK Stack integrated, access to 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. Remember, service names are the short names for the containers as listed in gw8/docker-compose.yml.

Examples: (commands may display wrapped)
# main rail, (revproxy)
docker-compose exec revproxy /src/docker_cmd.sh enableAccessLogging
docker-compose exec revproxy /src/docker_cmd.sh disableAccessLogging

# dalek
docker-compose exec dalek /src/docker_cmd.sh enableAccessLogging
docker-compose exec dalek /src/docker_cmd.sh disableAccessLogging

# monarch
docker-compose exec monarch /src/docker_cmd.sh enableAccessLogging
docker-compose exec monarch /src/docker_cmd.sh disableAccessLogging

# rstools
docker-compose exec rstools /src/docker_cmd.sh enableAccessLogging
docker-compose exec rstools /src/docker_cmd.sh disableAccessLogging

# nedi
docker-compose exec nedi /src/docker_cmd.sh enableAccessLogging
docker-compose exec nedi /src/docker_cmd.sh disableAccessLogging

# nagios-ui
docker-compose exec nagios-ui /src/docker_cmd.sh enableAccessLogging
docker-compose exec nagios-ui /src/docker_cmd.sh disableAccessLogging

Docker Access

docker

Verify access to Docker

docker-compose

Verify access to Docker Compose
Volumes

docker volume ls

List all volumes

Versions

docker -v

Show Docker version

docker-compose -v

Show Compose version

Cloud Hub Connections

docker-compose exec cloudhub bash -c

This command will give you a line of output for each deployed connector instance, and will also show you the display name so you can disambiguate multiple deployments of the same connector type.

Example: (commands may display wrapped)
docker-compose exec cloudhub bash -c 'grep -r displayName /usr/local/groundwork/config/cloudhub/*'

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.

NeDi example

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:

from:

#module System Database db adm

to:

module System Database db adm

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. This is easily done using the following steps:

  1. Access the command line as the gwos user and change to the gw8 directory: 

    $ cd gw8

  2. Edit the file with the following command: 

    docker-compose exec nedi vi /usr/local/groundwork/config/nedi/nedi.conf

    This will put you in a vi session on the container. 

  3. Search for the module line by typing "/" and a search term, e.g: 

    /Database

  4. Remove the comment at the start of the module line: 

    # Database allows direct access to the nedi database.  Off by default.
module System          Database                db      adm

  5. The file should then be saved, e.g. type:

    :wq

Such changes are preserved across upgrades. 

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!


NOT preserved

Many edits, additions and deletions of files are NOT preserved, but will be reverted on upgrades or even on restarts. To be preserved, the changes must occur on a shared volume, such as /usr/local/groundwork/config. 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.


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

docker-compose exec -u 1000 nagios bash

or

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.

Container directories

The directories you can access will vary by container.

For NoMa:

/usr/local/noma/etc

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

For the Nagios container, the directories:

/usr/local/nagios/etc
/usr/local/nagios/libexec

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:

  • application-users.properties
  • check_cacti.conf
  • cloudhub-log4j.xml
  • cloudhub-logback.xml
  • cloudhub.properties
  • db.properties
  • event-feeder.conf
  • foundation-log4j.xml
  • foundation.properties
  • groundwork.lic
  • influxdb.properties
  • install.properties
  • ldap.properties
  • log-archive-receive.conf
  • log-archive-send.conf
  • menu.json
  • perfdata.properties
  • register_agent_by_discovery.conf
  • register_agent.properties
  • statistics-feeder.conf
  • status-feeder.properties
  • ws_client.properties
  • 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.