)
)
)
)
)
)
)
)
)
)
)
)
)
)
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
Prerequisites
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 4GMirantis 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 updateNext, install Docker using apt:
sudo apt install docker.ioYour USER will need access to the Docker daemon, so let’s go ahead and give it to them:
sudo usermod -aG docker $USERAt 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 https://binary.mirantis.com"Download the setup script
Next, download the bootstrap installer on our bootstrap machine:
wget https://binary.mirantis.com/releases/get_container_cloud.shYou'll need to modify permissions...
chmod 0755 get_container_cloud.shFinally, when you run the installer script, it will unpack the bootstrapper in a new directory called kaas-bootstrap.
./get_container_cloud.shInclude 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.licConfigure the bootstrapper for Azure
On the bootstrap machine, download the Azure command-line interface (CLI) using the following script maintained by Microsoft:
curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bashOnce the Azure CLI is installed (you may need to restart), run the following to associate it with your Azure account:
az loginYou 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 tableIf 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 contributorThis 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:
export KAAS_AZURE_ENABLED=trueThis 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.templateIn the file, modify the following parameters using the values returned from the Azure CLI above (or using existing service principal credentials):
spec:subscriptionIDis the subscription ID of your Azure accountspec:tenantIDis the value of "tenant"spec:clientIDis the value of "appId"spec:clientSecret:valueis 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.templateI’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:
./bootstrap.sh allIf 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' commandIt’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 ./kubeconfigI’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 k8slens.dev. 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:
./bootstrap.sh cleanupAs with the deployment script, the process will take a few minutes to complete.
Conclusion
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.
