NEW! Mirantis Academy -   Learn confidently with expert guidance and On-demand content.   Learn More


Get Started with Mirantis Container Cloud on Microsoft Azure


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 ResourceQuota RequirementStandard FSv2 Family vCPUs8 per node (3 nodes minimum)RAM24 GB per node (3 nodes minimum)Storage128 GB per node (3 nodes minimum)Azure Resource Groups1Azure Networks1Azure Subnets1Azure Security Groups1Azure Network Interfaces3Azure Route Tables3Azure Load Balancers2Public IP Addresses12OS Disks3 (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.

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.”

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.


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


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 <subscriptionID>

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:


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:


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 <userName> --roles <roleName> --kubeconfig <path/to/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:


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.

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.

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.


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.

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.

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.

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.

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.

And when you bring it up in the browser…

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.

Choose your cloud native journey.

Whatever your role, we’re here to help with open source tools and world-class support.


Subscribe to our bi-weekly newsletter for exclusive interviews, expert commentary, and thought leadership on topics shaping the cloud native world.