As most blog post ideas start, a question from a customer for how to handle base image updates using Helm Charts.

The question stems from Container OS & Framework Patching requirements.

“…if the release pipelines are controlled by Azure DevOps, how would they be notified of the change?

• Do I create a Pipeline triggered by the Azure Container Registry webhook?
• What if I’m using Helm for example? Usually building (and hopefully storing in ACR) of the Helm chart happens in the build pipeline, how would that be handled with a base image update?”

As noted, ACR supports webhooks. Which is the preferred way to trigger a deployment, post build. For two primary reasons:

• When geo-replicating a registry, users may push from East US, and have deployments in East US, West Europe and Australia. If the release system attempts to deploy these three regions as soon as build is done, the distant regions will fail as the images haven’t been replicated yet.
• An evolving Quarantine Pattern, that limits an image from being pulled until it’s scan is complete.

ACR supports regional webhooks, and Azure Event Grid notifications. This way you can trigger the West Europe and Australian deployments as the images arrive locally.

Here’s a relevant post: Working with ACR Geo-replication notifications

What about Helm Chart Webhooks?

Helm Chart Webhook events will start showing up at the end of November. Helm Chart webhooks will help when you have chart updates.

Base Image Updates – What to do…

To make sure I answered the question, I re-read and there’s a subtlety here:

• Do you update when a chart is changed?
• Do you update when an image has changed?

When a chart has changed, you likely want it deployed. Assuming that was the reason you updated the chart.

When an image is updated, do you want it deployed as well?

What might trigger an updated image?

• Code change – (git commit) that automatically rebuilt, tested and pushed the image
• OS & Framework Patching – (Base Image Update) that also automatically rebuilt, tested and pushed the image.

If you follow a unique tagging pattern (Best practices for tagging and versioning docker images), you’ll want to monitor updates to a specific image repository. As new tags are pushed, you’ll trigger the deployment. Using the same webhooks, or Azure Event Grid notifications, monitor the webhooks and trigger a deployment.

Chart Based Deployments

In summary, the main point: when updates happen as a result of code commits or base image updates, use Helm Charts for your deployments. By making OS & Framework patching follow the same flow as your code changes, you’ll leverage all the work you’ve already put in place.

In the CI/CD Pipeline workflows, the key points are:

• Decouple CI from CD
• Base CD on events, including Chart Updates and Image updates
• Be sure you’re thinking globally, as you’ll want a geo-replicated registry to enable local image pulls, which means there’s latency between an image push and when an image is available locally
• Create checksum that handles missed webhooks as “stuff happens”.

Steve