Get Started with Mirantis Container Cloud on Microsoft Azure

Eric Gregory - November 4, 2021 - , , , , ,

This week, we’re excited to announce that Mirantis Container Cloud officially supports Microsoft Azure deployment. For those who wish to experiment with this new feature using a trial license — or deploy to Azure with an existing license — we’ve created this walkthrough to help you get started.

In this guide, we will show you how to:

  • Deploy Mirantis Container Cloud to Azure
  • Configure a user
  • Create a Kubernetes cluster from the Container Cloud interface (full license only)
  • View and manage your clusters with Lens

Note: While you can explore Mirantis Container Cloud for free using a trial license, following this guide may incur costs on Microsoft Azure. Be sure to carefully review the required Azure resources and their associated costs.

Table of Contents


This guide assumes a basic level of fluency with both Microsoft Azure and the Linux command line. We will walk through each step so that a relative beginner can follow along, but make sure you are familiar with cost structures on Azure before you begin.

To get started, here are the core requirements you will need to prepare:

  • Microsoft Azure Account and Resources
  • Mirantis Container Cloud Account and License
  • An Ubuntu machine (either a personal computer or VM) that you will use to configure and prepare the bootstrap environment for Mirantis Container Cloud

Microsoft Azure Account and Resources

You will need a Microsoft Azure account to deploy Mirantis Container Cloud to Azure. If you don’t have one already, you can sign up for a free account here.

Cloud resources on Azure are made available by account quota. You will need the following resources to deploy Mirantis Container Cloud:

Azure Resource Quota Requirement
Standard FSv2 Family vCPUs 8 per node (3 nodes minimum)
RAM 24 GB per node (3 nodes minimum)
Storage 128 GB per node (3 nodes minimum)
Azure Resource Groups 1
Azure Networks 1
Azure Subnets 1
Azure Security Groups 1
Azure Network Interfaces 3
Azure Route Tables 3
Azure Load Balancers 2
Public IP Addresses 12
OS Disks 3 (128 GB each)

By default, new accounts will not have sufficient quota to make a deployment immediately. If you have started a new account, you will need to request, at a minimum, additional Standard FSv2 Family vCPUs to deploy Mirantis Container Cloud.

To check your resource availability or request quota, click “Subscription” from the home screen of the Azure Management Console and select the Azure subscription you will be using for your deployment.

subscription keys

In the right-hand menu column, select “Usage and quotas.” At the top of the table displayed on the next screen, you will see an option to “Request Increase.”

request increase button

Here, you will need to request an increase to your quota specifically for Standard FSv2 Family vCPUs. The default limit is 10, and we recommend having at least 48 available to deploy Mirantis Container Cloud itself. To run an actual production cluster, you will of course require additional resources to run your nodes.

Ubuntu PC or VM

You will need a computer running Ubuntu 18.04 or higher to configure and run the bootstrap script that will deploy Mirantis Container Cloud to Azure. This may be either a physical box or a virtual machine (VM). Think of this bootstrap machine as the installer for your deployment—it will make initial setup (and later cleanup) easier, but it won’t do any of the work of actually running Container Cloud.

Whether you use a PC or VM, your machine should meet the following minimum requirements:

  • Ubuntu 18.04 or higher
  • 2 vCPUs
  • 4 GB of RAM
  • 5 GB of available storage

Whether you’re on Linux, Mac, or PC, one easy way to quickly create a virtual Ubuntu machine from the command line is using multipass. If you choose this approach, once multipass is installed, you can spin up a VM meeting the requirements above with the following command:

multipass launch -c 2 -d 10G -m 4G

Mirantis Container Cloud Account and License

If you wish to deploy Mirantis Container Cloud with a trial license, you will need to sign up for a Container Cloud account. Once you have an account, you can watch this Get Started Tutorial, or simply follow the steps outlined below.

mcc trial sign in page  

