Merge pull request #106503 from TimShererWithAquent/us1669724g

Azure CLI syntax blocks.

Author: American-Dipper

articles/aks/openfaas.md

@@ -24,9 +24,11 @@ In order to complete the steps within this article, you need the following.
 
 ## Add the OpenFaaS helm chart repo
 
+Go to [https://shell.azure.com](https://shell.azure.com) to open Azure Cloud Shell in your browser.
+
 OpenFaaS maintains its own helm charts to keep up to date with all the latest changes.
 
-```azurecli-interactive
+```console
 helm repo add openfaas https://openfaas.github.io/faas-netes/
 helm repo update
 ```
@@ -37,13 +39,13 @@ As a good practice, OpenFaaS and OpenFaaS functions should be stored in their ow
 
 Create a namespace for the OpenFaaS system and functions:
 
-```azurecli-interactive
+```console
 kubectl apply -f https://raw.githubusercontent.com/openfaas/faas-netes/master/namespaces.yml
 ```
 
 Generate a password for the OpenFaaS UI Portal and REST API:
 
-```azurecli-interactive
+```console
 # generate a random password
 PASSWORD=$(head -c 12 /dev/urandom | shasum| cut -d' ' -f1)
 
@@ -58,7 +60,7 @@ The password we create here will be used by the helm chart to enable basic authe
 
 A Helm chart for OpenFaaS is included in the cloned repository. Use this chart to deploy OpenFaaS into your AKS cluster.
 
-```azurecli-interactive
+```console
 helm upgrade openfaas --install openfaas/openfaas \
     --namespace openfaas  \
     --set basic_auth=true \
@@ -68,7 +70,7 @@ helm upgrade openfaas --install openfaas/openfaas \
 
 Output:
 
-```
+```output
 NAME:   openfaas
 LAST DEPLOYED: Wed Feb 28 08:26:11 2018
 NAMESPACE: openfaas
@@ -96,7 +98,7 @@ kubectl get service -l component=gateway --namespace openfaas
 
 Output.
 
-```console
+```output
 NAME               TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)          AGE
 gateway            ClusterIP      10.0.156.194   <none>         8080/TCP         7m
 gateway-external   LoadBalancer   10.0.28.18     52.186.64.52   8080:30800/TCP   7m
@@ -116,7 +118,7 @@ Set `$OPENFAAS_URL` to the public IP found above.
 
 Log in with the Azure CLI:
 
-```azurecli-interactive
+```console
 export OPENFAAS_URL=http://52.186.64.52:8080
 echo -n $PASSWORD | ./faas-cli login -g $OPENFAAS_URL -u admin --password-stdin
 ```
@@ -131,13 +133,13 @@ Click on **Deploy New Function** and search for **Figlet**. Select the Figlet fu
 
 Use curl to invoke the function. Replace the IP address in the following example with that of your OpenFaas gateway.
 
-```azurecli-interactive
+```console
 curl -X POST http://52.186.64.52:8080/function/figlet -d "Hello Azure"
 ```
 
 Output:
 
-```console
+```output
  _   _      _ _            _
 | | | | ___| | | ___      / \    _____   _ _ __ ___
 | |_| |/ _ \ | |/ _ \    / _ \  |_  / | | | '__/ _ \
@@ -178,46 +180,46 @@ Now populate the Cosmos DB with test data. Create a file named `plans.json` and
 
 ```json
 {
-	"name" : "two_person",
-	"friendlyName" : "Two Person Plan",
-	"portionSize" : "1-2 Person",
-	"mealsPerWeek" : "3 Unique meals per week",
-	"price" : 72,
-	"description" : "Our basic plan, delivering 3 meals per week, which will feed 1-2 people.",
-	"__v" : 0
+    "name" : "two_person",
+    "friendlyName" : "Two Person Plan",
+    "portionSize" : "1-2 Person",
+    "mealsPerWeek" : "3 Unique meals per week",
+    "price" : 72,
+    "description" : "Our basic plan, delivering 3 meals per week, which will feed 1-2 people.",
+    "__v" : 0
 }
 ```
 
 Use the *mongoimport* tool to load the CosmosDB instance with data.
 
 If needed, install the MongoDB tools. The following example installs these tools using brew, see the [MongoDB documentation][install-mongo] for other options.
 
-```azurecli-interactive
+```console
 brew install mongodb
 ```
 
 Load the data into the database.
 
-```azurecli-interactive
+```console
 mongoimport --uri=$COSMOS -c plans < plans.json
 ```
 
 Output:
 
-```console
+```output
 2018-02-19T14:42:14.313+0000    connected to: localhost
 2018-02-19T14:42:14.918+0000    imported 1 document
 ```
 
 Run the following command to create the function. Update the value of the `-g` argument with your OpenFaaS gateway address.
 
-```azurecli-interctive
+```console
 faas-cli deploy -g http://52.186.64.52:8080 --image=shanepeckham/openfaascosmos --name=cosmos-query --env=NODE_ENV=$COSMOS
 ```
 
 Once deployed, you should see your newly created OpenFaaS endpoint for the function.
 
