|latest/stable||44||21 Aug 2023|
|latest/candidate||40||07 Jun 2023|
|latest/beta||44||17 Aug 2023|
|latest/edge||45||09 Aug 2023|
|1.29/edge||45||21 Aug 2023|
|1.28/stable||44||22 Aug 2023|
|1.28/candidate||40||07 Jun 2023|
|1.28/beta||44||07 Aug 2023|
|1.28/edge||45||09 Aug 2023|
|1.27/stable||40||12 Jun 2023|
|1.27/candidate||40||12 Jun 2023|
|1.27/beta||37||09 Apr 2023|
|1.27/edge||35||07 Apr 2023|
|1.26/stable||34||27 Feb 2023|
|1.26/candidate||34||25 Feb 2023|
|1.26/beta||29||09 Apr 2023|
|1.26/edge||29||23 Nov 2022|
|1.25/stable||27||30 Sep 2022|
|1.25/candidate||27||28 Sep 2022|
|1.25/beta||30||01 Dec 2022|
|1.25/edge||22||09 Sep 2022|
|1.24/stable||16||04 Aug 2022|
|1.24/candidate||16||01 Aug 2022|
|1.24/beta||8||21 Apr 2022|
|1.24/edge||15||22 Jul 2022|
|1.23/beta||4||22 Mar 2022|
|1.23/edge||2||24 Feb 2022|
juju deploy azure-integrator
This charm acts as a proxy to Azure and provides an interface to apply a certain set of changes via roles, profiles, and tags to the instances of the applications that are related to this charm.
When on Azure, this charm can be deployed, granted trust via Juju to access Azure, and then related to an application that supports the interface. The set of permissions that the related application could request is documented in the interface’s Requires API documentation.
For example, Charmed Kubernetes has support for this, and can be deployed with the following bundle overlay (download it here):
description: Charmed Kubernetes overlay to add native Azure support. applications: aws-integrator: annotations: gui-x: "600" gui-y: "300" charm: cs:~containers/azure-integrator num_units: 1 trust: true relations: - ['azure-integrator', 'kubernetes-control-plane'] - ['azure-integrator', 'kubernetes-worker']
To use this overlay with the Charmed Kubernetes bundle, it is specified during deploy like this:
juju deploy charmed-kubernetes --overlay azure-overlay.yaml --trust
To deploy with earlier versions of Juju, or if you wish to provide it different
credentials, you will need to provide the cloud credentials via the
charm config options.
Note: The credentials used must have rights to use the API to inspect the instances connecting to it, enable a Managed Service Identity (MSI) for those instances, assign roles to those instances, and create custom roles. This may be different from the access permissions that Juju itself requires.
Resource Usage Note
By relating to this charm, other charms can directly allocate resources, such as managed disks and load balancers, which could lead to cloud charges and count against quotas. Because these resources are not managed by Juju, they will not be automatically deleted when the models or applications are destroyed, nor will they show up in Juju’s status or GUI. It is therefore up to the operator to manually delete these resources when they are no longer needed, using the Azure management website or API.
Following are some examples using Azure integration with Charmed Kubernetes.
Creating a pod with a Disk Storage-backed volume
This script creates a busybox pod with a persistent volume claim backed by Azure’s Disk Storage.
#!/bin/bash # create a storage class using the `kubernetes.io/azure-disk` provisioner kubectl create -f - <<EOY apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: azure-standard provisioner: kubernetes.io/azure-disk parameters: storageaccounttype: Standard_LRS kind: managed EOY # create a persistent volume claim using that storage class kubectl create -f - <<EOY kind: PersistentVolumeClaim apiVersion: v1 metadata: name: testclaim spec: accessModes: - ReadWriteOnce resources: requests: storage: 100Mi storageClassName: azure-standard EOY # create the busybox pod with a volume using that PVC: kubectl create -f - <<EOY apiVersion: v1 kind: Pod metadata: name: busybox namespace: default spec: containers: - image: busybox command: - sleep - "3600" imagePullPolicy: IfNotPresent name: busybox volumeMounts: - mountPath: "/pv" name: testvolume restartPolicy: Always volumes: - name: testvolume persistentVolumeClaim: claimName: testclaim EOY
Creating a service with an Azure load-balancer
The following script starts the hello-world pod behind an Azure-backed load-balancer.
kubectl create deployment hello-world --image=gcr.io/google-samples/node-hello:1.0 kubectl scale deployment hello-world --replicas=5 kubectl expose deployment hello-world --type=LoadBalancer --name=hello --port=8080 watch kubectl get svc hello -o wide
Providing load-balancers to other charms
Any charm which supports the
loadbalancer interface can request an Azure-backed load-balancer. For example, you can use an Azure LB to run Vault in HA mode with this:
applications: vault: charm: cs:vault num_units: 3 azure-integrator: charm: cs:azure-integrator num_units: 1 trust: true relations: - ["vault:lb-provider", "azure-integrator"]