How to deploy on Azure

Azure is the cloud computing platform developed by Microsoft. It has management, access and development of applications and services to individuals, companies, and governments through its global infrastructure. Access the Azure web console at portal.azure.com.

Choose the target substrate. The VM procedure deploys machines through Juju’s Azure cloud; the K8s procedure creates an Azure Kubernetes Service (AKS) cluster.

Install client environment

Warning

Current limitations:

  • Only supported starting Juju 3.6

  • Juju CLI should be on Azure VM for it to be able to reach cloud metadata endpoint.

  • Managed Identity and the Juju resources should be on the same Azure subscription

  • The current setup has been tested on Ubuntu 22.04 and higher

Juju

Install Juju via snap:

sudo snap install juju

Check that the Juju version is correctly installed:

juju version
Output example 
3.6-rc1-genericlinux-amd64

Azure CLI

Install the Azure CLI on Linux distributions by following the Azure CLI installation guide.

Verify that it is correctly installed:

az --version
Output example 
azure-cli                         2.65.0

core                              2.65.0
telemetry                          1.1.0

Dependencies:
msal                              1.31.0
azure-mgmt-resource               23.1.1

Python location '/opt/az/bin/python3'
Extensions directory '/home/deusebio/.azure/cliextensions'

Python (Linux) 3.11.8 (main, Sep 25 2024, 11:33:44) [GCC 11.4.0]

Legal docs and information: aka.ms/AzureCliLegal

Your CLI is up-to-date.

Authenticate

Note

For more information on how to authenticate, refer to the Juju documentation.

First of all, retrieve your subscription id:

az login

After authenticating via the web browser, you will be shown a list of information and a table with the subscriptions connected to your user, e.g.:

No     Subscription name                     Subscription ID                       Tenant
-----  ------------------------------------  ------------------------------------  -------------
[1] *  <subscription_name>                   <subscription_id>                     canonical.com
[2]    <other_subscription_name>             <other_subscription_id>               canonical.com

In the prompt, select the subscription id you would like to connect the controller to, and store the id as it will be needed in the next step when bootstrapping the controller.

Bootstrap Juju controller on Azure

First, you need to add a set of credentials to your Juju client:

juju add-credentials azure

This will start a script that will help you set up the credentials, where you will be asked:

  • credential-name — a sensible name that will help you identify the credential set, say <CREDENTIAL_NAME>

  • region — a default region that is most convenient to deploy your controller and applications. Note that credentials are not region-specific

  • auth type — authentication type. Select interactive, which is the recommended way to authenticate to Azure using Juju

  • subscription_id — the value <subscription_id> taken in the previous step

  • application_name — any unique string to avoid collision with other users or applications

  • role-definition-name — any unique string to avoid collision with other users or applications, and store it as <AZURE_ROLE>

Next, you will be asked to authenticate the requests via your web browser with the following message:

To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code <YOUR_CODE> to authenticate.

In the browser, open the authentication page and enter the code <YOUR_CODE> provided in the output.

You will be asked to authenticate twice, for allowing the creation of two different resources in Azure.

You will see a message that the credentials have been added locally:

Credential <CREDENTIAL_NAME> added locally for cloud "azure".

Once the credentials are correctly added, we can bootstrap a controller:

juju bootstrap azure <CONTROLLER_NAME>

Deploy charms

Create a new Juju model, if needed:

juju add-model <MODEL_NAME>

(Optional) If you are troubleshooting charms and wish to see DEBUG logs:

juju model-config logging-config='<root>=INFO;unit=DEBUG'

Deploy Charmed Apache Kafka:

juju deploy kafka -n 3 --channel 4/stable --config roles=broker,controller

To use a specific instance type, add --constraints "instance-type=<INSTANCE_TYPE>".

Caution

This co-located broker/controller topology is for evaluation. For a production deployment, use separate broker and controller applications as described in the general deployment guide.

Caution

Note that the smallest instance types on Azure may not have enough resources for hosting an Apache Kafka broker. We recommend selecting an instance type that provides at the very least 8 GB of RAM and 4 cores, e.g. Standard_A4_v2. For more guidance on production environment sizing, see the Requirements page. You can find more information about the available instance types in the Azure documentation.

