# run a local image
make -f Makefile.omd-labs-centos start
# build a "local/" image without overwriting the consol/ image
make -f Makefile.omd-labs-centos build
# start just the bash
make -f Makefile.omd-labs-centos bash

Notice the section "Data volume check". In this case there were no host mounted data volumes used. The "start.sh" script has renamed all .ORIG folders to the original name in case there are no mounted volumes.

run a custom site

If you want to create a custom site, you have to build an own image:

clone this repository, cd into the folder containg the Dockerfile, e.g. omd-labs-centos

On the very first start, this folders will be created on the host file system.In that case, the start.sh synchronize ongoing through lsycnd the content into the volumes (etc.mount, local.mount, var.mount) from the original folders (etc, local, var):

On the next start the folders are not empty anymore and used as usual.

Checking available space on mount point

Before OMD starts, each of the three mount points (etc, local, var) can be checked for free available disk space to ensure that the container can store its data. The threshold can be given as an environent variable in the docker run command. If there is not enough space on any mount point, the startup script fails. On a container orchestration platform like OpenShift this should be handled by your deployment config (=the running pod only gets shutdown if the new pod was started properly).

Start OMD-Labs with data volumes

This starts the container with the three data volumes. Everything the container writes into one of those three folder, it will synchronized into the persistent file system.

(make startvol is just a handy shortcut to bring up the container. In Kubernetes/OpenShift you won't need this.)

Ansible drop-ins

For some time OMD-Labs comes with full Ansible support, which we can use to modify the container instance on startup. How does this work?

start sequence

By default, the OMD-labs containers start with the CMD /root/start.sh. This script

checks if there is a playbook.yml in $ANSIBLE_DROPIN (default: /root/ansible_dropin, changeable by environment). If found, the playbook is executed. It is completely up to you if you only place one single task in playbook.yml, or if you also include Ansible roles. (with a certain point of complexity, you should think about a separate image, though...)