Table Of Content
Part 5: Set up CI/CD pipeline for Kubernetes using DevOps best practices
Part 6: Debugging generic Kubernetes Clusters with Draft (coming soon)
DevOps pipelines for k8s
So we’ve finally come to creating DevOps pipelines for Kubernetes apps using DevOps best practices. Remember, our “app” is so much more than just our source code. And so much more than just the container image with our app running in it. Our app consists of a specific version of our container image as well as the Kubernetes configuration for that specific version.
In the previous installments, I walked through how to set up a dev environment, how to create an app, and how to containerize it using Draft or Azure Dev Spaces. And part of what Draft and what Azure Dev Spaces did was create an initial set of Helm charts that makes sense for the technology picked. Using Helm, I can create a Helm package which consists of an application image and the configurations for that image. And also using Helm, I can deploy that package (both image and configuration) into a Kubernetes cluster.
Bam! Everything I need. So now, my pipeline should look something like this.
- Compile/package up app
- Create image
- Push image to a Docker registry
- Create a Helm package (helm charts + the image that I just created)
- Store my Helm package somewhere
- Deploy the Helm package into a Kubernetes cluster.
Using Azure DevOps Project
Since I’m going to host my app in Azure using Azure Kubernetes Service, it makes sense for me to use VSTS as my DevOps tool. All right, question time. Who here likes building out pipelines? Honestly, I’m not a huge fan of building out pipelines. I know they are super important and I will do it because it’s absolutely needed. But my first love is slinging code. I sure wish there was a way to automatically build out my pipeline.
Guess what? There totally is. We have made it rediculously simple to go from nothing at all to a full end to end DevOps project. And what’s this DevOps project I speak of? It is your whole DevOps solution in a box. And this box contains 5 things. You get a team project in VSTS. You get sample code in the language that you pick in the git repo in your VSTS project. You get a build and release pipeline that makes sense for the technologies that you picked and you get infrastructure deployed out in Azure. And when it’s all done, it will send the sample app through the build and release pipeline all the way out to the infrastructure in Azure. And you get all of this with just a couple of clicks. Click here for a detailed description of Azure DevOps Projects.
Let’s see how we create a DevOps project for an app that will run in a Kubernetes cluster hosted in AKS.
Creating an Azure DevOps project for a .net core app running in AKS
- Browse to your portal and click on Create resource
- Click on DevOps Project
- Click on .NET and the Next
- Click on ASP.NET Core and the Next
- Click on Kubernetes Service and the Next
- We now get to a screen where we can either create a brand new VSTS account or use an existing one.
- I’m going to use my demo account named MSVSTSDemo-A, I’m going to name my project name AbelBlogDevOpsProjk8s, leave the azure infrastructure as default and click Done
The default infrastructure is a kubernetes cluster with 3 nodes with size Standard_D2_v2. If I wanted to configure this, I would just click on Change and configure my cluster size
- After clicking Done, all I need to do now is… nothing. Except wait. Just let Azure do its thing. It’s going to build me out my end to end DevOps project. A new team project in VSTS, sample .net core code in the repo, a build and release pipeline that makes sense for the technologies picked that will build and deploy my sample app into an AKS cluster it provisions for us in Azure. This takes quite a while so seriously, kick back and relax for a bit until it’s finished. When it’s finally done, you get a portal blade that looks like this
Yeah, literally. A couple of clicks and you get a full end to end DevOps project. All the links in this portal blade are deep links into the provisioned infrastructure. Along the left hand side, you see the CI/CD pipeline with links to the repo, build and release. Along the right hand side, you see all the resources provisioned in azure. The AKS cluster, application insight monitoring your app, and you even get a link to the external endpoint of your sample app that is already built and deployed.
will take us directly to the repo in VSTS
Notice this is just a git repo holding our .net core sample app with Helm charts and Docker file. Navigating to the build definition, you can see we created a build definition that makes sense for a .net core container app using helm charts.
We first build the container image of our sample app. Then we push that image to the Container Registry (which we provisioned for you). Next we install Helm onto the build agent and then create the helm package (this consists of the helm charts and a reference to the container image) and we publish that package back to VSTS as a build artifact.
Browsing to the release pipeline, you’ll see we create a release pipeline that again, makes sense for the technology picked. We use Helm to deploy the Helm package into the AKS cluster that we provisioned.
And finally, clicking on the external endpoint
built and deployed using our piplines all the way out into k8s in AKS provisioned by the AzureDevOps project. Pretty cool huh! End to end DevOps pipeline for k8s in AKS, all in a box.
Replacing the sample app with your real app
Azure DevOps projects are cool but the million dollar question of course is, how do i replace that sample app with my real app? Simple enough. Remember the repo holding the sample code is just a git repo. Simply clone the repo onto your hard drive, delete all the files (except don’t delete what’s in the .git directory), copy your real code there, commit, push and voila! Your app will now flow through the build and release pipeline all the way out into the AKS cluster.
So that’s what I did. I copied the app we created in the previous blog post into my cloned repo, commit and pushed back to vsts. The build kicked off and…
Looking at the error, it looks like my Helm package task couldn’t find the Chart.yaml file. And looking at our build definition, here is where I define where the Helm charts are
Which clearly doesn’t exist in my real code. Easy enough to fix, let’s click on the elipses and pick where my Helm charts are in the repo
Now lets save the build and queue it up again….
Bam! Success. My app was built, an image was created, pushed to my Azure Container Registry and a helm package was created. Which kicked off my release….
Failure!!! WHAAAAAT!!!!!! Looking at my release log…
Ugghh.. of course. My helm package isn’t called sampleapp anymore. My real app is called adsapp, Ok, easy enough. Jumping into my release definition
Lets change $(System.DefaultWorkingDirectory)/**/sampleapp-*.tgz to $(System.DefaultWorkingDirectory)/**/adsapp-*.tgz,
save it, kick off a new release….
WHAT!!!!!! What went wrong???? This was supposed to just work? Ok… time to debug. Let’s look at the release log and let’s look at the upgrade helm task.
Oh yeah, of course. My helm charts describe a container with only internal IP’s (I know practically nothing about ops, kubernetes etc so forgive me if my terminology is wrong). No external facing address. Ok I’ll tweek values.yaml file….
Check them in… wait for it to build… release… and….
When you talk about DevOps best practices and AKS, it makes sense to have a pipeline that will let us pull our source code from a repo, build an image and the Kubernetes configuration from the source and then push that into a Kubernetes cluster. Helm let’s us do just that. And scaffolding a helm pipeline into AKS is super easy to do with Azure DevOps projects.
Next> Debugging generic Kubernetes Clusters with Draft (coming soon)