Moving your data services to Hosted Data Solutions

https://github.com/Azure/blackbelt-aks-hackfest/blob/master/linux-container-workshop/hol-content/10-cluster-upgrading.md

This step says to use az aks get-versions which doesn't work..

$ az aks get-versions
az aks get-versions: error: the following arguments are required: --location/-l
usage: az aks get-versions [-h] [--verbose] [--debug]
                           [--output {json,jsonc,table,tsv}]
                           [--query JMESPATH] --location LOCATION

I suspect it wants us to use az aks get-upgrades except it never explains how to set $AKS_CLUSTER_NAME or $RESOURCE_GROUP_NAME

Reusing the vars from the earlier steps.. I guessed at..

NAME=$(az group list | jq '.[0]."name"' -r)
CLUSTER_NAME="${NAME//_}"
AKS_CLUSTER_NAME=$CLUSTER_NAME
RESOURCE_GROUP_NAME=$NAME

Either the page needs to use the old vars and explain how to set them, or it should show how to set the new vars used on that page.

Page also needs more beer. Amount consumed while writing this page was insufficient leading to inconsistencies.

I am facing an error while applying the yaml file with the Service Instance for the OSBA lab.

Even after installing osba with --set modules.minStability=EXPERIMENTAL and having the class name as azure-cosmosdb-mongo-account, getting the following error:

=====================
kubectl apply -f heroes-cosmosdb.yaml

Error from server (Forbidden): error when creating "heroes-cosmosdb.yaml": serviceinstances.servicecatalog.k8s.io "heroes-cosmosdb-instance" is forbidden: ClusterServiceClass {ClusterServiceClassExternalName:"azure-cosmosdb-mongo-account"} does not exist, cannot figure out the default ClusterServicePlan.

And azure-cosmos-mongo-account is not listed in the 'svcat get classes' and the 'svcat get plans' output too. AKS cluster is v1.9.6.

In the HOL 2 section "Tag images with ACR server and repository", the first line of code is:

# Be sure to replace the login server value

Since the $ACR_SERVER variable is set in the prior step, this comment is not necessary, right?

I'll submit a PR to remove the comment, upon confirmation.

Dockerizing Applications

The file was moved to "helper_files" Can we just have the user switch to that directory and run the helm command from there?

In the Ingress Controllers lab, following Helm command:

helm install --name ingress stable/nginx-ingress --namespace kube-system

fails with error
Error: release ingress failed: clusterroles.rbac.authorization.k8s.io "ingress-nginx-ingress" is forbidden:.......

After doing a bit of research found that this is a known issue: rbitia/aci-demos#74

Workaround which seems to work is to set the RABC properties:

helm install stable/nginx-ingress --name ingress --namespace kube-system --set rbac.create=false --set

I would recommend adding a note regarding this in the lab, as it will be helpful in case someone faces the same issue.

For users using their own jumpbox, on the HOL #2 step:

docker login --username $ACR_USER --password $ACR_PWD $ACR_SERVER

... they may receive the following message:

WARNING! Using --password via the CLI is insecure. Use --password-stdin.

The solution is to use vi to write the password to a txt file (e.g. ~/acr-pw.txt) and then use this alternative login command:

 cat ~/acr-pw.txt | docker login $ACR_SERVER -u $ACR_USER --password-stdin

Is this deserving of a PR? Perhaps it's a bit out of scope.

Deploy the Superhero Ratings App to AKS

Working with Azure Kubernetes Service Cluster Scaling

In lab 03-create-aks-cluster.md, the given Kubernetes version is not available. we may have to use 1.11.4

I'm looking at the aks versions available and see that 1.11.2 is not available, not in the major us regions at least... eastus, westus, centralus

Possibly, we want to use the latest one. I will use 1.12.5 and let you know if the rest of the lab goes okay.

bash-4.4# az aks get-versions --location eastus --output table
KubernetesVersion Upgrades

1.12.5 None available
1.12.4 1.12.5
1.11.7 1.12.4, 1.12.5
1.11.6 1.11.7, 1.12.4, 1.12.5
1.10.12 1.11.6, 1.11.7
1.10.9 1.10.12, 1.11.6, 1.11.7
1.9.11 1.10.9, 1.10.12
1.9.10 1.9.11, 1.10.9, 1.10.12
bash-4.4# az aks get-versions --location westus --output table
KubernetesVersion Upgrades