You can then download the mirantis.lic license file to use in deployments to the platform of your choice.

try on-prem hosted trial download page  

If you’re able to download this file on your bootstrap machine, go ahead and do that now. If you’re using an Ubuntu Server VM, you may wish to transfer the mirantic.lic file to the VM using scp, the multipass transfer command, or another tool.

Prepare the bootstrap environment

If your bootstrap machine is a new VM instance, you’ll need to do some basic housekeeping first:

sudo apt-get update

Next, install Docker using apt:

sudo apt install

Your USER will need access to the Docker daemon, so let’s go ahead and give it to them:

sudo usermod -aG docker $USER

At this point, you’ll need to restart the machine so your changes can take effect. Once you’ve restarted, you can test to see whether the Docker daemon is functioning correctly (and can reach Mirantis’ content delivery network) with the following line:

docker run --rm alpine sh -c "apk add --no-cache curl; \ curl"

Download the setup script

Next, download the bootstrap installer on our bootstrap machine:


You’ll need to modify permissions…

chmod 0755

Finally, when you run the installer script, it will unpack the bootstrapper in a new directory called kaas-bootstrap.


Include the license

Remember when we said we would need the mirantis.lic file on our bootstrap machine? The moment is here. All we need to do is place the file in the kaas-bootstrap directory.

Assuming both the license file and kaas-bootstrap are located in our current directory:

mv ./mirantis.lic ./kaas-bootstrap/mirantis.lic

Configure the bootstrapper for Azure

On the bootstrap machine, download the Azure command-line interface (CLI) using the following script maintained by Microsoft:

curl -sL | sudo bash

Once the Azure CLI is installed (you may need to restart), run the following to associate it with your Azure account:

az login

You will receive a device login code and will be prompted to enter it here. Once the CLI is set up, you can list your Azure subscriptions with this command:

az account list -o table

If you only have one subscription, you can skip this next step line. But if you have multiple and you need to choose one:

az account set -s 

Now that you’ve selected your subscription, you’ll need to create a service principal. This is essentially an entity with certain, specified permissions to use resources on your Azure account. (Some users may have an existing service principal that they wish to use—in that case, skip the next command.)

In creating a service principal, you are giving the bootstrapper permission to provision cloud resources on your behalf. That is obviously a great deal of power, so your own account will require owner permissions in order to create the service principal.

When you are ready, the following command will create a service principal with the contributor role:

az ad sp create-for-rbac --role contributor

This will return JSON output that looks something like this:

   "appId": "0c87aM5a-e172-182b-a91a-a9b8d39ddbcd",
   "displayName": "azure-cli-2021-08-04-15-25-16",
   "name": "1359ac72-5794-494d-b787-1d7309b7f8bc",
   "password": "Q1jB2-7Uz6Cka7xos6vL-Ddb4BQx2vgMl",
   "tenant": "6d498697-7anvd-4172-a7v0-4e5b2e25f280"

Your own alphanumeric sequences, of course, will differ. You will need these values in a moment—you may wish to copy them to a text editor.

Now, make sure you are in the kaas-bootstrap directory, and then enter:


This parameter will tell the bootstrapper that you’re deploying to Azure, so that it knows to work from the correct configuration templates. Speaking of those templates, we need to make some configuration changes right now.

At this point, we’ll be making a few modifications to YAML configuration files. In the snippets below, I’m going to use vim, but you can use the graphical or command-line editor of your choice.

From the kaas-bootstrap directory, first open the Azure config template:

vim ./templates/azure/azure-config.yaml.template

In the file, modify the following parameters using the values returned from the Azure CLI above (or using existing service principal credentials):

  • spec:subscriptionID is the subscription ID of your Azure account
  • spec:tenantID is the value of “tenant”
  • spec:clientID is the value of “appId”
  • spec:clientSecret:value is the value of “password”

Using the example values generated above, my Azure config template would look like this:

KaaS-Config command example  