We also recommend to deploy a Data Integrator for creating an admin user to manage the content of the Kafka cluster:

juju deploy data-integrator \
  --config extra-user-roles=admin \
  --config topic-name=__admin-user

And integrate it with the Kafka application:

juju integrate kafka data-integrator

For more information on Data Integrator and how to use it, please refer to the how-to manage applications guide.

Clean up

Caution

Always clean Azure resources that are no longer necessary! Abandoned resources are tricky to detect and they can become expensive over time.

To list all controllers that have been registered to your local client, use the juju controllers command.

To destroy the Juju controller and remove the Azure instance (Warning: all your data will be permanently removed):

juju destroy-controller <CONTROLLER_NAME> --destroy-all-models --destroy-storage --force

Should the destroying process take a long time or be seemingly stuck, proceed to delete VM resources also manually via the Azure portal. See Azure documentation for more information on how to remove active resources no longer needed.

Next, check and manually delete all unnecessary Azure VM instances, to show the list of all your Azure VMs run the following command (make sure to use the correct region):

az resource list

List your Juju credentials with the juju credentials command.

Output example 
Client Credentials:
Cloud        Credentials
azure        NAME_OF_YOUR_CREDENTIAL

Remove Azure CLI credentials from Juju:

juju remove-credential azure NAME_OF_YOUR_CREDENTIAL

After deleting the credentials, the interactive process may still leave the role resource and its assignment hanging around. We recommend checking if these are still present by running:

az role definition list --name <AZURE_ROLE>

To get the full list, use it without specifying the --name argument.

You can check whether you still have a role assignment bound to <AZURE_ROLE> registered by using:

az role assignment list --role <AZURE_ROLE>

If there is an unwanted role left, you can remove the role assignment first and then the role itself with the following commands:

az role assignment delete --role <AZURE_ROLE>
az role definition delete --name <AZURE_ROLE>

Finally, log out from Azure CLI:

az logout

Install tooling and authenticate

Install Juju 3.6 LTS and follow the Azure CLI installation guide:

sudo snap install juju --channel 3.6/stable
sudo snap install kubectl --classic
az login

Create an AKS cluster

az group create --name <RESOURCE_GROUP> --location <LOCATION>
az aks create \
  --resource-group <RESOURCE_GROUP> \
  --name <K8S_CLUSTER_NAME> \
  --enable-managed-identity \
  --node-count 3 \
  --node-vm-size <INSTANCE_TYPE> \
  --generate-ssh-keys

This example is suitable only for evaluation. For production, size and spread the worker nodes according to the requirements.

Download the cluster credentials and verify access:

az aks get-credentials --resource-group <RESOURCE_GROUP> --name <K8S_CLUSTER_NAME> --context aks
kubectl get pods --all-namespaces

Bootstrap Juju and deploy

juju bootstrap aks <CONTROLLER_NAME>
juju add-model <MODEL_NAME>
juju deploy kafka-k8s -n 3 --channel 4/stable --trust --config roles=broker,controller kafka
juju deploy data-integrator admin --channel stable \
  --config extra-user-roles=admin \
  --config topic-name=admin-topic
juju integrate kafka admin

This co-located broker/controller topology is for testing. For a production deployment, use separate broker and controller applications as described in the general deployment guide.

Inspect the environment with kubectl cluster-info, az aks list, and kubectl get nodes.

Clean up

Caution

Always remove AKS resources that are no longer needed; they can be costly.

juju destroy-controller <CONTROLLER_NAME> --destroy-all-models --destroy-storage --force

Before deleting the cluster, check for Services with external IPs that Juju may not remove automatically — they continue to incur Azure charges while the cluster exists:

kubectl get svc --all-namespaces | grep -v "ClusterIP"

Delete any remaining Services with an EXTERNAL-IP (for example, the Kafka NodePort/LoadBalancer Services created by the charm) before deleting the cluster:

kubectl delete svc <service-name> -n <MODEL_NAME>

Then delete the AKS cluster itself and remove the local kubectl context that az aks get-credentials created:

az aks delete --resource-group <RESOURCE_GROUP> --name <K8S_CLUSTER_NAME>
kubectl config delete-context aks
az logout

Check for other cloud resources that were not removed automatically.