1.12.5 None available
1.12.4 1.12.5
1.11.7 1.12.4, 1.12.5
1.11.6 1.11.7, 1.12.4, 1.12.5
1.10.12 1.11.6, 1.11.7
1.10.9 1.10.12, 1.11.6, 1.11.7
1.9.11 1.10.9, 1.10.12
1.9.10 1.9.11, 1.10.9, 1.10.12
bash-4.4# az aks get-versions --location centralus --output table
KubernetesVersion Upgrades

1.12.5 None available
1.12.4 1.12.5
1.11.7 1.12.4, 1.12.5
1.11.6 1.11.7, 1.12.4, 1.12.5
1.10.12 1.11.6, 1.11.7
1.10.9 1.10.12, 1.11.6, 1.11.7
1.9.11 1.10.9, 1.10.12
1.9.10 1.9.11, 1.10.9, 1.10.12

the 3rd hackfest lab has a hardwired location (-l eastus), perhaps make a LOCATION=xxx similar to the approach used for resource group and cluster name?

Step one of adding Dockerfile is already done for the user, but there's instructions to do it.

The lab instructions should state at the top, "Service Catalog currently works with Kubernetes version 1.9.0 and higher, so you will need a Kubernetes cluster that is version 1.9.0 or higher."

In labs/day1-labs/05-kubernetes-ui.md the suggested way to view the Kubernetes dashboard is to get the cluster credentials (for kubectl) then run kubectl proxy and finally browse to a long URL.

You can just use az aks browse -n $CLUSTER_NAME -g $NAME to achieve the same thing in one command. Any particular reason to not change the instructions to say this?

When creating the image of the ratings-db, it uses the following commands:

az acr build --registry $ACR_NAME --image azureworkshop/rating-api:v1 .

Shouldn't it be:

az acr build --registry $ACR_NAME --image azureworkshop/rating-db:v1 .

Now that AKS has B-series VM support, should we change HOL 3 to use a B-series VM?

Otherwise the more expensive Standard_DS1_v2 default is used.

I imagine Standard_B1ms would be fine, but perhaps Standard_B1s would suffice (see B-series VM options). I have not tested.

The new command line would be along the lines of...

az aks create -n $CLUSTER_NAME -g $NAME -c 2 -k 1.7.7 --node-vm-size=Standard_B1ms --generate-ssh-keys -l eastus

Thoughts?

Works in Safari, Chrome for Mac, Chrome for PC, Edge, but not IE version 11.192.16299.0 on Windows 10

In labs/day1-labs/02-dockerize-apps.md a user-defined bridge network is created with a specific subnet and then the 3 docker containers are started using IPs like so:

docker network create --subnet=172.18.0.0/16 my-network
docker run -d --name db --net my-network --ip 172.18.0.10 -p 27017:27017 rating-db
docker run -d --name api -e "MONGODB_URI=mongodb://172.18.0.10:27017/webratings" --net my-network --ip 172.18.0.11 -p 3000:3000 rating-api
docker run -d --name web -e "API=http://172.18.0.11:3000/" --net my-network --ip 172.18.0.12 -p 8080:8080 rating-web

Using IPs is both unnessary and also confusing for readers.

You can achieve the same thing by using the container names instead of IPs:

docker network create my-network
docker run -d --name db --net my-network -p 27017:27017 rating-db
docker run -d --name api -e "MONGODB_URI=mongodb://db:27017/webratings" --net my-network -p 3000:3000 rating-api
docker run -d --name web -e "API=http://api:3000/" --net my-network -p 8080:8080 rating-web

User-defined networks in Docker provide built-in DNS so you don't need to refer to containers by their IPs.

Should look more like this with semi-colon at the end so it's copy-pasteable.

# set these values to yours
ACR_SERVER=<fill_acr_server>;
ACR_USER=<fill_acr_user>;
ACR_PWD=<fill_acr_pwd>;

docker login --username $ACR_USER --password $ACR_PWD $ACR_SERVER

Kubernetes Dashboard

For some reason I'm getting the same issue as:

Azure/azure-cli#8305

when building with the docker file with tags. I simply take out the build tags and it's able to build and push.

This is at step
https://github.com/Azure/blackbelt-aks-hackfest/blob/master/labs/day1-labs/02-dockerize-apps(alt-acr-build).md
When running:
az acr build --registry $ACR_NAME --build-arg BUILD_DATE=date -u +"%Y-%m-%dT%H:%M:%SZ" --build-arg VCS_REF=git rev-parse --short HEAD --build-arg IMAGE_TAG_REF=v1 --image azureworkshop/rating-web:v1 .

