Container Publishing

Containers offer a high degree of platform flexibility and scalability necessary for SaaS ecosystems, and this project has been made container-ready for this reason. The .github/workflows directory hosts Yaml files utilized as part of GitHub Workflows. Actions triggered by PR creation targeting the main branch handle publishing of container images to Github Container Registry. These container images are then pulled by the app services running the modules (if you followed the instructions listed in our Quick Start guide).

These processes are defined by files that GitHub will automatically recognize, and so comitting them to a GitHub repo will include them for use in your own project. Here are some key files and attributes to familiarize yourself with the publishing process:

Pull-Based vs Push-Based Deployments

Using containers changes the way a traditional CI/CD process works, and moves away from a “push-based” deployment into a “pull-based” deployment. This means that in order to release code using containers, you will first need to build and publish your container (with your code and runtime inside), and then trigger your hosting environment to pull the new version of your container on your instance. See our CI/CD for custom containers documentation for a more thorough explanation of how this process works using Azure App Service.

i. Building Images

As part of build-artifacts.yml each of the modules is built as a Docker image by invoking docker-compose.yml. The compose script defines the overall execution parameters of each module and identifies a corresponding Dockerfile to define how a given module is built for use in a container.

ii. Pushing Image

Containers are published at three times in the project’s workflows:

  1. Merge: Whenever a merge occurs on main then build-artifacts.yml is run. This workflow builds all of the images registered in the docker-compose.yml file. It will push each image tagged as latest to the GitHub Container Registry.
  2. Tag: When a tag is created on the project then four corresponding actions are triggered which build a module and push an image tagged with the newly-created repo tag. These scripts are:
  3. PR: When a PR is opened, synchronized, or reopened targeting main, then four corresponding actions are triggered which build a module and push an image tagged with the PR number. These scripts are:

The constructed images and identifiers are then pushed to the GitHub Container Registry service for future instances of the application modules to pull when relevant. No publishing action is necessary at this point and existing container instances will continue running their contained version without issue.

iii. Pulling Image

Continuous Delivery has been enabled via the Tag and PR workflows to enable testing and dev environment automatic update. These scripts are configured to fetch a webhook url secret from the repository corresponding to an environment and the given module. It will then issue an HTTP POST against this endpoint so that it can be alerted that a new image version has become available. The endpoint in use with the existing repository is the provided CI/CD webhook for the Azure Web App custom container image endpoint.

Scripts and Variables

i. Build Artifacts

The build-artifacts.yml script is invoked whenever there is a PR issued against the main branch. It defines two steps for building and publishing the module Docker images.

Variable Description Default
IMAGES_TO_PUSH Quoted and space-delimited list of images to push. (“asdk-admin” “asdk-web” “asdk-permissions” “asdk-signup”)
GH_TAG Tag applied to image to identify it and indicate its version. Currently version is always set to latest.

ii. Docker Compose

The docker-compose build command in the build artifacts script finds and invokes the Docker Compose specification script docker-compose.yml in the project root. This lists out the images to construct and indicates a corresponding Dockerfile for an image.

Variable Section Description Default
image The image identifier, must match with the image name variable in build-artifacts.yaml to be tagged and pushed into container repository.
container_name Container identifier, distinct from the image it is started from.
context build Defines the directory context from project root other relative paths are searched against ./src
dockerfile build Path relative to context to the Dockerfile for a given image specification
expose Defines the ports that must be exposed from container. 80
ports Container ports to expose for access.

iii. Dockerfile

Each module directory contains a corresponding Dockerfile referenced by docker-commpose.yml which contains the commands necessary to construct its container image.

Variable Section Description Default
app_name Shared Informal identifier
app_path Shared Path to project directory from context defined in compose specification.
dll_name Stage 2 Name of the dll in output directory
ENTRYPOINT Stage 2 Command which directs the container to the path and dll as entry to the image.

iv. GitHub Action Secrets

The following secrets are referenced by the GitHub Actions CI/CD workflows to issue a POST alerting deployed apps of newly-available container images.

Variable Environment Module
ASDK_ADMIN_DEV_WEBHOOK_URL Dev Saas.Admin.Service
ASDK_WEB_DEV_WEBHOOK_URL Dev Saas.Application.Web
ASDK_PERMISSIONS_DEV_WEBHOOK_URL Dev Saas.Permissions.Service
ASDK_SIGNUP_DEV_WEBHOOK_URL Dev Saas.SignupAdministration.Web
Last modified June 27, 2022: Module Readme Revisions (#176) (e4dec86a)