🗓️ What's new this week
🔴 Live show today June 29th: Istio Ambient Mesh and Solo.io
This week my co-host will be Nirmal Mehta and we'll welcome Idit Levine, Founder/CEO of Solo.io, to the show. Idit focuses on Service Mesh, API-GW and Multi-Cloud networking, and security. She’s been involved in the Containers/DevOps community for 10+ years, building products from Docker to Envoy to Kubernetes, and now Istio and Cilium.We have lots to talk about -- Istio, Ambient Mesh, Envoy, Zero-Trust Security, Cilium, eBPF, Multi-Cloud -- and I hope we can get to it all. Thursday at 13:00 US ET (UTC-4).
🎧 Launching Friday June 30th on the Podcast
Ep 135: AWS containers with Corey Quinn
We're releasing a podcast this week. My co-host Matt Williams and I go on an AWS adventure with Corey Quinn, the Chief Cloud Economist at the Duckbill Group. You may have seen or heard some of his in-depth AWS content, including his Last Week in AWS newsletter and blog, Corey's podcast Screaming in the Cloud and the AWS Morning Brief, or his highly produced YouTube videos on the Last Week in AWS channel.
Corey runs the Duckbill Group, a company of people focused on helping clients understand and manage their cloud spend. If I had to describe Corey in a sentence, he's a quick-thinking AWS expert who is one part cloud strategist and one part sarcasm.
The inspiration for this show came from his blog series focused on all the ways to run containers on AWS, which is to say there's a lot; dozens of ways, in fact, which I took as a testament to how containers have won the cloud as the primary way to package and deploy software to servers. Enjoy!
👨💻 What I'm working on
New stuff in Docker Mastery
I just finished updating a section in my Docker Mastery course on Udemy. The section is titled Inspecting Kubernetes Resources. Originally, it was just one video. I've added new content and broken it into 5 lectures and a quiz. All of the lectures are shorter than 9 minutes.
I also added a quiz to the Kubernetes Architecture and Install and Your First Pods sections.
😍 Why I prefer Docker’s official GitHub Actions
You may have heard I'm teaching GitHub Actions for DevOps, and I use Docker's GitHub Actions to do some heavy lifting. Why do I prefer Docker’s official GHAs rather than the default Actions or just docker commands at the shell?
I’ve seen many attempts to make tools that shortcut the traditional Dockerfile process. There’s a growing list of trendy tools, SaaS-based builders, and homemade automation on building lean-and-mean images.
But I keep returning to Docker’s BuildKit as the most feature-rich and flexible way to build all container images. I also use GitHub Actions (GHA) for my image builds, and rely on Docker’s Official GitHub Actions for my projects and my client's container builds.
Here’s just a few reasons I teach, implement, and recommend Docker’s GitHub Actions for all container image builds:
👉 BuildKit is the most used, feature-rich, and financially-supported image builder on the planet.
👉 Dockerfiles are universal and have a lot of newer features that solve many of the original 2013 limitations from when we all first learned basic Dockerfiles. I recommend learning the new BuildKit and “Dockerfile Frontend” features rather than replacing “docker build” with a bespoke 3rd party builder that might sound easier, but likely won’t solve all your problems in the long run.
👉 Caching is first class in BuildKit, and even more so on GitHub Actions. There’s image build layer caching, and even RUN line package caching (to speed up those long npm and pip installs). The cache can live outside a GHA runner so it’s used on every build. Oh and no Docker Hub pull limits on GHA public runners.
👉 The Docker team has a list of official actions that go well beyond the functionality of what other solutions can do. It’s worth your time to try them, and learn all the ways they can make better images.
👉 The Docker Metadata Action can easily generate multiple tags including PR#, branch names, datetime, build-id, and friendly reusable tags, all in a few lines of YAML. It’s super flexible and way more maintainable than the fancy shell scripts I tend to see others write for tagging images.
👉 The combo of these Actions provides parallel building of x86_64 and arm64 images to support Intel/AMD servers and Apple Silicon, and also properly push manifests for those platforms in one go.
👉 BuildKit can now automatically add Providence and SBOMs to image manifests.
❓What questions do you have about GitHub Actions workflow design? Respond in this LinkedIn post.
🐦 Tweet of the week
🐳 DockerCon IRL is Back!
(more news as we make plans for this hybrid event)
👀 In case you missed it
(headlines from last week's newsletter that you can skip if you already read it)
🔴 Live show: Cloud Native DevOps: Live Q&A (Ep 222), June 22, 2023
This week is our 100% ask-me-anything show with you! I'm joined by Matt and we're focused on cloud native DevOps Q&A.