Skip to content
This repository has been archived by the owner on Jul 6, 2022. It is now read-only.

Latest commit

 

History

History
357 lines (262 loc) · 12.9 KB

quickstart-minikube.md

File metadata and controls

357 lines (262 loc) · 12.9 KB
Raw

Quickstart: Open Service Broker for Azure on a Minikube cluster

This quickstart walks through using the Open Service Broker for Azure (OSBA) to deploy WordPress on a local Minikube cluster.

WordPress requires a back-end MySQL database. Without OSBA, we would create a database in the Azure portal, and then manually configure the connection information. Now with OSBA our Kubernetes manifests can provision an Azure MySQL database on our behalf, save the connection information in Kubernetes secrets, and then bind them to our WordPress instance.

Prerequisites

Install Minikube

Minikube is a tool that makes it easy to run Kubernetes locally. Minikube runs a single-node Kubernetes cluster inside a VM on your computer.

Some older versions of Minikube, as well as some newer ones, suffer from bugs that can be worked around, but only with moderate effort. We therefore recommend that if you are using Minikube that you use v0.25.2.

MacOS

curl -Lo minikube https://storage.googleapis.com/minikube/releases/v0.25.2/minikube-darwin-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/

Windows

  1. Download the minikube-windows-amd64.exe file.
  2. Rename it to minikube.exe.
  3. Add it to a directory on your PATH.

Linux

curl -Lo minikube https://storage.googleapis.com/minikube/releases/v0.25.2/minikube-linux-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/

Install the Azure CLI

Install az by following the instructions for your operating system. See the full installation instructions if yours isn't listed below.

MacOS

brew install azure-cli

Windows

Download and run the Azure CLI Installer (MSI).

Ubuntu 64-bit

  1. Add the azure-cli repo to your sources: 
    echo "deb [arch=amd64] https://packages.microsoft.com/repos/azure-cli/ wheezy main" | \
     sudo tee /etc/apt/sources.list.d/azure-cli.list
  2. Run the following commands to install the Azure CLI and its dependencies: 
    sudo apt-key adv --keyserver packages.microsoft.com --recv-keys 52E16F86FEE04B979B07E28DB02C46DF417A0893
sudo apt-get install apt-transport-https
sudo apt-get update && sudo apt-get install azure-cli

Install the Kubernetes CLI

Install kubectl by running the following command:

az aks install-cli

Install the Helm CLI

Helm is a tool for installing pre-configured applications on Kubernetes. Install helm by running the following command:

MacOS

brew install kubernetes-helm

Windows

  1. Download the latest Helm release.
  2. Decompress the tar file.
  3. Copy helm.exe to a directory on your PATH.

Linux

curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get | bash

Cluster Setup

Now that we have all the tools, we need a Kubernetes cluster with Open Service Broker for Azure configured.

Configure your Azure account

First let's identify your Azure subscription and save it for use later on in the quickstart.

  1. Run az login and follow the instructions in the command output to authorize az to use your account

  2. List your Azure subscriptions:

    az account list -o table

  3. Copy your subscription ID and save it in an environment variable:

    Bash

    export AZURE_SUBSCRIPTION_ID="<SubscriptionId>"

    PowerShell

    $env:AZURE_SUBSCRIPTION_ID = "<SubscriptionId>"

Create a Resource Group

Create a resource group to contain the resources you'll be creating with the quickstart.

az group create --name osba-quickstart --location eastus

Create a service principal

This creates an identity for Open Service Broker for Azure to use when provisioning resources on your account on behalf of Kubernetes.

  1. Create a service principal with RBAC enabled for the quickstart:

    az ad sp create-for-rbac --name osba-quickstart -o table

  2. Save the values from the command output in environment variables:

    Bash

    export AZURE_TENANT_ID=<Tenant>
export AZURE_CLIENT_ID=<AppId>
export AZURE_CLIENT_SECRET=<Password>

    PowerShell

    $env:AZURE_TENANT_ID = "<Tenant>"
$env:AZURE_CLIENT_ID = "<AppId>"
$env:AZURE_CLIENT_SECRET = "<Password>"

Create a Kubernetes cluster using Minikube

Next we will create a local cluster using Minikube. You can also try OSBA on the Azure Container Service (AKS).

  1. Create a Minikube Cluster:

    minikube start --bootstrapper=kubeadm

    Note: Service Catalog may not work with Kubernetes versions less than 1.9.0. If you are using a version of Minikube older than 0.25, you will need to upgrade to at least 0.25 to ensure the cluster is compatible with Service Catalog and OSBA.

Configure the cluster with Open Service Broker for Azure

  1. Before we can use Helm to install applications such as Service Catalog and WordPress on the cluster, we first need to prepare the cluster to work with Helm:

    kubectl create -f https://raw.githubusercontent.com/Azure/helm-charts/master/docs/prerequisities/helm-rbac-config.yaml
helm init --service-account tiller

  2. Deploy Service Catalog on the cluster:

    helm repo add svc-cat https://svc-catalog-charts.storage.googleapis.com
