Housekeeping

• Beth is here to help me!
• We’re taking a picture of us near the end of class. Let Beth know in chat if you’d like to opt out
• Find us in the Maven course community to get help
• Reply to any email help@bretfisher.com

Schedule

Week 1

• Workshop 1: Monday. GitHub Actions for Docker and best practices
• Workshop 2: Wednesday. GitHub Actions reusable workflows
• Q&A 1: Friday. Discussion on implementing GHA

–

Week 2

• Workshop 3: Monday. Argo CD setup
• Workshop 4: Wednesday. Argo CD app deployments
• Q&A 2: Friday. Discussion on implementing Argo CD

Topic links

Add simple Docker build via PR

Let’s focus on wordsmith-web for now

1. Copy my sample "Docker Simple" YAML here
2. Navigate to the Actions tab in wordsmith-web
3. Click New workflow, then click setup a workflow yourself
4. Name the new file .github/workflows/docker-build.yml
5. Paste in our sample workflow
6. One thing to change: update tags to our repo (last line)
   • ghcr.io/<orgname>/wordsmith-web:latest
   • ⚠️ <orgname> must be lowercase to work with Docker!
7. Commit changes to a new branch
8. Create a PR for that branch. This will kick off the workflow
9. Let’s watch the Action run (don’t merge yet)

This is a good start, but…

• Only pushes an image when merged to the main branch
• Doesn’t build for multi-arch (Intel + Arm)
  • Click your Zoom Reaction if you have Apple Silicon Mac’s in your team
• Doesn’t use image layer caching
• Only has one (hardcoded) tag :latest
• Doesn’t have image labels like

  org.opencontainers.image.title=wordsmith-api
  org.opencontainers.image.source=https://github.com/MostlyDevOps/wordsmith-api
  org.opencontainers.image.version=gha-4715332302
  org.opencontainers.image.created=2023-04-16T21:16:33.149Z
  org.opencontainers.image.revision=f217725e1bf9e1032debb15df43b06513907d58b

• Requires us to dig into build logs to know the image tag
• We can do better!

Improve supply chain security with GitHub settings

More automation means you need more guardrails

• In GitHub repo settings, add a main branch protection rule
• In GitHub Security tab, enable everything
• For bigger teams, add a CODEOWNERS file
• (Shameless plug) 📧 get on my newsletter to get updates on my security steps guide

Concurrency limits can save you money

• Avoid multiple commits in the same branch/PR from running at the same time

• Add this at workflow level, before jobs, in every workflow

# cancel any previously-started, yet still active runs of this workflow on the same branch
concurrency:
  group: ${{ github.ref }}-${{ github.workflow }}
  cancel-in-progress: true

You can do this in the extra credit slides later

Dependabot creates PRs for outdated Actions

Let’s add a Dependabot config to our wordsmith-web repo

• Create a new file in the .github folder called dependabot.yml

---
# Please see the documentation for all configuration options:
# https://docs.github.com/github/administering-a-repository/configuration-options-for-dependency-updates

version: 2
updates:
  # Maintain dependencies for GitHub Actions
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "daily"

Then you’ll see PRs like this:

Create PRs for Docker image updates

This only works for image tags that use semver tags

• Add another package-ecosystem to the dependabot.yml file

  - package-ecosystem: "docker"
    directory: "/"
    schedule:
      interval: "weekly"
    commit-message:
      prefix: "[docker] "

Then you’ll see PRs like this:

This also works for Kubernetes and Helm! Repeat the above YAML for each directory you want to update.

Note: Dependabot can update many dependencies, check it out

What is Super-Linter?

Extra, Extra Credit: Watch my Super-Linter walkthrough live stream

Why lint everything?

1. It doesn’t just change code, it changes culture
2. Helps avoid "one person’s opinion" about style
3. Educates on best practices
4. Avoid "code smells" that lead to bugs
5. Avoid unseen errors before deploys
6. Linters now do security checks too

Add Super-Linter to wordsmith-web

1. In your wordsmith-web repo, go to the Actions tab
2. Don’t use suggestions, click "set up a workflow yourself"
3. Paste in the Super-Linter workflow template
4. Commit to a new PR and study the output/logs of how it works
5. Advanced Reusable Mode. We’ll learn more about Reusable Workflows Wednesday, but if you want to take the leap now: Fork and implement BretFisher/super-linter-workflow

The problem with Monday’s GHA approach

• Each Workflow only works in its repo
  • (we’d have to copy/paste to every repo)
• No way to set standards, or track "workflow drift" between repos
• On every Action version update, we have to update every repo
  • (Even with Dependabot, that’s a lot of PRs to review)

Option 2: Actions Starter workflows

• Create an org repo called .github and put workflows in there
• When you create a new Action from the repo web UI, you’ll see them:

