ECS-C2: Continuous Deployment with Docker and GitHub

GitHub Actions is a hosted automation service. You define workflows in YAML which live in your repository, and they can be triggered by pushes, schedules, manual runs and other events.

Jobs run in a short-lived VM which is provisioned for you, and the standard VMs include Docker so you can easily transition your Docker-powered CI/CD process to GitHub.

In this episode we’ll take the multi-stage Dockerfiles from ECS-C1 and use them to build images with GitHub Actions. We’ll see a couple of approaches to the workflows, finishing with a full CI/CD pipeline which deploys the sample app to a Kubernetes cluster running in Azure.

Here it is on YouTube - ECS-C2: Continuous Deployment with Docker and GitHub

Links

• GitHub Actions - docs

• Configure GitHub Actions - Docker’s action guide

• Best practices for using Docker Hub for CI/CD - Docker blog

• Docker metadata action - from Docker Captain Crazy Max

• Kubernetes deployment action - from Microsoft

Pre-reqs

GitHub (and an AKS cluster if you want to try the deployment).

You can clone this repo and create your own Secrets:

• DOCKER_HUB_USERNAME
• DOCKER_HUB_ACCESS_TOKEN
• AZURE_CREDENTIALS

Demo 1 - basic build

The first workflow uses Docker Compose for the build - ecs-c2-v1.yml, with this Docker Compose file.

It uses GitHub Secrets for the Docker Hub credentials.

Run the build manually from the repository actions page.

Then check the tags in the sixeyed/access-log repo on Docker Hub.

Using Docker Compose is nice and easy, but because runners are temporary you don’t get any caching.

Demo 2 - Docker’s GitHub actions

Docker have their own GitHub actions which support caching image layers.

ecs-c2-v2.yml:

• Docker build & push
• buildx configuration
• build cache

The v2 workflow uses a job for each image. There’s a lot of duplication in the spec but it means the jobs can run in parallel.

(There’s also a Docker QEMU action which you can use for cross-platform Linux builds).

Run the build from actions.

Check the tags in the sixeyed/access-log repo.

Demo 3 - Deploying to AKS with Helm

The v2 build has caching but a fixed image tag. v3 sets the tag and adds image labels, and then it deploys the app to Kubernetes using Helm.

ecs-c2-v3.yml:

• Docker metadata to use GitHub tag as image tag and labels
• connection to AKS cluster
• parameterized deployment with Helm (image tag & port)

Nothing in AKS right now:

kubectl get nodes

kubectl get all

The workflow is triggered from a tag with a version number:

git tag v1.0

git push --tags

Check the build in actions; output shows the URL to browse to.

Check the tags for sixeyed/access-log.

kubectl get pods --show-labels

kubectl describe pod -l app=apod-api

Check the GitHub tag is the image tag.

Coming next

• ECS-C3: GitOps on Kubernetes with Argo CD