Promote Container Images across Environments with Weave Cloud: Deploy
Weave Cloud Deploy is a Continuous Deployment/Delivery operator for Kubernetes which makes it super easy to automate releases to a cluster - but what about multiple clusters? Weave Cloud Deploy can filter tags - by tagging each image with an environment specific prefix, it’s possible for the same image build to be automatically released to each environment in turn.
Weave Cloud: Deploy is a Continuous Deployment/Delivery operator for Kubernetes. It automatically updates the workload manifest files you’ve stored in Git, whenever a new, matching container image tag is detected and then applies those, (and any other config changes), made in Git.
Weave Flux is the open source project by which we achieve this, and deploy Weave Cloud itself - as described in our GitOps blog posts.
Installing Flux makes it super easy to automate releases to a cluster - but what about multiple clusters? First let’s look at container image tags - and the versioning of images.
Tag Versioning
The “Pets vs Cattle” meme refers to the movement in applications and infrastructure towards disposable components (cattle) and away from unique components (pets) that are treated with special care.
At Weaveworks, our internal applications are not given Semantic Versions, but instead images are built with a version that matches a pattern like $branch-$commit_short_id
Build versions are disposable. A full container image name and version could look like weaveworks/service:master-49911e5
For container images, tags are the version - a kind of alias for the actual address of the final layer, and they can be applied, or indeed removed, at any time after the image is created.
The choice of $commit_short_id is one of convenience, it’s a relatively unique number and readily available - when there’s a lot of builds, having to coordinate on a centralised version numbering system would be painful. Adopting the CICD pattern is intended to, and does lead to a greater velocity - which means more builds, and more builds means more image tags. (Learn more about a Weave Cloud user who’s now deploying 30 times a day).
Multi-cluster Pipeline
Weave Cloud: Deploy can filter on container image tags - meaning that only tags that match the filter will have manifests updated, triggering the deployment to cluster in which it’s installed.
Consider a three cluster pipeline: Development, UAT and Production. Each cluster has its own CI pipeline with various tests and Flux runs in each cluster, configured to deploy image tags that match $cluster-$branch-$commit_short_id
The image only needs to be built once, but it can be tagged differently for each environment. At the end of whatever tests each of the per-cluster pipelines the CI system is running, it adds the tag for the next environment, and Flux will deploy it.
Our fully qualified container image tag would now look like weaveworks/service:prod-master-49911e5
The image isn’t rebuilt for each environment, which gives us confidence that the image that gets deployed is the image that was tested successfully at each stage. Learn more about the importance of and how to secure a CICD pipeline.
Summary
It’s easy to automate a container image deployment through multiple environments, using Weave Cloud: Deploy, by filtering on container image tags. That means you can deploy with greater confidence - leading to fewer bugs, fewer risks and more time developing code.
Sign up for a free 14 day trial of Weave Cloud to give it a try.