• Con: Better, but still doesn’t centrally control workflows across repos
• Con: Only works in private repos if you have GitHub Enterprise Cloud

Advantages of reusable workflows

• Reusable workflows can be centrally managed (one or more repos)
  • (a different team can own them)
• Works across public and private repos
• Ideally, one place to manage action versions and control complexity
  • (depends on how you call them with @semver, @branch, or @sha)
• You can call a workflow in the same repo or a different repo
• You can call multiple reusable workflows from a single calling workflow (20 max)
• You can nest reusable workflows in reusable workflows (4 levels max)
• You can make starter workflows that call reusable workflows
  • (if you’re open source or GitHub Enterprise)
• Allows junior devs to use advanced workflows w/o knowing the internals
• You can design inputs so calling workflows can customize the reusable workflow
• Con: Inputs (how you pass data between workflows) will add a bit of complexity
• Con: Troubleshooting workflows not running gets a bit more complex

Create a central public actions repo

1. Create a new public repo called actions
2. Add a .github/dependabot.yml file with this content:

version: 2
updates:
 - package-ecosystem: "github-actions"
   directory: "/"
   schedule:
     interval: "daily"

Note: If the repo was private, this setting would show up. We would need to change it:

Settings > Actions > General > Access

Extra Credit Recap

Did you do any of the extra credit? Do you have questions?

Housekeeping

• I updated Monday’s Further reading slide
  • More links to following updates: Public Roadmap
  • More links to finding good Actions

Examples of reusable workflows

Imagine all these being centrally controlled and automated for all software repos in your org

• The advanced Docker Build
• Image CVE Scanning with the Trivy Action
• Linting Action with Super-Linter (50+ linters in one Action)
• Complex testing designs (unit + integration + E2E in one Workflow)
• Smoke test any PR commit by deploying to a k8s cluster and waiting for probes to pass
• Static analysis (code quality, security, etc) with CodeQL
• Create PR preview environments with Uffizzi or Okteto. Built on PR open and destroyed on PR close
• PR bots that auto-assign reviewers, assign labels, etc
• Automatically rebase PRs when they get out of date from main
• Sync labels (names, colors, descriptions) across repos
• Create a OpenSSF scorecard of your repos
• Watch GitHub runners for bad behavior while your workflows run

Process overview: implement a reusable workflow

1. Add a workflow to a repo .github/workflows that you want to reuse elsewhere
   1. This is the "Reusable Workflow"
2. Add a on:workflow_call event to the workflow
3. Add any required or optional inputs and secrets to that event
   1. These act similarly to environment variables during the workflow run
4. Add those input and secret values into the workflow steps
5. Create a "Calling Workflow" job in another repo (a calling job calls a reusable workflow)
6. Add the inputs and secrets to the calling workflows

Call the workflow from the wordsmith-web repo

1. Create the file .github/workflows/call-trivy.yml and paste this in
2. Change <org>. Then change <pr-branch-name> to the branch you just created in the actions repo
3. ProTip: This is how you test reusable workflows before merging them in either repo
4. GitHub Best Practice: Make this PR draft, because you’ll change it to main branch before merging

name: Call Trivy
on:
 push:
   branches: [main]
 pull_request:
jobs:
 scan:
   name: Scan
   uses: <org>/actions/.github/workflows/reusable-trivy.yml@<pr-branch-name>

• NOTE: This Action run may not succeed if you have uppercase in org or repo name
• Also, how do we change the tag to the one being built in a commit or PR?
• That brings us to inputs!

Popcorn Time!

Question 1: What workflow will you likely build first in your work projects?

Question 2: What workflow would most impress your boss?

After you speak, pick the next raised hand to speak

The problem with reusable workflows

• The calling workflow usually needs to pass data to the reusable workflow
• GitHub limits the ways we can do that. Because security
• GHA calls these workflow inputs
• env/config data can be passed via with and secrets
• Example:

jobs:
  call-docker-build:
    name: Call Docker Build
    uses: bretfisher/docker-build-workflow/.github/workflows/reusable-docker-build.yaml@main
    secrets:
      dockerhub-username: ${{ secrets.DOCKERHUB_USERNAME }}
      dockerhub-token: ${{ secrets.DOCKERHUB_TOKEN }}
    with:
      dockerhub-enable: true
      image-names: ghcr.io/${{ github.repository }}
      tag-rules: |
        type=ref,event=pr
        type=raw,value=gha-${{ github.run_id }}

Passing data to reusable workflows

Reusable workflows accept data via inputs

1. First, let’s add an inputs array to our reusable workflow on:workflow_call: event
2. Next, we pass those input values to the Action steps: ${{ inputs.<input-name> }}
3. Then we’ll add matching with and secrets key:values to our calling workflow

But we’re only scanning latest

A CVE scan is more valuable if it’s scanning each PR commit

1. We’ll need to ensure our Docker Build creates a unique image tag for each PR commit

