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.

Environment, Solution and Function Properties Release 2.6.0 is the start of applying consistent prioritised properties. The principle of application, from highest to lowest is Arguments Environment Variables Solution Properties Existing Features The application is progressive, starting with existing properties which have environment variable format CDAF_REGISTRY_URL CDAF_REGISTRY_TAG CDAF_REGISTRY_USER CDAF_REGISTRY_TOKEN CDAF_HOME_MOUNT CDAF_ERROR_DIAG New Features in 2.6.0 Along with these, new properties are introduced to support containerBuild using a base image from a private registry

Package Features and Method Package Features As CDAF has grown, there has been a constant growth in the number of helper scripts available, however, in many cases only a subset of these are needed at deploy time, so packageFeatures has been introduced to support different deployment use cases, starting with minimal. The minimal set, as the name implies, is the smallest number of helper scripts to execute a deployment. The deployment is limited to local context, so it is recommended to reduce the processSequence in your CDAF.

PROPLD and DETOKN Extensions Properties which are mapped to variables can now be directly defined as such. This is particularly useful for values that are only known at deploy time, such as cloud resources which are automatically allocated by the provider or are randomly generated such as UUIDs. For the following example tokenised settings file, for example variables.tf variable "terraform_token" { default = "%terraform_token%" } variable "api_ip" { default = "%api_ip%" } variable "redis_cache" { default = "%redis_cache%" } Non-sensitive variable mapping can be applied to the properties.

Deployment from within Container using 'Remote' artefacts containerDeploy, like containerBuild, is intended for self-hosted agent/runner use cases. By including the image construction and container execution in source control, the developers remain masters of their own destiny. They can ensure build dependencies are fulfilled while not affecting other users of the agent/runner. When deploying to remote targets using Web/REST API, or command line interfaces, containerDeploy can exploit the same principles as containerBuild to ensure the required deploy time dependencies are fulfilled, e.

CDAF provided tabular configuration management files in late 2018, but until now, did not have a convenient way of verifying these properties when they are loaded as variables, nor environment variables, at deploy time. The VARCHK operation has been added to the execution engine to allow different validation rules and logging. The operation syntax is VARCHK properties.filename There are 5 rules available, two for plain text and three for secrets. When validating a secret against a known MD5 value, either a literal or variable can be supplied.

The existing feature branch capability in CDAF (Git only, entry.ps1/entry.sh) has been based on docker-compose, for stand-up, test and tear-down environments based on feature branches. For some organizations, where containers are not feasible, i.e. system complexity, proprietary software, a limited number on perpetual environments are available. The CDAF extension (2.4.5) allows for the targeting of one or more environments, based on branch name prefix (definition file is feature-branch.properties). Important note: beware of potential environment drift over time as different environments receive different updates.

Vagrant Rationalisation, Terraform Adoption While support for Vagrant will continue, the extend of regression testing for it will be reduced, i.e. only use cases that I cannot replace with docker will continue to be regression tested. Additional efforts will be make for “Manifest Releases” in Terraform (based on Autonomous Development, Authoritative Release. & Containers at Scale, A Containers Journey. CentOS Sunset, UBI8 With the end of CentOS in the infancy of CentOS 8, Fedora support by CDAF will based on Red Hat Universal Base Image (UBI).

The previous output from the CDAF build process was directory of scripts and artifacts, and where remote execution was required, a compressed package. This was slow to upload due to many small files and also didn’t provide an obvious realisation of the Build, Run, Release principle. The Self-Extracting release now produces and single executable output. This addresses the issues above, while providing a more meaningful output for interpretive solutions, i.e. where no compile process is required.

MASKED using SHA256 The MD5MSK operation will be removed in the next breaking change. The new operation MASKED does not reference the algorithm to allow for changes (though unlikely) in the future. MASKED $PASSWORD Returns uppercase (as per MD5MSK, in both Linux and Windows) checksum. A591A6D40BF420404A011733CFB7B190D62C65BF0BCDA32B57B277D9AD9F146E VARCHK secret mask Also for the VARCHK operation, when a property is secret or checksum verified, SHA256 algoithm is used. For this example property file