Using:

az aks create -n $CLUSTER_NAME -g $NAME -c 2 -k 1.7.7 --generate-ssh-keys -l $LOCATION

Now gives the following message:

Operation failed with status: 'Bad Request'. Details: RBAC feature is not supported with theselected Kubernetes version. The version of Kubernetes must be 1.8.x or higher

Problem
The linux-container-workshop/hol_content``` docs are out of order when we exceed 9 documents.

Solution
Suggest adding/prepending document names with 0 e.g. 01_docname.md, so that they are ordered correctly when we have more than 9 documents.

https://github.com/Azure/blackbelt-aks-hackfest/blob/master/linux-container-workshop/hol-content/05-kubernetes-ui.md

Googled but couldn't find anything about azure black belt or offerings.

Instead of get svc should be get pods

https://github.com/Azure/blackbelt-aks-hackfest/blob/master/linux-container-workshop/hol-content/02-dockerize-apps.md

Need to call out that when az group create ... is called that it needs to be in a region that supports AKS, otherwise you will get an error like this –

$ az aks create -n $NAME -g $NAME -c 2 -k 1.7.7 --generate-ssh-keys
The provided location 'westus' is not available for resource type 'Microsoft.ContainerService/managedClusters'. List of available regions for the resource type is 'eastus,westeurope,centralus,canadacentral,canadaeast,westus2'.

Need contributions and help here, anyone would like to jump on this one?

Since PR #108 and like explained there, "Lab 7 - Add Monitoring to an Azure Kubernetes Service Cluster" is not working well now. Data are not properly populated in Grafana dashboards.

So far, here are what have been found and the thoughts on that so far:

• The lab is using old versions:
  • Prometheus Helm chart 4.6.13 (12/2017), furthermore Prometheus itself changed from 1 to 2 with breaking changes.
  • Grafana Helm chart 0.5.1 (12/2017)
• For this specific Hackfest content, do we want to use the monitoring aks addon instead (Azure Monitor)? Could be enabled at creation or afterward, and it's pretty straightforward - https://docs.microsoft.com/en-us/azure/monitoring/monitoring-container-health
• We are seeing more and more Prometheus Operator...

Azure Kubernetes Service (AKS) Deployment

Step 2 show capital letters instead of lowercase

Hi I noticed that the 4 super hero images in the leaderboard section are absent when using cosmosdb as backend. is something lost along the dump and restore from the mongodb pod?

Including setting the Aggregation Pipeline feature

In lab 05-kubernetes-ui.md, for accessing kubernetes dashboard correctly, we have to run the following command to create cluster role binding.

import.sh is copied to sites.json instead of import.sh.

$ az aks create -n $NAME -g $NAME -c 2 -k 1.7.7 --generate-ssh-keys

• Running ..

This takes a while to run...

tags use azureworkshop/rating-web, but the k8 maifest use just rating-web

Add Monitoring to an Azure Kubernetes Service Cluster

/linux-container-workshop/hol-content/05-kubernetes-ui.md

tells the user to use NAME=$(az group list | jq '.[0]."name"' -r)

But the VM does not have jq installed

sudo yum install jq is one option.. or pre-install it ?

Upgrade an Azure Container Service (AKS) cluster

In the OSBA lab using Cosmos it's using the class azure-cosmos-mongo-db. Doesn't look like that class exists any longer as running apply results in
Error from server (Forbidden): error when creating "heroes-cosmosdb.yaml": serviceinstances.servicecatalog.k8s.io "heroes-cosmosdb-instance" is forbidden: ClusterServiceClass {ClassExternalName:"azure-cosmos-mongo-db"} does not exist, can not figure out the default ClusterServicePlan.
I ran ./svcat get classes and azure-cosmos-mongo-db wasn't listed.

Two of us at SNP (@jayachandralingam and I) independently completed the CI/CD Brigade lab, but in the end our web apps did not update.

We could see the Brigade worker and jobs running and the webhook invoked in GitHub. We installed Kashti to get better visibility into the Brigade builds. In the Kashti dashboard we see the GitHub events for the project, but each in a failed state. In the Build page, it reads "There are currently no jobs inside this build."

Any thoughts as to what may be the cause?

1.11.1 is no longer available.

1.11.2 and 1.11.3 are available.