2. Also, we’ll need to wait for Docker Build to finish before trying to scan

• We’ll enhance the Docker Build in today’s Homework!

Permissions in reusable workflows!

• Below is a "calling" workflow. Notice the Job-based permissions
• We always need to pass necessary permissions to the reusable workflow
• The reusable "called" workflow gets the calling "context", including GITHUB_TOKEN and these perms
• ProTip: Also set required perms in Reusable Workflow. Then, it’ll fail earily if calling doesn’t give them

name: Docker Build
on:
push:
  branches:
    - main
  pull_request:
jobs:
  call-docker-build:
    name: Call Docker Build
    uses: mostlydevops/actions/.github/workflows/reusable-docker-build.yaml@main
    permissions:
      packages: write
      pull-requests: write
    with:
      image-name: ghcr.io/mostlydevops/wordsmith-web

Examples of reusable workflows

Imagine all these being centrally controlled and automated for all software repos in your org

• The advanced Docker Build
• Image CVE Scanning with the Trivy Action
• Linting Action with Super-Linter (50+ linters in one Action)
• Complex testing designs (unit + integration + E2E in one Workflow)
• Smoke test any PR commit by deploying to a k8s cluster and waiting for probes to pass
• Static analysis (code quality, security, etc) with CodeQL
• Create PR preview environments with Uffizzi or Okteto. Built on PR open and destroyed on PR close
• PR bots that auto-assign reviewers, assign labels, etc
• Automatically rebase PRs when they get out of date from main
• Sync labels (names, colors, descriptions) across repos
• Create a OpenSSF scorecard of your repos
• Watch GitHub runners for bad behavior while your workflows run

Workshop 2 homework recap

• Did everyone get the Docker reusable workflow working in web and api?
• You’ll need those images built for next week
• I threw in a few minor issues like…
  • Finding the right uses: path for the reusable workflow
  • .yaml vs .yml in file paths
  • secrets: and with: were empty arrays and invalid YAML. Comment them out
• If you don’t see a workflow run in PR like you expect, check the Actions tab
• If it’s done correctly, github.com/orgs/<org-name>/packages shows two images
  • Both repositories should have an image with tags similar to stable-20230714-b3cc954
• Check HardlyDevOps for a working example

🧑‍💻 Prep for next week

• Next week we’re shifting to Argo CD on Kubernetes
• You need a Kubernetes cluster for Argo CD. I’ll be using Docker Desktop
• Any K8s is fine, even k3d (Kubernetes in Docker), minikube, or kind
• Let me know if you need help with setup or a K8s cluster to use (single node)
• Wednesday’s reusable Docker builds homework is REQUIRED for next week
  • (we need those latest and stable-<date>-<sha> images to deploy)
• You’ll get a video on GitOps and Argo CD before Monday to prep the basics

Wrap-up

• That’s it for today
• Monday is in Zoom on Argo CD setup
• Remember you’ll get a short GitOps video before Monday as prep
• Take tech topic questions to the Maven class community
• For schedule, logistics, and feedback: help@bretfisher.com

More about Argo’s history

• Project started in 2017, grew within Intuit, and exploded in popularity
• Intuit open-sourced it in 2018. Today Intuit uses it for:
  • 14,000 apps in 3,300 git repos
  • 5k developers doing 1,000 deployments per day
  • On 350 clusters with 15,000 nodes
• The parent project, Argo, also has "Workflows", "Events", and "Rollouts"
• Akuity is a startup by a few of the Argo founders
• Akuity was on my show last year, and is a SaaS platform for Argo

Argo CD core concepts

Argo CD concept dictionary

Argo CD architecture setup options

• Namespace scoped: One Argo CD per namespace
  • In enterprise: Dev’s manage their own Argo CD in their namespace. HA not required
• Workload clusters: One Argo CD per cluster
  • Most popular. Mgmt overhead grows with # of clusters. HA not required
• Control plane cluster: One Argo CD for multiple clusters
  • Inevitable without tight IaC control. Reduces overhead, but SPOF . HA highly encouraged
• Hybrid: Argo of Argo’s. Central Argo CD deploys Argo CD to each cluster
• Akuity SaaS: Argo of Argo’s with more automation and easier management

Wrap-up

• That’s it for today
• Homework: Install Argo CD on your own cluster by Wednesday
• Extra Credit for the over achievers
• Wednesday we’ll deploy our app multiple ways with Argo CD!
• Take tech topic questions to the Maven class community
• For schedule, logistics, and feedback: help@bretfisher.com

+ Mic Time!

• Raise your hand in Zoom reactions to share your answer

Which Argo CD setup design do you think you’ll use?

• One instance per cluster?
• One multi-cluster instance?
• Argo-of-Argos where a central Argo CD manages an Argo-per-cluster design (Akuity)?