helm install svc-cat/catalog --name catalog --namespace catalog \
   --set apiserver.storage.etcd.persistence.enabled=true

    Note: the command above enables persistence for the embedded etcd used by Service Catalog. Using this flag will create a persistent volume for the etcd instance to use. Enabling the persistent volume is recommended for evaluation of Service Catalog because it allows you to restart Service Catalog without data loss. For production use, we recommend a dedicated etcd cluster with appropriate persistent storage and backup.

  3. Check the status of Service Catalog: Run the following command and checking that every pod is in the Running state. You may need to wait a few minutes, rerunning the command until all of the resources are ready.

    $ kubectl get pods --namespace catalog
NAME                                                     READY     STATUS    RESTARTS   AGE
po/catalog-catalog-apiserver-5999465555-9hgwm            2/2       Running   4          9d
po/catalog-catalog-controller-manager-554c758786-f8qvc   1/1       Running   11         9d

  4. Deploy Open Service Broker for Azure on the cluster:

    Bash

    helm repo add azure https://kubernetescharts.blob.core.windows.net/azure
helm install azure/open-service-broker-azure --name osba --namespace osba \
  --set azure.subscriptionId=$AZURE_SUBSCRIPTION_ID \
  --set azure.tenantId=$AZURE_TENANT_ID \
  --set azure.clientId=$AZURE_CLIENT_ID \
  --set azure.clientSecret=$AZURE_CLIENT_SECRET

    PowerShell

    helm repo add azure https://kubernetescharts.blob.core.windows.net/azure
helm install azure/open-service-broker-azure --name osba --namespace osba `
  --set azure.subscriptionId=$env:AZURE_SUBSCRIPTION_ID `
  --set azure.tenantId=$env:AZURE_TENANT_ID `
  --set azure.clientId=$env:AZURE_CLIENT_ID `
  --set azure.clientSecret=$env:AZURE_CLIENT_SECRET

    Note: to install OSBA with experimental modules enabled, use the --set modules.minStability=experimental argument.

  5. Check on the status of Open Service Broker for Azure by running the following command and checking that every pod is in the Running state. You may need to wait a few minutes, rerunning the command until all of the resources are ready.

    $ kubectl get pods --namespace osba
NAME                                           READY     STATUS    RESTARTS   AGE
po/osba-azure-service-broker-8495bff484-7ggj6   1/1       Running   0          9d
po/osba-redis-5b44fc9779-hgnck                  1/1       Running   0          9d

Deploy WordPress

Now that we have a cluster with Open Service Broker for Azure, we can deploy WordPress to Kubernetes and OSBA will handle provisioning an Azure MySQL database and binding it to our WordPress installation.

helm install azure/wordpress --name osba-quickstart --namespace osba-quickstart

Use the following command to tell when WordPress is ready:

$ kubectl get deploy osba-quickstart-wordpress -n osba-quickstart -w

NAME                        DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
osba-quickstart-wordpress   1         1         1            0           1m
...
osba-quickstart-wordpress   1         1         1            1           2m

Login to WordPress

  1. Run the following command to open WordPress in your browser:

    open http://$(minikube ip):$(kubectl get service osba-quickstart-wordpress -n osba-quickstart -o jsonpath={.spec.ports[?\(@.name==\"http\"\)].nodePort})/admin

    Note: We are using the minikube ip to get the WordPress URL, instead of the command from the WordPress deployment output because with Minikube the WordPress service won't have a public IP address assigned.

  2. To retrieve the password, run this command:

    kubectl get secret osba-quickstart-wordpress -n osba-quickstart -o jsonpath="{.data.wordpress-password}" | base64 --decode

  3. Login using the username user and the password you just retrieved.

Uninstall WordPress

Using Helm to uninstall the osba-quickstart release will delete all resources associated with the release, including the Azure MySQL database.

helm delete osba-quickstart --purge

Since deprovisioning occurs asynchronously, the corresponding serviceinstance resource will not be fully deleted until that process is complete. When the following command returns no resources, deprovisioning is complete:

$ kubectl get serviceinstances -n osba-quickstart
No resources found.

Optional: Further Cleanup

At this point, the Azure MySQL database should have been fully deprovisioned. In the unlikely event that anything has gone wrong, to ensure that you are not billed for idle resources, you can delete the Azure resource group that contained the database. In the case of the WordPress chart, Azure MySQL was provisioned in a resource group whose name matches the Kubernetes namespace into which WordPress was deployed.

az group delete --name osba-quickstart --yes --no-wait

To remove the service principal:

az ad sp delete --id http://osba-quickstart

To tear down minikube:

minikube delete

Next Steps

Minikube may seem like an odd choice for an Azure quickstart, but it demonstrates that Open Service Broker for Azure isn't limited to clusters running on Azure! Our local Kubernetes cluster communicated with Azure via OSBA, provisioned an Azure MySQL database, and bound our local WordPress installation to that new database.

With OSBA any cluster can rely on Azure to provide all those pesky "as a service" goodies that make life easier.

Now that you have a cluster with OSBA, adding more applications is quick. Try out another to see for yourself:

All of our OSBA-enabled helm charts are available in the Azure/helm-charts repository.

Contributing

Do you have an application in mind that you'd like to use with OSBA? We'd love to have it! Learn how to contribute a new chart to our helm repository.