-```console
+```output
 Deployed. 202 Accepted.
 URL: http://52.186.64.52:8080/function/cosmos-query
 ```

articles/aks/spark-job.md

@@ -181,7 +181,7 @@ export AZURE_STORAGE_CONNECTION_STRING=`az storage account show-connection-strin
 
 Upload the jar file to the Azure storage account with the following commands.
 
-```bash
+```azurecli
 CONTAINER_NAME=jars
 BLOB_NAME=SparkPi-assembly-0.1.0-SNAPSHOT.jar
 FILE_TO_UPLOAD=target/scala-2.11/SparkPi-assembly-0.1.0-SNAPSHOT.jar
@@ -236,8 +236,10 @@ Submit the job using `spark-submit`.
 This operation starts the Spark job, which streams job status to your shell session. While the job is running, you can see Spark driver pod and executor pods using the kubectl get pods command. Open a second terminal session to run these commands.
 
 ```console
-$ kubectl get pods
+kubectl get pods
+```
 
+```output
 NAME                                               READY     STATUS     RESTARTS   AGE
 spark-pi-2232778d0f663768ab27edc35cb73040-driver   1/1       Running    0          16s
 spark-pi-2232778d0f663768ab27edc35cb73040-exec-1   0/1       Init:0/1   0          4s
@@ -265,7 +267,7 @@ kubectl get pods --show-all
 
 Output:
 
-```bash
+```output
 NAME                                               READY     STATUS      RESTARTS   AGE
 spark-pi-2232778d0f663768ab27edc35cb73040-driver   0/1       Completed   0          1m
 ```
@@ -278,7 +280,7 @@ kubectl logs spark-pi-2232778d0f663768ab27edc35cb73040-driver
 
 Within these logs, you can see the result of the Spark job, which is the value of Pi.
 
-```bash
+```output
 Pi is roughly 3.152155760778804
 ```
 

articles/aks/update-credentials.md

@@ -64,7 +64,7 @@ The output is similar to the following example. Make a note of your own `appId`
 
 Now define variables for the service principal ID and client secret using the output from your own [az ad sp create-for-rbac][az-ad-sp-create] command, as shown in the following example. The *SP_ID* is your *appId*, and the *SP_SECRET* is your *password*:
 
-```azurecli-interactive
+```console
 SP_ID=7d837646-b1f3-443d-874c-fd83c7c739c5
 SP_SECRET=a5ce83c9-9186-426d-9183-614597c7f2f7
 ```

articles/aks/use-network-policies.md

@@ -38,7 +38,7 @@ These network policy rules are defined as YAML manifests. Network policies can b
 
 Azure provides two ways to implement network policy. You choose a network policy option when you create an AKS cluster. The policy option can't be changed after the cluster is created:
 
-* Azure’s own implementation, called *Azure Network Policies*.
+* Azure's own implementation, called *Azure Network Policies*.
 * *Calico Network Policies*, an open-source network and network security solution founded by [Tigera][tigera].
 
 Both implementations use Linux *IPTables* to enforce the specified policies. Policies are translated into sets of allowed and disallowed IP pairs. These pairs are then programmed as IPTable filter rules.
@@ -168,7 +168,7 @@ wget -qO- http://backend
 
 The following sample output shows that the default NGINX webpage returned:
 
-```
+```output
 <!DOCTYPE html>
 <html>
 <head>
@@ -200,15 +200,16 @@ spec:
   ingress: []
 ```
 
+Go to [https://shell.azure.com](https://shell.azure.com) to open Azure Cloud Shell in your browser.
+
 Apply the network policy by using the [kubectl apply][kubectl-apply] command and specify the name of your YAML manifest:
 
-```azurecli-interactive
+```console
 kubectl apply -f backend-policy.yaml
 ```
 
 ### Test the network policy
 
-
 Let's see if you can use the NGINX webpage on the back-end pod again. Create another test pod and attach a terminal session:
 
 ```console
@@ -218,8 +219,10 @@ kubectl run --rm -it --image=alpine network-policy --namespace development --gen
 At the shell prompt, use `wget` to see if you can access the default NGINX webpage. This time, set a timeout value to *2* seconds. The network policy now blocks all inbound traffic, so the page can't be loaded, as shown in the following example:
 
 ```console
-$ wget -qO- --timeout=2 http://backend
+wget -qO- --timeout=2 http://backend
+```
 
+```output
 wget: download timed out
 ```
 
@@ -260,7 +263,7 @@ spec:
 
 Apply the updated network policy by using the [kubectl apply][kubectl-apply] command and specify the name of your YAML manifest:
 
-```azurecli-interactive
+```console
 kubectl apply -f backend-policy.yaml
 ```
 
