containerBuild

containerBuild

Some CI/CD pipeline toolsets support native capability (GitLab, BitBucket) to execute with a container. In other some cases, (CircleCI, Travis) all pipeline activity can only be executed within containers.

For toolsets which do not support this functionality, but do allow for self-hosted agents or where a self-hosted agent is preferred/mandated i.e. execution within a private network, the CDAF container helpers can provide consistency for construction, execution and housekeeping.

Even with a toolset uses containers, if they support docker-in-docker, the CDAF container helpers can still be utilised.

containerBuild

containerBuild

Master of Build Success

The containerBuild option allows the execution of the build process from within a container. Unlike toolsets which reference a image that is used to create the build container, CDAF uses a Dockerfile, for the following advantages:

• Build Prerequisites can be defined in code, without being limited to available published images
• Once constructed the image image cache provides improved performance, without having to use a image registry
• Working directory and user home directory are volume mounted, to allow caching of build dependencies, e.g. Maven, node_modules

Container Build Configuration

To execute the build within a container, add the containerBuild definition and containerImage to CDAF.solution. Note: complete definitions are provided in the GitHub samples for Windows and Linux.

The following samples have the default process commented out, and can be used to define a custom process.

Windows

containerImage=cdaf/windows
# containerBuild=& ${AUTOMATIONROOT}/processor/containerBuild.ps1 $SOLUTION $BUILDNUMBER $REVISION $ACTION

Linux

containerImage=cdaf/linux
# containerBuild=$AUTOMATIONROOT/processor/containerBuild.sh $SOLUTION $BUILDNUMBER $REVISION $ACTION

Build Time Variables

To supply variables to the build process, prefix with CDAF_CB_ (see CDAF Environment Variables) and the variables will be mapped into the build container.

See GitHub samples for Windows and Linux for dockerfile and additional properties.

imageBuild

imageBuild

This helper script supports the creation of docker images, and conditionally, the pushing of that image to a registry.

Container Build Configuration

To execute, define the buildImage definition. Note: complete definitions are provided in the GitHub samples for Windows and Linux.

The following samples have the default process commented out, and can be used to define a custom process.

Windows

buildImage=cdaf/windows
# imageBuild=& "$AUTOMATIONROOT/remote/imageBuild.ps1" ${SOLUTION}_${REVISION} ${BUILDNUMBER}

Linux

buildImage=cdaf/linux
# imageBuild="$AUTOMATIONROOT/remote/imageBuild.sh" ${SOLUTION}_${REVISION} ${BUILDNUMBER}

Immutable Deploy in Construction

If a custom docker file is not supplied, the default dockerfile will execute the IMMUTABLE release in the image construction process.

Registry Push

To include a push to a registry, add the following to CDAF.solution for DockerHub

CDAF_REGISTRY_URL=DOCKER-HUB
CDAF_REGISTRY_TAG=repo/${SOLUTION}:$BUILDNUMBER
CDAF_REGISTRY_USER=pat
CDAF_REGISTRY_TOKEN=${ACCESS_TOKEN}

Or for another registry provider or a self-hosted registry

CDAF_REGISTRY_URL=myregistry.io/repo
CDAF_REGISTRY_TAG=${CDAF_REGISTRY_URL}/${SOLUTION}:$BUILDNUMBER
CDAF_REGISTRY_USER=pat
CDAF_REGISTRY_TOKEN=${ACCESS_TOKEN}

Custom Image & Process

For samples of more complex usage see the GitHub samples for Windows and Linux dockerfile and additional properties.

Stand-alone Usage

The imageBuild script is used for docker-compose stand-up/tear-down process, for complete samples see Windows and Linux.

The following parameters must be passed

• Unique ID : normally "${SOLUTION}_${REVISION}"
• Sequential Number : normally "${BUILDNUMBER}"
• Base Image : any valid image, e.g. cdaf/linux or cdaf/windows

Optional parameters

• Context : if supplied, only the named directory is built, if ommited, all directories are built.

containerDeploy

containerDeploy

Like containerBuild, containerDeploy provides both image build and container task execution. The common use for container deploy where a command line interface is required.

Master of Deployment Success

The containerDeploy option allows the execution of the deploy process from within a container. Unlike toolsets which reference a image that is used to create the deploy container, CDAF uses a Dockerfile, for the following advantages:

• Deploy Prerequisites can be defined in code, without being limited to available published images
• Once constructed the image image cache provides improved performance, without having to use a image registry

Container Deploy Configuration

To execute the deploy within a container, add the containerDeploy definition and runtimeImage (if not supplied, containerImage will be used) to CDAF.solution. Note: complete definitions are provided in the GitHub samples for Windows and Linux.

The following samples have the default process commented out, and can be used to define a custom process.

Windows

runtimeImage=cdaf/windows
# containerDeploy=& ${WORK_DIR_DEFAULT}/containerDeploy.ps1 "${TARGET}" "${RELEASE}" "${SOLUTION}" "${BUILDNUMBER}" "${REVISION}" -imageDir cli

Linux

containerImage=cdaf/linux
# containerDeploy=${WORK_DIR_DEFAULT}/containerDeploy.sh "${TARGET}" "${RELEASE}" "${SOLUTION}" "${BUILDNUMBER}" "${REVISION}" cli

Deploy Time Variables

To supply variables to the build process, prefix with CDAF_CD_ (see CDAF Environment Variables) and the variables will be mapped into the build container.

See GitHub samples for Windows and Linux for dockerfile and additional properties.

Custom Image

The default directory used for container deploy is containerDeploy, if this is not found, the default Dockerfile is used, with the default runtime files. If you have your own Dockerfile in containerDeploy, or a custom directory specified in CDAF.solution containerDeploy property, then that will be used.

Runtime Files

The release.sh file is included in the default image, however, if using a default image, this needs to be explicitly defined in CDAF.solution runtimeFiles property. This can be a space separated list of files.

runtimeFiles=$WORKSPACE_ROOT/release.sh

Runtime Retain

To skip image clean-up, set CDAF.solution runtimeRetain property.

runtimeRetain=yes

dockerPush

dockerPush

Using the same logic after imageBuild, this utility script provides simple login and push logic.

The script can be called passing arguments

./dockerPush.ps1 $TARGET_TAG cdaf/${SOLUTION} "${artifactPrefix}.${BUILDNUMBER} latest" $DOCKERHUB_TOKEN cdaf

This example uses an environment variable (complete list follows) to set the URL. The registry in this example does not require authentication.

export CDAF_PUSH_REGISTRY_URL=hub.private.registry
./dockerPush.sh ${SOLUTION}_master_target:${BUILDNUMBER} ${SOLUTION} ${BUILDNUMBER}

Available environment variables