Containerization Assist Integration with AKS VSCode Extension

Key Takeaways

But, if you need a pipeline for the actual deployment, then the next step is to go to this AKS deploy app with automated pipeline command. Hello and welcome to another exciting episode of Open at Microsoft. In today's episode, we are joined by Sneha, who is an engineer in developer experience upstream team within AKS. And we will cover the part two of the containerization assist by discussing developer experience enhancement, which are done by integrating containerization assist into VS Code via AKS VS Code extension. Welcome, Sneha. Thank you so much, Tatsat. Thank you for having me on this Open at Microsoft episode. And I'm super excited to show our viewers this new feature that we have in the Azure Kubernetes Service VS Code extension. That's awesome. So, do you want to start by defining what the containerization assist did? Because we had a part one to it, we can add the link to the description, and then likely a segway for the integration work which you have done. Yeah, of course. So, just to give a refresher, containerization assist or just to call it simply CA, it is a AI-powered tool that helps you containerize your applications from within your IDE. So, how it works is if you have your source code within VS within your VS Code IDE, you can hook it up as a MCP server and use the tools that it offers to generate all the deployment files that are needed to finally get that source code onto production environments such as AKS or AKS cluster. So, that means generating a production grade Dockerfile which has like multi stages and also generating the Kubernetes manifest such as deployment YAMLs or service YAMLs, ingress YAMLs and like depending on the project the different resources that are needed for deployment. So CA helps you create all of these resources with the help of AI and by first analyzing the repository, understanding the the architecture, the framework dependencies, all of these intricacies of your repository and then it decides on what kind of Dockerfile and manifest it needs to create and it does that by using a specialized knowledge base. So it uses that knowledge base to create these files and that's that's how it is kind of like different from what you can get in a general AI tool. And for today's episode, we are going to show like how we integrated this CA MCP server and we took these tools and integrated it into our Azure Kubernetes service VS Code extension. So our idea was kind of to help smoothen the developer process. So we integrated that into the very flow that a developer generally would use in a day-to-day basis within their IDE. That sounds very exciting and I can see already that how it can help from a lot of DevOps engineer in the early stage of their career to actually have from zero to hero kind of shimmed experience using their favorite IDE VS Code. Do we have any demo? Do you want to start sharing your screen? Yes, of course. I do have a demo today to show. And so let me know if you can see the repository here that I have opened already. Mhm. This is within VS Code and this is a simple Spring Boot app called Spring PetClinic. And we're going to see like how we can convert this simple source code into an actual running application onto AKS. And we can do all of that just by using our extension, which is the Azure Kubernetes Service Extension. So, this one needs to be installed first to use any of this feature. And we also recommend installing the GitHub Pull Request extension and the GitHub Actions extension, which can help you create the pull request right from the IDE the VS Code IDE and also you can monitor your GitHub workflows later on. And we'll get back to that later how we can do that. So, starting from the source code here in the Explorer we have all our code in here and it's a very simple flow. If you right click within the source code within the Explorer File Explorer, you'll see all these AKS commands that will come up here. And just a point to be noted, this is a preview feature right now. So, there is a preview flag that you need to turn on to see all these commands in here. So, the first thing that needs to be done when we are trying to containerize an app is generate the Dockerfile and the Kubernetes manifest, which are the basic artifacts that are going to help us finally deploy. So, the first command is generate Dockerfiles and K8s manifest. So, here you can see like there are like two options here and the first one is auto selected, which is generate deployment files. We also support generating GitHub workflows, which is a CICD pipeline, but we're going to get back to that later on. So, for now, we are going to focus just on the deployment files. So, this one actually uses your GitHub Copilot subscription, which is the language model that actually generates the file. And you can set up your own default model that you want to use. For example, we have the GPT 5.2 Codex as a default model set up right now, but you can also select any other model that you want to check out. For example, we'll just use the auto model now, the auto-selected one, which is the 5.3 Codex. Now, it will list down the subscription for you. And this is the subscription that we're going to use. Next up, we're already assuming that you are you already have your AKS cluster created. So, we I have my AKS cluster here, which is called SB2, and I'm going to select that. Next, we will see the list of namespaces that are available where we can deploy our app. And today, we're going to deploy it within the Spring Pet Clinic namespace. Now, for deployment, we need like for containerizing the image, we need to store that image in a container registry. And also, on top of that, that container registry needs to be attached to your cluster. So, what we do here is we're showing the exact container registry, which is already attached to your cluster. So, here you can see the DT test ACR. This particular one is already attached to my cluster SB2. And in case if you don't have the the container registry attached, you can do that right from here. So you will get an option if you want to set up the attachment and you can go through it. It is completely optional. You can do it outside VS Code as well, but just for simplicity and so that you don't have to do context switching, we also offer that here. That's amazing. And now the final generation is actually happening underneath. What is happening is we are using CA's analyze tool to analyze this report, detect the language, the framework, the dependencies, all of that stuff and then we are creating a structured prompt using that analysis and sending back to the LLM that we selected earlier, the model, which is the 5.3 Codex model. And that LLM is actually writing or creating these files. Here we can see the Dockerfile has already been generated here. And all the right ports are detected. And next up it is generating the Kubernetes manifests. So depending on your project structure, it will create the necessary resources, Kubernetes resources. Of course, we need a deployment file here. And you can see it has already populated your ACR link here so that the image is actually pulled from the right ACR. And there is this ingress YAML and the service YAML as well. And the config map, if required, that is also going to be generated. And you can see the banner that it was created by containerization assist using AI. Now, what we have here is a Dockerfile and the Kubernetes manifest. So, as I said, these are the main files that you need for containerizing your app. And you can of course use a CubeCTL CLI to just apply it all these raw manifests onto your AKS cluster. Uh and but you can just uh push the Docker file and containerize the image and push it into ACR. But instead of doing all of that manually in a production scenario, you are always going to use a CI/CD pipeline, which will take care of the actual building and the deployment part. So, the next step, the next like intuitive and obvious step comes as the generation of an automated pipeline. And we also offer that here. And in case you have uh your own pipeline set up, then you don't your step kind of ends here. You can commit your all the files that are generated and create a pull request for review. But if you need a pipeline for the actual deployment, then the next step is to go to this AKS deploy app with automated pipeline command. And this is the the option that I was talking about earlier. You'll see it has already been preselected here, the generation of the GitHub workflow. And we're kind of going to to the same flow that we did for generation of the deployment artifacts, which is selection of the subscription and the clusters where we are going to deploy. And the name space is spring-petclinic-1. And that's the ACR. So, this is the auto generated name for the pipeline and the user can change that to their liking. We will just it as it is, which is deploy Spring Pet Clinic KS. Now, since we just generated the Dockerfile in the earlier step, it will auto-detect the Dockerfile here. And I'll just confirm that this is the right file. And the build context will be from the root, so this is also correct. And here it also detected the correct Kubernetes YAMLs that got generated earlier. So, we are going to select those as well. Now, this is an interesting thing you can see here. So, it says your pipeline needs an Azure managed identity to connect to AKS. Now, when we are creating this GitHub workflow, that particular workflow still doesn't have access to the user's Azure resources. So, we first need to give access to the pipeline so that it can access those resources. And for that purpose, we need something called OIDC Federation. So, we need to create a managed identity and also a federated identity credential on top of that managed identity, which can access the user's repo and also can actually push the images to the user's ACR and deploy to AK to their AKS cluster. And all of this requires setting up the actual managed identity, the OIDC credential, setting up the right role assignments. So, it is all a few steps here. And this is where we kind of make it easy for the user to get their app right from their IDE to AKS. So, if we go here and click on this configure pipeline with managed identity, you can see it asks for a resource group name. And I will actually change this resource group to the one that I was using earlier. Okay. so here you will get the option of creating a new managed identity or using an existing one. So, you can have an existing one which already has all the right like role assignments created or assigned to it. In that case, you don't need to create a new one, but here I'm going to create a new one and show you how that flow looks like. And for example, the managed identity name let's do MI test as he for now. And we will deploy to East US region. And make sure it's so this is the warning which says that it will this particular managed identity will get created and it will get access to this particular repo which is my repo for the source code of the Spring Pet Clinic project. And this is the issue of the token which is GitHub. So, GitHub will is going to issue the token to our managed identity for easy access to our resources. And we will here go ahead and proceed and now we can see it is setting up all the role assignments for us. So, we don't have to worry about like setting or knowing exact role assignments which are needed for deploying this app. So, the managed identity has been created and configured, but there is yet a few steps needed for the pipeline to actually work which is setting the secrets of these managed this managed identity that just got created. So, it has a client ID, a tenant ID. So, these these IDs need to be set in your actual GitHub repo. So, the repo where your project lives. And you can of course just copy the secrets and set it manually, but again, we don't want the user to or the developer to switch between their ID and their and GitHub like all the time. So, you can just do set secrets here. And it will set the right secrets to your uh repository correctly. Now, let's see what got generated in here. So, this is the pipeline that got generated. And we have two stages, which is the first one is a build stage, where we are using that Dockerfile and building our image and pushing that to ACR. And finally, we are using the GitHub actions to deploy that particular image to the user's AKS cluster. So, now that we have all these files created that are needed for the deployment, we can go ahead and commit this. And as I said earlier, like if you have the GitHub pull request extension already installed, it becomes super easy to create the PR right from your VS Code. So, that is something that I'm going to do right now. So, this is and deployment files. And now we can see the PR got created. Well, let's go to GitHub here. >> Woohoo! I can see the pull request. Okay. >> Yes. So, we have the pull request open and all the files that were generated are here. So, basically this is just all you need to actually get your app running on EKS. And this is one such amazing feature, I believe, that from where the repo was when we started about 10 minutes ago. And we had no manifestation manifest files. From there till opening a pull request, because now we have an appropriate file for even deploying the tool. Um this kind of guidance really help a lot of people who are in their learning journey and kind of make a lot of dry topics in terms of converting people's use code bases into EKS specific code bases much more easy and journey becomes much more relevant through the cause they're aiming for. So, um I love this feature. This is amazing. Exactly. Yeah. >> Um Thank you. So, what next in these feature and where if people want to raise more feature requests or any kind of usage, what where they can land their feature request? Um for this work. So, uh yeah, as you said, so the whole idea is to you create the create a smoother workflow for the developer and make their life easier so that they can just focus on developing and writing code and not about develop about deploying the application. Now, the repository that I showed you, this is a very simple repository which has just one module that needs to be deployed. But of course, there can be scenarios where you have a mono repo with multiple modules. So, the next feature that we are focusing on is to support such mono repos where we can deploy different multiple modules at the same time. So, watch out for that. That'll be the next feature. And also, if you want to check out the repository of the actual AKS VS Code extension, this is the one. Please, if you feel this is a great feature, then leave a star here, and we will love to see your contribution in any of the open issues in here. And also, if any of the viewers have any feature requests that you want to see in your favorite extension, then please feel free to leave a feature request in the issues here. And another thing I wanted to mention is the documentation. So, the whole process that I showed you, I know it can be a lot of steps, but it has been documented very clearly in this particular documentation. So, right from the exact role assignments that we are creating to how like where you need to go, where you need to click, what are the existing extensions that you need to install beforehand, all of that has been documented very clearly in this extension and this documentation. So, please go ahead and give it a read. That is amazing, Snehal. I love this from zero to hero in about few seconds. Um is something I'm sure everybody is going to try and be excited about. I'm really looking forward for the next features around this. Uh thank you so much for taking time and demoing that for us. Really appreciate it. Thanks, Snehal. >> Yeah, of course.