In your cluster template, you may also wish to modify the Azure location to the one where you have the required quota:

vim ./templates/azure/cluster.yaml.template

I’ve used the default of eastus:

server location_azure tutorial  

Optional: if you wish to use your own TLS certificates for Container Cloud’s Keycloak user authentication, change DISABLE_OIDC to true in bootstrap.env. If you’re not sure whether this applies to you, just skip to the next step for the moment.

You’re ready for launch! From the kaas-bootstrap directory, run the bootstrap script:

./ all

If everything is correctly configured, the bootstrap script will set about deploying Mirantis Container Cloud to Azure. This may take several minutes. The bootstrap will log each step, which may include output noting attempts to reach IP addresses and other normal steps in the process—make sure not to interrupt the process prematurely.

When the bootstrap process is successfully completed, the script will output instructions for accessing your new Container Cloud deployment, looking like this:

MCC UI is accessible at [IP address]
To be able to login into UI, create users via 'container-cloud bootstrap user add' command
Keycloak service is accessible at [IP address]
To set up services with your certificates use 'container-cloud set certificate' command

It’s also important to note that the bootstrap has created, in the kaas-bootstrap directory, both an SSH key and kubeconfig file. Make sure to save these.

Congratulations, your deployment is live! Now let’s create a user and login through the web UI.

Create a user

Still working from the bootstrap machine, you can create initial user accounts for Container Cloud:

./container-cloud bootstrap user add --username  --roles  --kubeconfig 

In my deployment, for example, I’ve created a user with my first name and the “writer” role, which refers to my read/write permissions.

./container-cloud bootstrap user add --username eric --roles writer --kubeconfig ./kubeconfig

I’ll be prompted to create a password in the command line. Now, with my initial user account created, I can log into Container Cloud from the “MCC UI” IP address provided by the bootstrap script.

Upon login, you’ll get a quick tour of the interface:

cluster view from the mcc ui  

This is as far as a trial license will take us. However, if you have a full license or simply want to see how to create a new cluster, import it to Lens, and install a Helm chart, read on. Or if you’re ready to remove your Container Cloud deployment from Azure, skip to the “Clean up” section at the end.

Create a cluster (full license only)

Click Create Cluster to add a new Kubernetes cluster to Container Cloud.

mcc create cluster window with Azure selected as provider

We’ll call this cluster “demo.” For this tutorial, we’ll leave everything else alone, but note that we can add SSH keys here and configure settings for storage and Stacklight.

Once we hit Create, the system will start preparing our cluster, and this will take a few minutes. But there’s one important thing to note here: the system isn’t going to deploy the cluster unless we have three manager nodes and two worker nodes. So let’s take care of that. We’ll add those machines by clicking on the name of our cluster — in this case, “demo” — and then the Create Machine button.

mcc create machine window with worker type selected

Here, we can add multiple nodes at once, specifying whether they are managers or workers, and then select our OS and machine type.

Download the kubeconfig

Our machines will take a few minutes to spin up. Once they’re ready and the cluster has completed most of its setup, we’ll have the option under the cluster’s vertical ellipsis menu icon to download our cluster’s kubeconfig.

dropdown menu containing download kubeconfig action from mcc UI  

Now we can use the kubeconfig however we like — today, let’s import it into Lens and see how we can manage the cluster from there.

Import to Lens

You may already be using Lens — if you’re not familiar with it, this is the free and open source Kubernetes IDE project supported by Mirantis, which you can download at I already have it installed, so I’m going to open it, click the plus icon in the lower right-hand corner, and sync the kubeconfig I just saved.

empty cluster view from Lens dash

When I click on our cluster now, I get a number of options. I can share the cluster, connect to it, delete it. Go ahead and connect.

connecting to a cluster within the Lens UI

Now you have a live dashboard for the cluster as a whole, with a single-pane view of error messages, resource usage…all the big picture items you want to understand at a glance. You can take a look at your nodes for more detail, and drill down as needed.

