Table Of Content

Part 1: Intro to containers, Kubernetes and DevOps

Part 2: Getting started (setting up my dev environment)

Part 3: My first app –  .net core, vscode, WSL, containerize and deploy to local k8s AND debug it while running in k8s??? GTFOH

Part 4: Deploy to k8s in the cloud (Azure Container Service – AKS) and debug from VSCode

Part 5: Set up CI/CD pipeline for Kubernetes using DevOps best practices (comming soon)

Part 6: Debugging generic Kubernetes Clusters with Draft (coming soon)

Intro to Containers, Kubernetes and DevOps

The older I get, the less I want to learn new things. And even knowing  this is the first sign of being irrelevant in our industry, I find myself procrastinating until my back is against the wall.

Well guess what? My back is against the wall and the container/Kubernetes wave is about to full on tsunami my ass.

Yes I know. We all know. Containers and Kubernetes, that’s huge in our industry right now. But I didn’t really want to dive into another new technology. I barely knew what a container was. And what the heck is this Kubernetes nonsense? Orchestration? What does that even mean????? Why should I even care about any of this???

In this series, I’ll take you through my process as I struggle to understand containers, Kubernetes and how to rub DevOps on everything to make it better. All from the perspective of a traditional windows/web developer.

Back in my day (stone ages), I never cared about infrastructure of any kind. I was tasked to build software, and that’s all I cared about. I wrote in java/.net/node/python whatever language/technology of choice, threw it over the fence when it was done and hooray for that. Someone else can worry about where, what and how to deploy my app.

Me, I was on to my next software project!

Then came the advent of Virtual Machines and we thought we were super cool because we could virtualize a machine. Make sure the app worked on the VM, and deploy the VM. Lots of benefits to using VMs.

Fast forward to today and now, we can virtualize the OS so our containers  just contains what we need to run our apps. And there is so much cool stuff we can do with these containers.  Since the OS is virtualized and shared, we can stack a shit ton of containers onto a given piece of hardware. And the coolest part (at least for me as dev) is that I no longer have to worry about the whole “it works on my machine” problem. Guess what, if it is wonky in prod, I can run that exact same container locally and debug exactly what’s going on.

Cool. Super powerful and so far makes perfect sense.

So I rolled up my sleeves and started diving in.  I created a .net core web app targeting a Docker Linux container. I created a ci/cd pipeline using Visual Studio Team Services where anytime code was merged into master, the build would kick off, get the latest code, compile everything, run my unit tests and if everything looked good, the build would then create a Docker image and the build would then send that image to Azure Container Registry. My release pipeline would then take the container image from ACR and would deploy this into Azure App Service into my Dev, QA, and Prod environments.

So far so good and so far, nothing highly groundbreaking either.

Now don’t get me wrong, I was super pleased with my progress. But by using containers in Azure App Service, I realized I was missing out on a lot of coolness.

Where was the advanced deployment abilities and the self healing ability.

And that’s when a small light bulb went off. Ahhh… this must be where Kubernetes comes in. Doing a little digging, Kubernetes is an open source, cloud agnostic platform for managing your container and container based apps. It can do things like deployments, auto scale, auto heal and much much more.

Cool. That’s exactly what I wanted!

So I spun up a Kubernetes cluster using Azure Container Service (AKS). I spent a few days tweaking my environment. Then modified my release pipeline so instead of getting my container image from ACR and deploying to Azure App Service, I now got my image from ACR and then used a kubectl task to deploy my app into my Kubernetes cluster.

YESSSSS!!!!!!!!! Success. Talk about feeling super pleased with myself.

However, that super pleased feeling was also super short lived. Being raised by a dragon mother, I immediately started questioning myself and started to see how I could do things better.  I realized I was still only telling half the DevOps story.

The code part. The web code. I didn’t address any of the infrastructure that is involved with the app.

Hypothetically, maybe for my app to run right, I need to have 4 instances of the web app with a load balancer that connects up to a sql database, and blob storage somewhere. And that’s when I realized, in today’s DevOps world, as a dev, I can’t just not care at all about infrastructure anymore. How and what my app will run on is important.

It’s kind of like with quality. Back in my day when I first started writing code, we didn’t care about quality. We wrote code as fast as we possibly could and we had huge QA teams that would try to bolt on quality after the fact by testing our apps super carefully for us. In today’s DevOps world, we don’t have that luxury anymore and we have to build quality into our apps as we write it with things like massive amounts of unit tests.

Ok, fair enough. I need to at least think about infrastructure. And in this example, I needed to think about the infrastructure and how it will look like in a Kubernetes cluster.

That’s when I stumbled onto Helm. With Helm, I can describe everything about my container app using yml files. Using Helm, I can describe my 4 instances of my web app and my load balancer, my sql server, my redis cache or whatever. So basically, Infrastructure As Code for k8s. And also with Helm, I’m able to deploy, update or rollback my environment in k8s.

Remember how my old deployment just deployed my container (web code) into a pre-configured Kubernetes cluster?

Now I can modify my release so that it deploys my app (including the infrastructure in Kubernetes) as well as the actual container holding my web code. And since everything is in Azure, I can take this one step further. Not only can I deploy my app (container image) and the infrastructure within my Kubernetes cluster, I can even define and deploy my Kubernetes cluster and ACR.

Bam! DevOps nirvana.

I think I get it now. In modern DevOps, we can’t just look at the “code” or just the container part. That’s only half the story. We also need to automate and deploy the infrastructure. And that’s where Kubernetes and Helm come in.

But here comes the kicker.

At the end of the day, I’m just a dev. I write code. Lots and lots of super fun code. That’s what makes me ridiculously happy. Trying to figure out all this Kubernetes and Helm madness kind of makes my head explode.

I mean, I get it, but I am not an Ops person. I don’t have enough infrastructure knowledge. And I never will. I don’t know what best practices are or even any practices. I just want to write code!!!!!

So is there a way, is there a tool that will help simplify all of this? And the answer is yes.

Draft. Using Draft, it makes it super easy for me as a plain old school dev to build applications that run on Kubernetes. It helps me create my helm charts right along side my app code. Also with Draft, I’m able run everything in a local publically accessible environment.  And since everything is checked into source control,my other team mates with far more knowledge about ops and Kubernetes can tweak the helm charts. Everything then gets sent down our CI/CD pipeline and finally deployed into Azure in our dev/qa/prod environments.

DevOps Nirvana with Kubernetes!

So in the next few posts, I will walk you through, in excruciating detail, how an old school windows/web dev with no knowledge of containers can create an app for Kubernetes and how to set up a DevOps pipelines using Kubernetes, Helm and Draft.

Next> Part 2: Getting Started (Setting up my dev environment)