Public | Automated Build

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

docker-base

https://hub.docker.com/r/behance/docker-base/tags/

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

Variants

Ubuntu container OS is in use by default

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

Tools

  • 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.

Expectations

To add a service to be monitored, simply create a service script: https://github.com/just-containers/s6-overlay#writing-a-service-script
For programmatic switches, create the service in /etc/services-available, and symlink to /etc/services.d to enable

Security

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

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

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.

Packaging

A convenience script is provided for post-package installation cleanup

On all variants, run:
/bin/bash -e /clean.sh

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 https://github.com/just-containers/s6-overlay#executing-initialization-andor-finalization-tasks

Testing

  • 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 test.sh. It uses dgoss validator. To add additional run-time tests, extend ./test.sh 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} /worker.sh 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: https://github.com/just-containers/s6-overlay#executing-initialization-andor-finalization-tasks
/etc/fix-attrs.d/ scripts that may fix permissions at runtime: https://github.com/just-containers/s6-overlay#fixing-ownership--permissions
/etc/services.d/ services that will be supervised by S6: https://github.com/just-containers/s6-overlay#writing-a-service-script
/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
Owner
behance
Source Repository