- Draft: Containerize apps for Azure Kubernetes Service - Thu, Jan 5 2023
- Azure Kubernetes Service vs. Kubernetes cluster - Wed, Aug 26 2020
- Web App for Containers on Azure - Wed, Feb 12 2020
Microsoft acquired container platform Deis from Engine Yard in 2017. You can read about that here. Deis is behind some of the most popular tools for building and managing applications on Kubernetes. Their projects include Helm, Brigade, and Containerd Wasm Shims. They also built Draft.
Draft streamlines the containerization of apps for Azure Kubernetes Service by detecting your application's language from the code, generating the needed Dockerfile, pushing it to a container registry as an image, generating the needed Kubernetes manifests or Helm charts for deployment, and then deploying the app to your Kubernetes cluster via a GitHub Actions workflow.
If you go with Helm or Kustomize, Draft generates what is needed to support these artifact types. If you chose Helm, Draft creates a charts folder in your app directory with the chart YAML files and a values.yaml file containing your app's specifics. If you choose Kustomize, Draft creates the overlays directory and a production directory inside with the necessary deployment and kustomization.yaml files. Draft simplifies creating the artifacts needed to run your app on Kubernetes so that you can stay more focused on building and maintaining the app itself.
Deis still exists but has been renamed to Deis Labs with a bolstered team of new colleagues and resources within the Cloud Native Compute Team of Microsoft. Deis Labs continues to work on open-source projects to this day. One of these projects is Draft.
Currently, there is the open-source version of Draft found here and the newer Draft 2, aka Draft for Azure Kubernetes Service (AKS) (preview), found here. The team at Microsoft decided to breathe new life into Draft, releasing an updated version and integrating the Draft experience into AKS. Draft 2 is wrapped up in the Azure CLI as an extension and works directly with the cloud now. One difference between the versions can be seen in the commands you run with Draft:
Draft commands start with:
whereas Draft for AKS commands start with this command:
az aks draft
Future versions of Draft will add it as a GUI-based extension in Visual Studio Code, and later bring Draft into the Azure portal.
- Create a Dockerfile
- Create the Kubernetes manifest files for deployment and service
- Connect our Azure to our GitHub repository
- Create a GitHub Actions workflow
- Run the GitHub Actions workflow to build our containerized app, push it to the Azure Container Registry, and deploy our app on Azure Kubernetes Service
- Azure subscription
- Resource group to hold all components
- Azure Container Registry
- AKS cluster
- Application code hosted in a GitHub repository
- VS Code
- Azure CLI installed and logged into a proper Azure subscription
- GitHub CLI installed and logged into a GitHub.com account
- aks-preview Azure CLI extension
- Ability to run all code from the VS Code Bash terminal
I will cover one prerequisite here, as it is specific to the scenario in this article. You will need the aks-preview Azure CLI extension installed in your VS Code after you have the Azure CLI. To install the aks-preview Azure CLI extension, run the following from the Bash terminal in VS code:
# Install the aks-preview extension az extension add --name aks-preview # Update the extension to make sure you have the latest version installed az extension update --name aks-preview
Now, let us dive into the steps to go from a noncontainerized app to an app running on AKS.
Create your Dockerfile
Enter the port your app will use. Draft will then create a Dockerfile for the app.
NOTE: Test the Dockerfile locally to ensure it runs. If it does not run locally, it will error out during the GitHub Action workflow > Build and push to ACR.
To test locally, use Docker Desktop and run:
docker build -t NAMEOFYOURIMAGE . docker run -d --name NAMEOFCONTAINER NAMEOFYOURIMAGE
Create Kubernetes deployment files
After Draft creates the Dockerfile, it will then prompt you to create a K8s deployment. Notice how you can navigate via arrows.
After you choose manifests, it will prompt you for the exposed port.
It will then prompt you for the name of the app.
It then creates a K8s manifest file.
NOTE: The name of the app should be lowercase. If not, it will fail during K8s deployment later.
If you run ls on the directory or navigate to it, you can see the Dockerfile and a folder with the manifest files for K8s deployment and service.
Connect Azure to the GitHub repository
Ensure you have the GitHub CLI installed. Instructions can be found here.
Run the following command to ensure you are logged into your GitHub.com account from VS Code:
gh auth login
Note: Create your resource group before this. Ensure that this is the same resource group that contains your AKS cluster and ACR.
Next, run this command:
az aks draft setup-gh
NOTE: Do not include https://github.com/ after Enter github organization and repo (organization/repoName). Enter it in this format instead: Buchatech/ContainerizedTodoApp.
After a couple of minutes, it will complete.
You should see the new app registration in your Azure subscription under Azure Active Directory > App registrations.
In the app registration, you should see the following credentials indicating that OIDC has been set up to connect to your GitHub repo.
In your GitHub repo, you should see the following secrets created under Actions:
Create the GitHub Action workflow
Note that you should have an Azure Container Registry and an AKS cluster created before continuing.
In your VS code bash terminal, run az aks draft generate-workflow
The YAML file is generated for the GitHub Actions workflow in your app folder.
Commit all the files to your repository, and the GitHub Actions workflow will start. The GitHub Actions workflow will build, push your container to ACR, and deploy the app to the AKS cluster.
In GitHub, click Actions to see your workflow starting to run, as shown in the following screenshot.
If you click the workflow run, you can see a summary of the workflow jobs, as shown in the following screenshots:
The GitHub Actions workflow should complete quickly.
After the workflow completes, you can go into AKS on the Azure Portal and see the secret that the workflow created in your AKS cluster, as shown in the following screenshot:
In AKS, click Workloads to see that the containerized app deployment is up and running on AKS.
You can see the load balancer for the app and its external IP by clicking Services and ingresses in AKS. The load balancer and external IP will be shown on the Services tab, as shown in the following screenshot:
You can click the external IP to access the app in the browser, as shown in the following screenshot:
Subscribe to 4sysops newsletter!
Thanks for reading this blog post. The next step is to go try out Draft for AKS on your own.