Ketch
Deploying Applications to Kubernetes from your CI Pipeline
January 7, 2021by Jim Shilts
0 Comments
Now that we know the advantages of leveraging Ketch over other tools such as Helm to ease the deployment of our applications (BLOG: Helm vs. Ketch when Deploying Applications), a good next step is for us to understand how we can tie Ketch to our CI pipeline and have an automated deployment process. For this example, we will leverage Ketch, GitHub Actions, and a Kubernetes cluster on Google Kubernetes Engine (GKE).
GitHub Actions are event-driven, meaning that you can run a series of commands after a specified event has occurred, which is excellent when automating your application deployment with Ketch as you can leverage Ketch across the different steps of your application deployment lifecycle.
For this example, we assume you already have:
Here is what we will deliver as part of this post:
GitHub: We will leverage the same podinfo application we used in our previous post. As explained before, we removed all code and files related to Helm Chart and Kustomize from the original podinfo application source code as Ketch won’t need those to deploy the application. The source code can be found here: https://github.com/brunoa19/podinfo.
GitHub Actions: We will leverage GitHub actions for:
GKE: Even though you can use Ketch with pretty much any available Kubernetes provider, for this example, we will use Google’s Kubernetes Engine.
GitHub Secrets
We will use the gcloud CLI to fetch the kubeconfig from our GKE cluster, where we will deploy our podinfo application. To store the information required to create the cluster config and deploy our application to our cluster, we will use GitHub Secrets.
Let’s create our secrets! To get started, go to the “Settings” tab in your project and click “Secrets” in the sidebar. Click on “New repository secret.”
You will need to create the following secrets:
Using the GitHub secrets in your workflow is relatively straightforward. Each secret gets added as an environment variable prefixed with “secrets”, which means we can easily use them when creating our config file.
Pipeline Settings
In this example, we will use our actions when there are either push or pull requests on our “main” branch. Our pipeline config file is stored inside .github/workflows directory, using a file called gke.yml
While we are using the PROJECT_ID secret that we have set before, we are also pre-setting variables such as GKE_CLUSTER, GKE_ZONE, and DEPLOYMENT_NAME. If you want to further automate your pipeline, you can also set these as Secrets on GitHub instead of hardcoding it in the pipeline config file.
Setting Up gcloud
Using the steps above, we are:
The steps above build our podinfo image using the Dockerfile present in the repository and, once built, storing the image in our Google Container Registry.
Setting Up Ketch and Deploying Our Application
Following the steps above, GitHub Actions will first setup Ketch by downloading Ketch’s v0.1.1 CLI and allowing it to be executed.
With Ketch’s CLI downloaded, our pipeline will then:
Source Code
You can find the complete GitHub Action code used for this example here:
https://github.com/brunoa19/podinfo/blob/main/.github/workflows/gke.yml
In the next blog post, we will cover how you can easily automate the deployment of applications with multiple services using Ketch, GitHub Actions, and Kubernetes. As always, Ketch’s object is to allow you to continue focusing on your application code rather than Kubernetes objects, charts, and others.
Ketch is an open-source application delivery framework created by Shipa that makes it extremely easy for developers to deploy and manage applications on Kubernetes using a simple command-line interface. No YAML is required!