We’ve come a long way with understanding and leveraging acs-engine but wait, there is more to it. We can also add Windows Agents to the mix a deploy a specific Kubernetes version.
In the previous post, I showed you how easy it is to deploy a basic K8s cluster using acs-engine. That’s great and all but most deployments requires you to consider the existing Azure environment and customer requirements. In this post, we will play a bit with custom VNet and Azure managed disks.
Now that we have all tools installed and a working IDE, it’s time to deploy an actual Kubernetes cluster using acs-engine.
Time to get all pieces in place. In order to start deploying K8s cluster using acs-engine, we need to start getting all of our tools inline such as Azure CLI, IDE environment, and the actual acs-engine binaries.
In the past few weeks, I’ve been doing some work on deploying Kubernetes clusters using Azure Container Service Engine aka acs-engine so I thought this might be a great topic to do a multiple parts blog series.
It’s time to become a member of the DevOps team and deploy our application to production. If you think we used Azure Container Registry only to deploy containers on top of DC/OS in Azure, well, think again.
Now, when Azure Container Registry contains our repository, new containers can be deployed out of it. Let’s switch role and become members of the Integration team as our role now is to deploy the application at scale on the DC/OS cluster deployed on Azure.
Now that we have all our puzzle pieces in place the real fun begins as we start to move containers around. From the developer laptop through the integration team tests and finally to a running container in production. Let’s get it on with playing the developer role…
© 2012-2018 I'm all vIRTUAL