Today we announced our Container Delivery Pipeline (CDP) features of Cloud 66 Skycap. In this short post I wanted to add some more technical information around what CDP is and how you can use it with your new Kubernetes cluster you just fired up.
With your Kubernetes cluster up and running, you need to build your code into Docker images and write Kubernetes configuration files. Apply those configuration files to your cluster and your app is now running on Kubernetes. Simple! Right?
Well. It depends.
CDP is everything you need to deploy your application to Kubernetes.
Here is a typical Skycap pipeline:
Items with a green star are the ones you usually perform with a CI solution like Jenkins.
Let's look at the pipeline in a bit more detail:
You need to turn your code into a Docker image. Skycap runs your Dockerfiles on a set of secure and powerful servers we call BuildGrid for you. Skycap supports build cascades and secrets during build as it supports Habitus.
You can run your unit tests as part of the build process if you want.
You might want to use pre-built images (like the official Redis image) or use your own CI solution to build the images. Skycap can pull those images in, retag them with a Deployment Tag for tracking and consistency.
The result of the build or retagging is then stored in a private Docker registry. All Skycap pipelines come with a private Docker registry but you can bring your own registry as well if you want.
With an application living turning into tens if not hundreds of Docker images and containers, asset management becomes an important part of deployment. All assets (built and pre-built) images are tagged, labeled and annotated.
Are you using a base image with known security vulnerabilities? How about leaving secrets behind in one of the images. This step makes sure those don't happen.
With all your images available and an application composition file (like Docker compose file), you can bring up the entire stack and run integration tests before a deployment. This will test your application as it will be in production.
Kubernetes Configuration Templates
Store your preferred Kubernetes templates in a git repository and ensure your team uses those for any new development. If you prefer to have a log-shipping sidecar for all production pods, here is where you can enforce that. With Stencils you can:
- Have environment variations for each configuration files.
- Use inlines to keep configuration files DRY.
- Benefit from placeholders that are much more than a markup and understand Kubernetes configuration files and the order they should be applied to a cluster.
You can use Helm charts if you like as well.
Using Copper, the open source Kubernetes configuration file police, you can make sure any change in Kubernetes configuration files generated from Stencils comply with your requirement like no use of
latest as a tag or requiring a sign off from you if the static IP address of the load balancer is changed.
With Deployment Workflow, you can do things like: Deploy to Staging, ask for a sign off from your Ops team and your client before proceeding to Production. Or perhaps you want another team member to eyeball your changes in the configuration before rolling them out.
As Kubernetes configuration files can potentially contain secrets and can be applied with a Kuberentes client key, you can move the generation (rendering) part of the configuration files onto a secure sever where secrets are added to the configuration and you have the credentials to apply the changes to your cluster without risking security.
Like any good deployment tool, you can ask for certain conditions to be raised and stop the deployment. This could be a violation on Copper policies or a routine process to check everything before going live!
We think using Skycap is the easiest way to deploy your application to Kubernetes. Skycap provides you with all the building blocks you need for a deployment pipeline into your cluster as a hosted service.