bretfisher / docker-build-workflow

A Reusable Workflow of the Docker GitHub Actions

Oh hi 👋

apiVersion: v48
kind: Human
metadata:
  name: Bret Fisher
spec:
  purpose: Help others learn container DevOps
  sponsorship: bretfisher.com/members
  locations:
    - 
      type: YouTube Live Stream on Thursdays
      where: bret.live
    - 
      type: Newsletter
      where: bret.news
    - 
      type: Homepage
      where: bretfisher.com
    - 
      type: Discord Server
      where: devops.fan
    -
      type: Podcast
      where: bretfisher.com/podcast
  favorites:
    number: 42
    animal: 🐶
    emoji: 🤦
    food: 🥩
    drink: 🥃

🙋‍♀️ You can Ask-Me-Anything in my ama repository, or tweet @BretFisher.

💬 Join my 12k+ member DevOps community on Discord: devops.fan.

📰 Read my Cloud Native Newsletter: bret.news

☕️ 🤑 Please support my DevOps YouTube Live show, podcast, and open source content by buying me a coffee every month at bretfisher.com/members!

🧑‍🏫 My course repositories

• All my Udemy course coupon codes: bretfisher.com/courses
• Automate Your Kubernetes Deployments with GitHub Actions and Argo GitOps
• Docker Mastery (with Kubernetes, Swarm, Compose, and more)
• Kubernetes Mastery (go deeper in K8s)
• Docker for Node.js (learn advanced ways to use local Docker with Node.js projects)
• Swarm Mastery (learn more about Docker's built-in orchestrator)
• More DevOps courses coming!

My examples and templates (New stuff on top)

• Awesome Swarm - A list of resources, tools, and learning on Docker/Mirantis Swarm (SwarmKit)
• Kubernetes initContainer Examples and Good Defaults - Learn Kubernetes Init Containers by example, and when to not use them.
• Kubernetes Pod Specification (podspec) Good Defaults - Good Defaults for the most common Kubernetes workloads. Adds security and uptime (optional) features.
• Node.js Rocks in Docker - Video and examples of multi-stage docker builds, k8s healthcheck probes, etc.
• GitHub Actions for Docker: examples and video walkthrough - Video and examples of GitHub Actions for advanced docker builds, automated testing, and CVE scanning.
• GitHub Actions DevOps Templates - reusable GitHub Actions templates for DevOps stuff (linting, docker builds, CVE scanning, etc.)
• Docker Build GitHub Action Template - My custom GitHub Actions workflow using Docker's official build-and-push Actions.
• Super Linter GitHub Action Template - My custom all-in-one linter workflow. I lint all my repositories, and I recommend you do to.
• Node.js Docker Good Defaults - A sample Node.js project that uses Docker.
• Docker Compose local TLS for devs - A sample Compose file that uses a Traefik proxy for TLS, and optionally, Let's Encrypt.
• Docker Build Multi-platform Readme - Explains some ways to build Docker images for multiple platforms in a single Dockerfile.
• Voting App Docker Example - My favorite multi-container example app that I often use to for learning Docker, K8s, CI/CD, and GitOps.
• PHP Docker Good Defaults (outdated) - A sample PHP project that uses Docker.
• Java Docker Petclinic Example - A sample Java project that uses Docker.
• dogvscat Using the voting app in Docker Swarm to explain orchestration, proxies, secrets, and networking.

My tools (often used for learning Containers, Kubernetes, and Docker)

• shpod - Common Kubernetes tools in a single pod.
• httping - Ping with HTTP. Fantastic for testing zero-downtime rolling updates.
• jekyll - Jekyll in a container.
• vackup - Docker Volume backup and restore.
• browncoat - A utility container for simulating failures like slow startup, failing healthchecks, etc.

docker-build-workflow's Issues

Create a GitOps deployment PR when image is pushed

Scenario:

• I use something like this repo to build docker images and push them to a registry. I do this in multiple app repos across my solution, and the PR merge creates a new image tag that's immutable, ready for deployment to servers. e.g. stable-<date>-<commit-sha>
• I might use Argo CD or Flux for GitOps, I might use Helm or Kustomize to define my environment values, or I might just use GHA itself to push a image change (in yaml, toml, json, etc.)

Problem:

• Our CI tools (in this case GHA, but could be Drone, CircleCI, Jenkins, Codefresh, etc.) build our image smartly with all the fancy tags and metadata, and push to our production registry and repo, but they stop there.
• Then our CD solution needs to change the image tag, first for staging, and then eventually promoting to prod. There are some tools like Argo CD Image Updater which will watch registries for new image tags (fitting a regex or date pattern) and update Kubernetes with that image, and optionally update a GitOps repo with the tag change, but this doesn't fit all workflows. For one, updating Git after a cluster change isn't fully GitOps IMO.
• This "CI to CD" gap requires humans to merge their PR, and then go find what image tag was built (which could be 10+ minutes later since it's creating a new image from the new merge commit), and paste the correct tag into a different repo where their IaC/GitOps is stored.

Proposed solution:

• Assuming in this case we're using GHA for CI, it knows when that image is pushed to the "final" registry and what the tag is. It should "bridge the gap" with a helpful commit or PR to our IaC/GitOps repos based on our human workflow requirements.
• All this solution needs to be is a final GHA Job after a default_branch commit or PR merge. It links the CI run to an environment deployment. Bonus points for adding a notification (Slack, etc.) that the IaC/GitOps repo has a new image ready for PR merge.

Provide image promotion workflow

In the current reusable workflow, it'll push to either Docker Hub, GHCR, or both. It'll push all tags to both registries every build. This isn't typically how more complex setups work. We should provide workflows and docs to support an additional process:

1. Image is only pushed to a single registry/repo while a PR is open. Assume this is the "Dev" registry/repo. There are multiple tags, including datetime, PR number, GHA run ID, etc.
2. Once PR is merged, a true "promotion" of that PR isn't possible (AFAIK) because the merge is really a GitHub push event. GHA can't correlate the PR merging and the push event. The image must be built again (but can lean on the layer cache of BuildKit, so it shouldn't need to rebuild any layers if the Dockerfile is designed properly).
3. Once that image is rebuilt, push the image to both registries, but only the tags we prefer for "promoted" images.

Proposal:

1. Add a new step using docker/build-push-action, but with different inputs for tags and labels. That step needs an if key to only fire on push (and if a promotion input is enabled.)
2. Change the current id: build_image step to only fire on pull_rest if the promotion input is enabled.

This should allow the calling workflow to opt-in to a promotion multi-build setup, and choose different image names and tags. Note, the image names for the promotion build will determine which registries and repos to push to.