@@ -278,7 +281,7 @@ wget -qO- http://backend
 
 Because the ingress rule allows traffic with pods that have the labels *app: webapp,role: frontend*, the traffic from the front-end pod is allowed. The following example output shows the default NGINX webpage returned:
 
-```
+```output
 <!DOCTYPE html>
 <html>
 <head>
@@ -303,8 +306,10 @@ kubectl run --rm -it --image=alpine network-policy --namespace development --gen
 At the shell prompt, use `wget` to see if you can access the default NGINX webpage. The network policy blocks the inbound traffic, so the page can't be loaded, as shown in the following example:
 
 ```console
-$ wget -qO- --timeout=2 http://backend
+wget -qO- --timeout=2 http://backend
+```
 
+```output
 wget: download timed out
 ```
 
@@ -339,7 +344,7 @@ wget -qO- http://backend.development
 
 Because the labels for the pod match what is currently permitted in the network policy, the traffic is allowed. The network policy doesn't look at the namespaces, only the pod labels. The following example output shows the default NGINX webpage returned:
 
-```
+```output
 <!DOCTYPE html>
 <html>
 <head>
@@ -383,7 +388,7 @@ In more complex examples, you could define multiple ingress rules, like a *names
 
 Apply the updated network policy by using the [kubectl apply][kubectl-apply] command and specify the name of your YAML manifest:
 
-```azurecli-interactive
+```console
 kubectl apply -f backend-policy.yaml
 ```
 
@@ -398,8 +403,10 @@ kubectl run --rm -it frontend --image=alpine --labels app=webapp,role=frontend -
 At the shell prompt, use `wget` to see that the network policy now denies traffic:
 
 ```console
-$ wget -qO- --timeout=2 http://backend.development
+wget -qO- --timeout=2 http://backend.development
+```
 
+```output
 wget: download timed out
 ```
 
@@ -423,7 +430,7 @@ wget -qO- http://backend
 
 Traffic is allowed because the pod is scheduled in the namespace that matches what's permitted in the network policy. The following sample output shows the default NGINX webpage returned:
 
-```
+```output
 <!DOCTYPE html>
 <html>
 <head>

articles/aks/virtual-nodes-cli.md

@@ -25,7 +25,7 @@ az provider list --query "[?contains(namespace,'Microsoft.ContainerInstance')]"
 
 The *Microsoft.ContainerInstance* provider should report as *Registered*, as shown in the following example output:
 
-```
+```output
 Namespace                    RegistrationState
 ---------------------------  -------------------
 Microsoft.ContainerInstance  Registered
@@ -115,7 +115,7 @@ az ad sp create-for-rbac --skip-assignment
 
 The output is similar to the following example:
 
-```
+```output
 {
   "appId": "bef76eb3-d743-4a97-9534-03e9388811fc",
   "displayName": "azure-cli-2018-11-21-18-42-00",
@@ -197,9 +197,7 @@ kubectl get nodes
 
 The following example output shows the single VM node created and then the virtual node for Linux, *virtual-node-aci-linux*:
 
-```
-$ kubectl get nodes
-
+```output
 NAME                          STATUS    ROLES     AGE       VERSION
 virtual-node-aci-linux        Ready     agent     28m       v1.11.2
 aks-agentpool-14693408-0      Ready     agent     32m       v1.11.2
@@ -248,9 +246,11 @@ kubectl apply -f virtual-node.yaml
 
 Use the [kubectl get pods][kubectl-get] command with the `-o wide` argument to output a list of pods and the scheduled node. Notice that the `aci-helloworld` pod has been scheduled on the `virtual-node-aci-linux` node.
 
+```console
+kubectl get pods -o wide
 ```
-$ kubectl get pods -o wide
 
+```output
 NAME                            READY     STATUS    RESTARTS   AGE       IP           NODE
 aci-helloworld-9b55975f-bnmfl   1/1       Running   0          4m        10.241.0.4   virtual-node-aci-linux
 ```
@@ -282,9 +282,7 @@ curl -L http://10.241.0.4
 
 The demo application is displayed, as shown in the following condensed example output:
 
-```
-$ curl -L 10.241.0.4
-
+```output
 <html>
 <head>
   <title>Welcome to Azure Container Instances!</title>
@@ -298,9 +296,11 @@ Close the terminal session to your test pod with `exit`. When your session is en
 
 If you no longer wish to use virtual nodes, you can disable them using the [az aks disable-addons][az aks disable-addons] command. 
 
+If necessary, go to [https://shell.azure.com](https://shell.azure.com) to open Azure Cloud Shell in your browser.
+
 First, delete the helloworld pod running on the virtual node:
 
-```azurecli-interactive
+```console
 kubectl delete -f virtual-node.yaml
 ```