Install a chart

Now you have a cluster and you can manage it in Lens — let’s start to put it to work by installing a Helm chart. Your available repositories will depend on what you’ve used on your local machine — if this is a fresh Lens install on a machine that you haven’t used for a lot of Kubernetes development, you may need to add some repos. To do that, you’ll go to the menu bar, click on “Lens,” and then “Preferences.” In the Preferences menu, select “Kubernetes” and then scroll down to Helm charts and select the repositories you would like to add. For this demo, we’ll use the bitnami repository — if you don’t already have it, go ahead and add that.

selecting custom helm charts within Lens UI

Now exit the Preferences menu and return to your cluster. Click on the “Apps” tab in the sidebar, and then select “Charts.” Here, you can search your available repositories for any Helm charts you’d like to use. Let’s search for “wordpress.” In just a few clicks, you can install this chart and bootstrap a WordPress deployment in your cluster.

installing wordpress helm chart within Lens UI

Now that the chart is installed, let’s take a look at our pods. Since this is an enterprise-grade cluster, you will have quite a few already — search for WordPress. You can click on the pod, scroll down through the information, and click on the Port.

pod view of wordpress cluster in Lens UI

And when you bring it up in the browser…

wordpress cluster shown in web browser returning "Hello World"

Success! Your app is up.

Clean up

Once you’re all done experimenting with your Container Cloud deployment, you can run the cleanup script from your bootstrap machine to delete all Container Cloud resources on Azure. (Think of this as the uninstaller.) To do this, run the following command from the kaas-bootstrap directory:

./ cleanup

As with the deployment script, the process will take a few minutes to complete.


For in-depth instructions on Container Cloud deployment and usage, see the official docs. If you’d like more information on how Mirantis can help you use Container Cloud to manage hybrid architectures and support a cloud native datacenter, explore our Mirantis Flow managed solution.

From Virtualization to Containerization
Learn how to move from monolithic to microservices in this free eBook
Download Now
Radio Cloud Native – Week of May 11th, 2022

Every Wednesday, Nick Chase and Eric Gregory from Mirantis go over the week’s cloud native and industry news. This week they discussed: Docker Extensions Artificial Intelligence shows signs that it's reaching the common person Google Cloud TPU VMs reach general availability Google buys MobileX, folds into Google Cloud NIST changes Palantir is back, and it's got a Blanket Purchase Agreement at the Department of Health and Human …

Radio Cloud Native – Week of May 11th, 2022
Where do Ubuntu 20.04, OpenSearch, Tungsten Fabric, and more all come together? In the latest Mirantis Container Cloud releases!

In the last several weeks we have released two updates to Mirantis Container Cloud - versions 2.16 and 2.17, which bring a number of important changes and enhancements. These are focused on both keeping key components up to date to provide the latest functionality and security fixes, and also delivering new functionalities for our customers to take advantage of in …

Where do Ubuntu 20.04, OpenSearch, Tungsten Fabric, and more all come together? In the latest Mirantis Container Cloud releases!
Monitoring Kubernetes costs using Kubecost and Mirantis Kubernetes Engine [Transcript]

Cloud environments & Kubernetes are becoming more and more expensive to operate and manage. In this demo-rich workshop, Mirantis and Kubecost demonstrate how to deploy Kubecost as a Helm chart on top of Mirantis Kubernetes Engine. Lens users will be able to visualize their Kubernetes spend directly in the Lens desktop application, allowing users to view spend and costs efficiently …

Monitoring Kubernetes costs using Kubecost and Mirantis Kubernetes Engine [Transcript]
Service Mesh for Mere Mortals
A Guide to Istio and How to Use Service Mesh Platforms
Technical training
Learn Kubernetes & OpenStack from Deployment Experts
Prep for certification!
View schedule
Mirantis Webstore
Purchase Kubernetes support