Self-hosted Containers

Self-hosted Containers

Opinionated Docker Image and Container Management

CDAF 2.6.1 & 2.6.2

With the progressive introduction of image and container management to CDAF, there has been a level of inconsistency around how the process operates.

The primary use case for CDAF containers is for self-hosted agents/runners to provide a similar capability to container native orchestration tools, e.g. GitLab and BitBucket Pipelines.

The following is a summary of the supported processes.

containerBuild

Used to perform the build prcess within a container. This is executed using a volume mount, so that the resulting artefacts are retained once the container closes. The user home directory is also mounted to provide shared cache data, for example, Maven dependencies. Additional build configuration can be supplied via environment variables CDAF_CB_, see CDAF Environment Variables.

imageBuild

Produce an immutable image based on the build artefacts, with an optional registry push configuration.

containerDeploy

Execute the deployment task within a container. This container is not volume mounted, instead the delivery process is injected into the image and executed at runtime. The management of environment specific configuration is via environment variables CDAF_CD_, see CDAF Environment Variables.

Linux Considerations

containerBuild and imageBuild will configure the host user as the default runtime user in the image. If the base image defined already contains a user with the same UID, that user will be removed and replaced.

Minimum Configuration

Along with the consistent implementation of default processes, default Dockerfiles are also defined, resulting in the following minimal CDAF.solution configuration for containerBuild, imageBuild and containerDeploy respectively.

containerImage=cdaf/linux
buildImage=cdaf/linux
runtimeImage=cdaf/linux        

For image build, the release environment for image construction is IMMUTABLE, i.e. an example properties.cm file could be…

context  target     deployTaskOverride
local    IMMUTABLE  immutable.tsk        

For full release details for CDAF 2.6.2 see http://cdaf.io/release

To view or add a comment, sign in

More articles by Jules Clements

  • Release Train Engineering

    In large-scale environments, a release can encompass infrastructure, operational, and application changes. Within the…

    2 Comments
  • Saying Goodbye to Old Code: A Love Letter to the Repos I've Laid to Rest

    There comes a time in every technologist’s journey when we face the final push—not of a feature, not a hotfix—but the…

    4 Comments
  • Realising the Feedback Loop

    Information Technology Solution Delivery in Enterprise Environments Continuous Delivery to Shift-Left While the DevOps…

    1 Comment
  • Technical Debt

    After over a decade of maintaining the Continuous Delivery Automation Framework, the time has come to pause new…

  • CDAF 2.6.0 Cascading Properties

    Environment, Solution and Function Properties CDAF Release 2.6.

  • CDAF 2.5.7 Package Features and Method

    CDAF 2.5.

  • Do-Nothing Pipeline

    Entering Sprint-0 To embed automation into the feature development lifecycle, a pipeline should exist at the earliest…

  • CDAF containerDeploy

    containerDeploy, like containerBuild, is intended for self-hosted agent/runner use cases. By including the image…

  • CDAF Variable Validation Operation

    CDAF provided tabular configuration management files in late 2018, but until now, did not have a convenient way of…

  • CDAF Feature Branch Environments

    The existing feature branch capability in CDAF (Git only, entry.ps1/entry.

Explore content categories