Public | Automated Build

Last pushed: 2 months ago
Short Description
Just enough to get process supervision and startup mechanisms
Full Description


Provides base OS, security patches, and tools for quick and easy spinup.


Ubuntu container OS is in use by default

— Alpine builds available tagged as -alpine
— Centos builds available tagged as -centos


  • S6 process supervisor is used for only for zombie reaping (as PID 1), boot coordination, and termination signal translation
  • Goss is used for build-time testing
  • Dgoss is used for run-time testing.


To add a service to be monitored, simply create a service script:
For programmatic switches, create the service in /etc/services-available, and symlink to /etc/services.d to enable


A convenience script is provided for security-only package updates.

On Ubuntu and CentOS-based variants, run:
/bin/bash -e /

This file is actually a symlink to the variant-specific script contained in the /scripts folder

NOTE: for Alpine variant, which is security-conscious, but does not have a mechanism to isolate security-specific updates, use apk update && apk upgrade as a generic alternative.


A convenience script is provided for post-package installation cleanup

On all variants, run:
/bin/bash -e /

This file, like security_updates (above) is actually a symlink to the variant-specific script contained in the /scripts folder

Environment Variables

Variable Example Description
S6_KILL_FINISH_MAXTIME S6_KILL_FINISH_MAXTIME=1000 Wait time (in ms) for zombie reaping before sending a kill signal
S6_KILL_GRACETIME S6_KILL_GRACETIME=500 Wait time (in ms) for S6 finish scripts before sending kill signal
  • with-contenv tool, which is used to expose environment variables across scripts, has a limitation that it cannot read beyond 4k characters for environment variable values. To work around this issue, use the script /scripts/with-bigcontenv instead of with-contenv. You'll need to remove the with-contenv from the shebang line, and add source /scripts/with-bigcontenv in the next line after the shebang line.

    Startup/Runtime Modification

To inject changes just before runtime, shell scripts may be placed into the
/etc/cont-init.d folder.
As part of the process manager, these scripts are run in advance of the supervised processes. @see


  • Container tests itself as part of build process using goss validator. To add additional build-time tests, overwrite (or extend) the ./container/root/goss.base.yaml file.
  • To initiate run-time validation, please execute It uses dgoss validator. To add additional run-time tests, extend ./ and ./goss.yaml file.

Advanced Modification

More advanced changes can take effect using the run.d system. Similar to the /etc/cont-init.d/ script system, any shell scripts (ending in .sh) in the /run.d/ folder will be executed ahead of the S6 initialization.

  • If a run.d script terminates with a non-zero exit code, container will stop, terminating with the script's exit code, unless...
  • If script terminates with exit code of $SIGNAL_BUILD_STOP (99), this will signal the container to stop cleanly. This can be used for a multi-stage build process

Long-running processes (workers + crons)

This container image can be used with multiple entrypoints (not to be confused with Docker entrypoints).
For example, a codebase that runs a web service, but also requires crons and background workers. These processes should not run inside the same container (like a VM would), but can be executed separately from the same image artifact by adding arguments to the run command.

docker run {image_id} / 3 /bin/binary -parameters -that -binary -receives

Runs 3 copies of /bin/binary that receives the parameters -parameters -that -binary -receives

Container Organization

Besides the instructions contained in the Dockerfile, the majority of this
container's use is in configuration and process. The ./container/root repo directory is overlayed into a container during build. Adding additional files to the folders in there will be present in the final image. All paths from the following explanation are assumed from the repo's ./root/ base:

Directory Use
/etc/cont-init.d/ startup scripts that run ahead of services booting:
/etc/fix-attrs.d/ scripts that may fix permissions at runtime:
/etc/services.d/ services that will be supervised by S6:
/etc/services-available/ same as above, but must be symlinked into /etc/services.d/ to take effect
/run.d/ shell scripts (ending in .sh) that make runtime modifications ahead of S6 initialization
/scripts convenience scripts that can be leveraged in derived images
Docker Pull Command
Source Repository