My last post was a bit on the dry/theory/boring side. But, necessary to tee up where I’m going now. This post, and a good number of the following, will be focused on implementing a CI/CD pipeline that spans on-prem and public cloud.

I’ll use Spinnaker for CD, Travis CI for CI, Docker Hub for image registry, and Github for git repo. I’ll also make use of Cluster API as posted previously. Full disclosure: I have no bias for the CI/image registry/Git repo. As with the CD component, there are many options. I currently work at Armory.io, so I do have a bias for Spinnaker.

Let’s get to it…

K8s cluster with pre-reqs assumed, we need only two additional items for Spinnaker to be up and running: The operator/CRDs and the spinsvc defined for the operator to do its work. The Spinnaker service is actually a combination of many micro-services (Spinnaker architecture). I won’t dive deep on the installation and config here, the Armory website has a page dedicated to the methods located here. The easiest way to get Spinnaker up and running is with the Minnaker method. Supply a linux VM and in a matter of minutes, you have a fully configured and functioning instance.

Once you have your CD platform running, you need to configure it to connect to your various endpoints. As an example, we can connect Spinnaker to AWS or GCP to deploy machines in each. In this case, I want to deploy K8s clusters to vSphere and AWS. Provisioning K8s clusters is not a native function of Spinnaker, nor other CD platforms. For this, I’ve configured a cluster API management cluster to perform K8s cluster provisioning in each. I am using the Spinnaker capability to deploy K8s manifests to create clusters via cluster api and then deploy services directly to them. I’m using the Armory Agent for K8s to provision clusters that are pre-configured to connect to my Spinnaker instance. Through the use of execution-time artifacts, I’m able to reference the clusters in downstream stages and pipelines. This allows me to deploy manifests to them in the latter stages.

So, the workflow will go like this: Build a new image and push to registry, Spinnaker triggers pipeline off that build, the image is passed in with its name and tag attributes, we assign that to an artifact for reference later, Spinnaker runs a ‘deploy manifest’ stage – calling. a manifest artifact from our git repo that instructs cluster api to create a new cluster, the new cluster is provisioned with the Armory Agent for K8s, allowing us to deploy to it. In my next post, I’ll cover defining the pipeline in Spinnaker and deploying the cluster to vSphere as part of deploying an updated service.