Docker JumpStart Virtual Workshop

I want to share here about Docker training I will be attending later this month June 24th/25th, 2019. It is a Docker JumpStart Virtual Workshop. I am excited about this training because it will be delivered by a fellow Microsoft MVP’s Dan Wahlin and Mike Pfeiffer. Also Dan Wahlin is a Docker Captain.

For those that don’t know a Docker Captain is like a Microsoft MVP but for Docker. There will even be some Kubernetes covered on day 2. This is shaping up to be some great training.

As of now there is still room in this class and its less than $300 USD! If you have wanted to get up to speed on Docker this is a good low cost way to do it. Here is a link to sign up: Docker JumpStart Workshop

Here is what will be covered across the 2 days (from the training website):

Day 1:

Read More

Azure Blockchain Workbench Whitepaper

I recently read a Career Advice for IT professionals in 2019 article and was reminded again by a friend and fellow MVP’s on his blog that “Change is always constant in IT.

Part of being an IT professional is keeping an eye on and ramping up on new technology. Change in IT is constant and it is critical to explore new technology so you can bring innovation to your organization and ensure you are ready if the business decides they want to use a specific technology to gain an edge in the market.

With all the excitement around Blockchain, I decided to spend time ramping up on Azure’s Blockchain technology specifically Azure Blockchain Workbench. Azure Blockchain Workbench is a way for developers and IT pros to get A blockchain network up and running quickly.

Once Azure Blockchain Workbench is up and running IT pros can administrator the network and developers can dive right into building blockchain apps. Most people that have heard of blockchain are familiar with cryptocurrency such as Bitcoin. Most people don’t know of or associate blockchain with smart contracts. Azure Blockchain Workbench powers smart contract technology. A smart contract is a self-executing contract between two or more parties involved in a transaction. Getting started with Blockchain can seem intimidating but with Azure Blockchain Workbench it is not hard to get started. I wrote a white paper that you can use to get started and takes you beyond cryptocurrency into the world of smart contracts using Azure Blockchain Workbench.

The white paper covers the following:

  • Explorers blockchain beyond cryptocurrency
  • Has an in-depth overview of Ethereum and smart contracts
  • Helps identify when and what to use blockchain for?
  • The Azure Blockchain Workbench architecture
  • How to deploy Azure Blockchain Workbench
  • How to deploy a blockchain application

The Azure Blockchain white paper titled “Blockchain beyond cryptocurrency – A white paper on Azure Blockchain Workbench” can be downloaded here: https://gallery.technet.microsoft.com/Blockchain-beyond-b18066b9

Read More

0 to 60 with Azure Blockchain Workbench

Almost every day when you go to a news website, a news program on the radio or news on the TV you can expect to hear some mention of Cryptocurrency and increasingly something about Blockchain.

Blockchain has a strong buzz and yet it is still misunderstood by many. It is an exciting time for technology and blockchain is one of the many reasons why. Blockchain is a public distributed digital ledger. Transactions between parties are processed in an efficient, verifiable and immutable way using cryptography. Transactions are tracked without a central entity such as a bank processing and keeping a record of the transactions. The ledger in a Blockchain is distributed across many nodes in the Blockchain network. Each time a transaction occurs the ledger is reconciled across all the nodes.

The Blockchain you typically hear about is related to some cryptocurrency such as Bitcoin, Litecoin, or Ripple. Blockchain goes way beyond this and is a technology that is being widely explored in use by some enterprises. Here are some examples of Blockchain in use within the enterprise. Microsoft’s Xbox uses Blockchain to deliver royalty statements to game publishers, FedEx uses Blockchain for storing shipping records, and 3M is using Blockchain for a new label-as-a-service concept. The commonality those examples is that they are using Blockchain smart contract technology.

A smart contract is a self-executing contract between two or more parties involved in a transaction. A smart contract holds each party in the transaction responsible without the need for a third-party authority. Smart contracts are essentially code running on top of a blockchain that are digitally facilitated, verified, and auto-enforced under the set of terms laid out within the contract.

Opposite of Blockchain used for cryptocurrency Blockchain used for smart contracts enable more complex scenarios beyond the exchange of digital currency. To illustrate an example of a Blockchain smart contract think about being able to buy and sell cars without a DMV processing the exchange of titles but instead the exchange of the title being verified and transferred digitally.

In today’s fast-moving world of technology, it is important to be able to take your solution from idea to MVP aka 0 to 60 as fast as possible. That is the goal of the Azure Blockchain Workbench (ABW). As shown in the following image with ABW you can literally go from idea>consortium blockchain network>code/use pre-built blockchain app>Blockchain app ready to use in a short amount of time.

 When I first started with Blockchain I was able to go from nothing to a fully functional Blockchain app in a couple of hours using ABW. As seen in the previous image ABW is made up of a combination of Azure services and capabilities. The main services include:

An App Service Plan with two web apps and two web APIs

An Application Insights instance

An Event Grid Topic

A couple of Key Vaults

A Service Bus Namespace

A SQL Server with a SQL Databases

A couple of Azure Storage accounts

Two Virtual Machine scale sets that consist of the ledger nodes and workbench microservices

A couple of virtual Network resource groups that contain Load Balancers, Network Security Groups, Public IP Address, and Virtual Network, VNet peering, and Subnets

Other components leveraged by ABW are Azure Active Directory for identity, Azure Monitor (optional), and log analytics workspace for logging (deployed with Azure Monitor), a mobile app for both iOS and Android along with a REST-based gateway service API to integrate to blockchain apps. Workbench provides the infrastructure needed to build and deploy blockchain applications so when you deploy ABW it includes everything you need. As of now ABW only supports Ethereum as its target blockchain. Microsoft has plans to add Hyperledger and Corda Blockchains in the future.

ABW is designed to make it easy for developers to bring Blockchain to the enterprise. ABW is deployed in the Azure Portal via a solution template. You can deploy Ethereum or attach to an existing one. After the Blockchain Workbench is deployed developers have the option to either create a Blockchain app or use one of the Applications and Smart Contract Samples from a repository maintained by Microsoft.

These Blockchain apps consist of a configuration metadata and smart contract. The configuration metadata file is in JSON format and determines the multi-party workflow the smart contract is in a language named Solidity and determines the business logic of the Blockchain application itself. The configuration and smart contract together make up the Blockchain application user experience. The Applications and Smart Contract Samples can be used as is to take Blockchain for a test run or can be modified to fit an organization’s specific need. As an example, some of the information you can modify with the configuration is application name, display name, state, and application roles.

As you can see it is relatively easy to get a Blockchain application up and going. Another real benefit to running a Blockchain application on Azure is the integration points with many of the other services available on Azure. Here are a few examples. ABW writes a copy of the Blockchains on-chain data from the Blockchain distributed ledgers to an off-chain SQL database. Developers can connect to this database to work with the Blockchain data for any number of scenarios one of them could be reporting in Power BI. The Workbench has a REST API, Service Bus, IoT Hub, and Event Grid that could be used for integration with other technology such as IoT devices, other systems, and Azure Streaming Analytics to further expand the possibilities. With the Blockchain workbench developers also have access to one of Azures automation tools called Logic Apps opening the door to a world of further automation scenarios.

There is much more to the Azure Blockchain Workbench then can be covered in a single blog. The main point of this post is to show how a developer can go from 0 to 60 within a short amount of time with minimal effort to stand up the scaffolding needed to support a Blockchain app. For a deeper dive into the Azure Workbench it is recommended to download my Blockchain Beyond Cryptocurrency whitepaper once it is released. Thanks for reading. To get started with the Azure Blockchain Workbench visit this link: https://azure.microsoft.com/en-us/features/blockchain-workbench

Read More

Deploy Rancher on Azure for Kubernetes Management

Lately I have been hearing a lot about a solution named Rancher in the Kubernetes space. Rancher is an open source Kubernetes Multi-Cluster Operations and Workload Management solution. You can learn more about Rancher here: https://www.rancher.com.

In short you can use Rancher to deploy and manage Kubernetes clusters deployed to Azure, AWS, GCP their managed Kubernetes offerings like GCE, EKS, AKS or even if you rolled your own. Rancher also integrates with a bunch of 3rd party solutions for things like authentication such as Active Directory, Azure Active Directory, Github, and Ping and logging solutions such as Splunk, Elasticsearch, or a Syslog endpoint.

Recently training opened up for some Rancher/Kubernetes/Docker training so I decided to go. The primary focus was on Rancher while also covering some good info on Docker and Kubernetes. This was really good training with a lot of hands on time, however there was one problem with the labs. The labs had instructions and setup scripts ready to go to run Rancher local on your laptop or on AWS via Terraform. There was nothing for Azure.

I ended up getting my Rancher environment running on Azure but it would have been nice to have some scripts or templates ready to go to spin up Rancher on Azure. I did find some ARM templates to spin up Rancher but they deployed an old version and it was not clear in the templates on where they could be updated to deploy the new version of Rancher. I decided to spend some time building out a couple of ARM templates that can be used to quickly deploy Rancher on Azure and add a Kubernetes host to Rancher. In the ARM template I pulled together it pulls the Rancher container from Docker Hub so it will always deploy the latest version. In this blog post I will spell out the steps to get your Rancher up and running in under 15 minutes.

First off you can find the ARM Templates here on my Github here: https://github.com/Buchatech/DeployRanchertoAzure.

The repository consists of ARM templates for deploying Rancher and a host VM for Kubernetes. NOTE: These templates are intended for labs to learn Rancher. They are not intended for use in production.

In the repo ARM Template #1 named RancherNode.JSON will deploy an Ubuntu VM with Docker and the latest version of Rancher (https://hub.docker.com/r/rancher/rancher) from Docker Hub. ARM Template #2 named RancherHost.JSON will deploy an Ubuntu VM with Docker to be used as a Kubernetes host in Rancher.

Node Deployment

Deploy the RancherNode.JSON ARM template to your Azure subscription through “Template Deployment” or other deployment method. You will be prompted for the following info shown in the screenshot:

Host Deployment

Deploy the RancherHost.JSON ARM template to your Azure subscription through “Template Deployment” or other deployment method. Note that that should deploy this into the same Resource Group that you deployed the Rancher Node ARM template into. You will be prompted for the following info shown in the screenshot:

After the Rancher Node and Rancher Host ARM templates are deployed you should see the following resources in the new Resource Group:

NameType
RancherVNet Virtual network
RancherHost Virtual machine
RancherNode Virtual machine
RancherHostPublicIP Public IP address
RancherNodePublicIP Public IP address
RancherHostNic Network interface
RancherNodeNic Network interface
RancherHost_OSDisk Disk
RancherNode_OSDisk Disk

Next navigate the Rancher portal in the web browser. The URL is the DNS name of the Rancher Node VM. You can find the DNS name by clicking on the Rancher Node VM in the Azure portal on the overview page. Here is an example of the URL:

https://ranchernode.centralus.cloudapp.azure.com

The Rancher portal will prompt you to set a password. This is shown in the following screenshot.

After setting the password the Rancher portal will prompt you for the correct Rancher Server URL. This will automatically be the Rancher Node VM DNS name. Click Save URL.

You will then be logged into the Rancher portal. You will see the cluster page. From here you will want to add a cluster. Doing this is how you add a new Kubernetes cluster to Rancher. In this post I will show you how to add a cluster to the Rancher Host VM. When it’s all said and done Rancher will have successfully deployed Kubernetes to the Rancher Host VM. Note that you could add a managed Kubernetes such as AKS but we won’t do that in this blog. I will save that for a future blog post!

Click on Add Cluster

Under “From my own existing nodes” Click on custom, give the cluster a name and click Next.

Next check all the boxes for the Node Options since all the roles will be on a single Kubernetes cluster. Copy the code shown at the bottom of the page, click done and run the code on the Rancher Host.

In order to run the code on the Rancher Host you need to SSH in and run it from there. To do this follow these steps:

  1. In the Azure Portal, from within the resource group click on the Rancher Host VM.
  2. On the Overview page click on Connect.
  3. Copy “ssh ranchuser@rancherhost.centralus.cloudapp.azure.com” from the Connect to virtual machine pop up screen.
  4. Open a terminal in either Azure cloud shell or with something like a terminal via VS Code and past the “ssh ranchuser@rancherhost.centralus.cloudapp.azure.com” in.

Running the code will look like this:

When done you can run Docker PS to see that the Rancher agent containers are running.

In the Rancher portal under clusters you will see the Rancher host being provisioned

The status will change as Kubernetes is deployed.

Once it’s done provisioning you will see your Kubernetes cluster as Active.

From here you can see a bunch of info about your new Kubernetes cluster. Also notice that you could even launch Kubectl right from hereand start running commands! Take some time to click around to see all the familiar stuff you are used to working with in Kubernetes. This is pretty cool and simplifies the management experience for Kubernetes. 

If you want to add more nodes or need the configuration code again just click the ellipsis button and edit.

In Edit Cluster you can change the cluster name, get and change settings and copy the code to add more VMs to the cluster.

That’s the end of this post. Thanks for reading. Check back for more Azure, Kubernetes, and Rancher blog posts.

Read More

Where to host Docker Containers on Azure (AKS, ASE, or ASF)?

Azure Kubernetes Service (AKS) service Azure App Service Environment (ASE) Azure Service Fabric (ASF) Comparison

Scenario:

So, your team recently has been tasked with developing a new application and running it. The team made the decision to take a microservices based approach to the application. Your team also has decided to utilize Docker containers and Azure as a cloud platform. Great, now it’s time to move forward right? Not so fast. There is no question that Docker containers will be used, but what is in question is where you will run the containers. In Azure containers can run on Azure’s managed Kubernetes (AKS) service, an App Service Plan on Azure App Service Environment (ASE), or Azure Service Fabric (ASF). Let’s look at each one of these Azure services including an overview, pro’s, cons, and pricing.

This Azure Kubernetes Service (AKS) Pros and Cons chart is clickable.
This Azure App Service Environment (ASE) Pros and Cons chart is clickable.
This Azure Service Fabric (ASF) Pros and Cons chart is clickable.

Conclusion:

Choose Azure Kubernetes Service if you need more control, want to avoid vendor lock-in (can run on Azure, AWS, GCP, on-prem), need features of a full orchestration system, flexibility of auto scale configurations, need deeper monitoring, flexibility with networking, public IP’s, DNS, SSL, need a rich ecosystem of addons, will have many multi-container deployments, and plan to run a large number of containers. Also, this is a low cost.

Choose Azure App Service Environment if don’t need as much control, want a dedicated SLA, don’t need deep monitoring or control of the underlying server infrastructure, want to leverage features such as deployment slots, green/blue deployments, will have simple and a low number of multi-container deployments via Docker compose, and plan to run a smaller number of containers. Regarding cost, running a containerized application in an App Service Plan in ASE tends to be more expensive compared to running in AKS or Service Fabric. The higher cost of running containers on ASE is because with an App Service Plan on ASE, you are paying costs for a combination of resources and the managed service. With AKS and ASF you are only paying for the resources used.

Choose Service Fabric if you want a full micros services platform, need flexibility now or in the future to run in cloud and or on-premises, will run native code in addition to containers, want automatic load balancing, low cost.

A huge thanks to my colleague Sunny Singh (@sunnys101) for giving his input and reviewing this post. Thanks for reading and check back for more Azure and container contents soon.

Read More

Monitoring Azure Kubernetes Service (AKS) with Azure Monitor & Log Analytics

Part of running Kubernetes is being able to monitoring the cluster, the nodes, and the workloads running in it. Running production workloads regardless of PaaS, VM’s, or containers requires a solid level of reliability. Azure Kubernetes Service comes with monitoring provided from Azure bundled with the semi-managed service. Kubernetes also has built in monitoring that can also be utilized.

It is important to note that AKS is a free service and Microsoft aims to achieve at least 99.5% availability for the Kubernetes API server on the master node side.

But due to AKS being a free service Microsoft does not carry an SLA on the Kubernetes cluster service itself. Microsoft does provide an SLA for the availability of the underlying nodes in the cluster via the Azure Virtual Machines SLA. Without an official SLA for the Kubernetes cluster service it becomes even more critical to understand your deployment and have the right monitoring tooling and plan in place so when an issue arises the DevOps or CloudOps team can address, investigate, and resolve any issues with the cluster.

The monitoring service included with AKS gives you monitoring from two perspectives including the first one being directly from an AKS cluster and the second one being all AKS clusters in a subscription. The monitoring looks at two key areas “Health status” and “Performance charts” and consists of:

Insights – Monitoring for the Kubernetes cluster and containers.

Metrics – Metric based cluster and pod charts.

Log Analytics – K8s and Container logs viewing and search.

Azure Monitor

Azure Monitor has a containers section. Here is where you will find a health summary across all clusters in a subscription including ACS. You also will see how many nodes and system/user pods a cluster has and if there are any health issues with the a node or pod. If you click on a cluster from here it will bring you to the Insights section on the AKS cluster itself.

If you click on an AKS cluster you will be brought to the Insights section of AKS monitoring on the actual AKS cluster. From here you can access the Metrics section and the Logs section as well as shown in the following screenshot.

Insights

Insights is where you will find the bulk of useful data when it comes to monitoring AKS. Within Insights you have these 4 areas Cluster, Nodes, Controllers, and Containers. Let’s take a deeper look into each of the 4 areas.

Cluster

The cluster page contains charts with key performance metrics for your AKS clusters health. It has performance charts for your node count with status, pod count with status, along with aggregated node memory and CPU utilization across the cluster. In here you can change the date range and add filters to scope down to specific information you want to see.

Nodes

After clicking on the nodes tab you will see the nodes running in your AKS cluster along with uptime, amount of pods on the node, CPU usage, memory working set, and memory RSS. You can click on the arrow next to a node to expand it displaying the pods that are running on it.

What you will notice is that when you click on a node, or pod a property pane will be shown on the right hand side with the properties of the selected object. An example of a node is shown in the following screenshot.

Controllers

Click on the Controllers tab to see the health of the clusters controllers. Again here you will see CPU usage, memory working set, and memory RSS of each controller and what is running a controller. As an example shown in the following screenshot you can see the kubernetes dashboard pod running on the kubernetes-dashboard controller.

The properties of the kubernetes dashboard pod as shown in the following screenshot gives you information like the pod name, pod status, Uid, label and more.

You can drill in to see the container the pod was deployed using.

Containers

On the Containers tab is where all the containers in the AKS cluster are displayed. An as with the other tabs you can see CPU usage, memory working set, and memory RSS. You also will see status, the pod it is part of, the node its running on, its uptime and if it has had any restarts. In the following screenshot the CPU usage metric filter is used and I am showing a containers that has restarted 71 times indicating an issue with that container.

 In the following screenshot the memory working set metric filter is shown.

You can also filter the containers that will be shown through using the searching by name filter.

You also can see a containers logs in the containers tab. To do this select a container to show its properties. Within the properties you can click on View container live logs (preview) as shown in the following screenshot or View container logs. Container log data is collected every three minutes. STDOUT and STDERR is the log output from each Docker container that is sent to Log Analytics.

Kube-system is not currently collected and sent to Log Analytics. If you are not familiar with Docker logs more information on STDOUT and STDERR can be found on this Docker logging article here:  https://docs.docker.com/config/containers/logging.

Read More

Deploy MySQL and WordPress on Azure Kubernetes Service (AKS)

In this blog post I am going to walk through the steps for deploying WordPress to Azure Kubernetes Service (AKS) using MySQL and WordPress Docker images. Note that using the way I will show you is one way. Another way to deploy WordPress to AKS would be using a Helm Chart. Here is a link to the WordPress Helm Chart by Bitnami https://bitnami.com/stack/wordpress/helm. Here are the images we will use in this blog post:
MySQL WordPress
apiVersion: v1
kind: Service
metadata:
name: wordpress-mysql
labels:
app: wordpress
spec:
ports:
– port: 3306
selector:
app: wordpress
tier: mysql
clusterIP: None

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mysql-pv-claim
labels:
app: wordpress
spec:
accessModes:
– ReadWriteOnce
resources:
requests:
storage: 20Gi

apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
name: wordpress-mysql
labels:
app: wordpress
spec:
selector:
matchLabels:
app: wordpress
tier: mysql
strategy:
type: Recreate
template:
metadata:
labels:
app: wordpress
tier: mysql
spec:
containers:
– image: mysql:5.6
name: mysql
env:
– name: MYSQL_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: mysql-pass
key: password
ports:
– containerPort: 3306
name: mysql
volumeMounts:
– name: mysql-persistent-storage
mountPath: /var/lib/mysql
volumes:
– name: mysql-persistent-storage
persistentVolumeClaim:
claimName: mysql-pv-claim
apiVersion: v1
kind: Service
metadata:
name: wordpress
labels:
app: wordpress
spec:
ports:
– port: 80
selector:
app: wordpress
tier: frontend
type: LoadBalancer

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: wp-pv-claim
labels:
app: wordpress
spec:
accessModes:
– ReadWriteOnce
resources:
requests:
storage: 20Gi

apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
name: wordpress
labels:
app: wordpress
spec:
selector:
matchLabels:
app: wordpress
tier: frontend
strategy:
type: Recreate
template:
metadata:
labels:
app: wordpress
tier: frontend
spec:
containers:
– image: wordpress:4.8-apache
name: wordpress
env:
– name: WORDPRESS_DB_HOST
value: wordpress-mysql
– name: WORDPRESS_DB_PASSWORD
valueFrom:
secretKeyRef:
name: mysql-pass
key: password
ports:
– containerPort: 80
name: wordpress
volumeMounts:
– name: wordpress-persistent-storage
mountPath: /var/www/html
volumes:
– name: wordpress-persistent-storage
persistentVolumeClaim:
claimName: wp-pv-claim

The first thing we need to do is save these files as mysql-deployment.yaml and wordpress-deployment.yaml respectively.

Next, we need to setup a password for our MySQL DB. We will do this by creating a secret on our K8s cluster. To do this launch the bash or PowerShell in Azure cloud shell like in the following screenshot and run the following syntax:

kubectl create secret generic mysql-pass –from-literal=password=YOURPASSWORDHERE

Note: Replace “PASSWORDHERE” in the syntax with your own password.

The secret is now created. To ensure it was created you can run the following syntax to list the secrets:

kubectl get secrets

You also can see the secret in the Kubernetes dashboard as shown in the following screenshot.

Next the mysql-deployment.yaml and wordpress-deployment.yaml files from the beginning of this post need to be uploaded to Azure cloudrive storage.

You can also do this in the Cloudshell as shown in the following screenshot.

Run ls in the shell to make sure the files are on your clouddrive.

You will need your home drive. Mine was. /home/steve. To see this, click on Download. It will show you what yours is.

Next create the MySQL Pod and service by running the following syntax.

kubectl apply -f /home/steve/mysql-deployment.yaml

NOTE: You could use kubectl create /home/steve/mysql-deployment.yaml instead of apply to create the MySQL pod and service. I use apply because I typically use the declarative object configuration approach. kubectl apply essentially equals kubectl create + kubectl replace. In order to update an object after it has been created using kubectl create you would need to run kubectl replace.

There are pros and cons to using each and it is more of a preference for example when using the declarative approach there is no audit trail associated with changes. For more information on the multiple Kubernetes Object Management approaches go here: https://kubernetes.io/docs/concepts/overview/object-management-kubectl/overview.

Note that in the mysql yaml file it has syntax to create a persistent volume. This is needed so that the database stays in tact even if the pod fails, is moved etc. You can check to ensure the persistent volume was created by running the following syntax:

kubectl get pvc

Also, you can run the following syntax to verify the mysql pod is running:

kubectl get pods

Deploying the WordPress Pod and service is the same process. Use the following syntax to create the WordPress pod and service:

kubectl apply -f /home/steve/wordpress-deployment.yaml

Again, check to ensure the persistent volume was created. Use the following syntax:

kubectl get pvc

NOTE: When checking right after you created the persistent volume it may be in a pending status for a while like shown in the following screenshot:

You can also check the persistent volume using the K8s dashboard as shown in the following screenshot:

With the deployment of MySQL and WordPress we created 2 services. The MySQL service has a clusterip that can only be accessed internally. The WordPress service has an external IP that is also attached to an Azure Load Balancer for external access. I am not going to expand on what Kubernetes services are in this blog post but know that they are typically used as an abstracted layer in K8s used for access to Pods on the backend and follow the Pods regardless of the node they are running on. For more information about Kubernetes services visit this link: https://kubernetes.io/docs/concepts/services-networking/service.

In order to see that the services are running properly and find out the external IP you can run the following syntax:

kubectl get services (to see all services)

or

kubectl get services wordpress (to see just the WordPress service)

You also can view the services in the K8s dashboard as shown in the following screenshot:

Well now that we have verified the pods and the services are running let’s check out our new WordPress instance by going to the external IP in a web browser.

Thanks for checking out this blog post. I hope this was an easy to use guide to get WordPress up and running on your Azure Kubernetes Service cluster. Check back soon for more Azure and Kubernetes/Container content.

Read More

Getting Started with Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) is a fully managed Kubernetes (K8s) offering from Microsoft on the Azure platform. AKS reduces the management overhead of running your own K8s instance while still being able to take full advantage of Container Orchestration. Microsoft takes care of the K8s health monitoring and maintenance. With AKS you only manage the agent nodes while Microsoft manages the master nodes. Also with AKS you get integration to many of the Azure services such as load balancers, RBAC, Azure storage etc.

In this blog post I am going to walk through the setup of an AKS cluster step by step. This is to serve as a intro to AKS to show how easy it is to get started with Kubernetes in Azure. In a follow up blog post I will dive into AKS more showing how to deploy an instance MySQL and WordPress containers on AKS. Before we get into the setup of AKS there are a few things to note:

  1. With the AKS managed service you only pay for the agent nodes within your AKS cluster. There is no cost for the master nodes and the managed service itself is free.
  2. At the time of this blog post AKS only supports Linux containers. There is a work around for this until Windows nodes and containers come to AKS.
  3. AKS is only available in the following Azure regions:
    -Australia East
    -Canada Central
    -Canada East
    -Central US
    -East US
    -East US2
    -Japan East
    -North Europe
    -Southeast Asia
    -UK South
    -West Europe
    -West US
    -West US 2
  4. The Kubernetes API server is exposed as a public fully qualified domain name (FQDN). Access should be restricted on this. It can be restricted using K8s RBAC and AAD.

Deploy AKS

Housekeeping is done, now let’s get into the deployment of AKS. The first thing you need to do within the Azure portal is go to Create a resource and search on Kubernetes. Select the Kubernetes Service.

Click on create.

You will now see the setup. The setup consists of the following sections shown in the following screenshot:

Let’s walk through each section.

Basics

Here you need to give your AKS instance a name, select the region, K8s version, DNS prefix, and number of nodes and count.

Authentication

Kubernetes has its own RBAC within its authentication and authorization system. Azure Active Directory (AAD) can be integrated with this for authentication. Once the AAD and K8s integration is setup AAD users can be used for Kubernetes role-based access control (RBAC) to cluster resources. Select yes to enable RBAC and integration with AAD.

It is recommended to setup your own service principle in AAD. For this blog post I let the deployment create one. The service principle is used by K8s for managing Azure cloud resources attached to the cluster. The service principle interacts with Azure APIs. For example when you setup a load balancer service in K8s AKS creates and Azure load balancer. The service principle is what is used for authentication to create the load balancer.

Networking

In this section you chose what you want for networking with AKS. If you select basic AKS will create all needed VNets, Subnets, NSG’s etc. AKS clusters cannot use the following ranges 169.254.0.0/16, 172.30.0.0/16, and 172.31.0.0/16. If you select advanced you can chose an existing VNet or create a new one specifying the subnet, IP range and DNS settings etc. You would select Advanced if you need more control over the virtual networking. 

HTTP application routing is used to make application endpoints publicly accessible in the AKS cluster. Enabling this essentially configures an Ingress controller in the AKS cluster. When getting started with AKS I recommend leaving this disabled and doing more research on K8s Ingress Controllers here https://kubernetes.io/docs/concepts/services-networking/ingress as there are other options making applications publicly accessible. In the meantime while getting started with AKS you can use the load balancer service type for external access to your applications running on AKS.

Monitoring

With AKS you have the option to utilize Container monitoring from Azure Monitor. This will give you performance and health monitoring. The monitoring data comes directly from an AKS cluster or from all the AKS clusters via Azure Monitor more specifically Log Analytics. In the future I plan to post a deeper blog about monitoring AKS.

If you chose to enable this you will need to setup a new  Log Analytics workspace or use an existing one.

Tags

You can set tags for the AKS cluster.

Create

After all the sections are completed the new AKS will need to validate. After it is validated click on Create.

Exploring AKS

After the AKS cluster is created you will see it in Azure under Kubernetes services.

Also you may notice two new resource groups in your Azure subscription. The first resource group will be the one you created during the AKS creation. This is the resource group that will contain the Azure K8s cluster service. If you selected an advanced network configuration during deployment to create a new VNet you will see that as well.

You will also see a second resource group with a name format similar to MC_ResourceGroupNAME_AKSClusterNAME_REGION. As shown in the following screenshot I have a resource group named MC_AKS12118RG_AKS12118_centralus. This resource group contains the individual AKS cluster resources such as the nodes.

This resource group also contains supporting Azure services like DNS, public IP’s, storage, load balancers, network security groups and more. Note do not make changes to the resources in this resource group directly. You should only make changes through the AKS service and K8s itself. For example when you deploy a new load balancer service in K8s the corresponding Azure load balancer will automatically be created.

Access Kubernetes Dashboard

Next you can access the K8s cluster via a shell or access the dashboard. Before you can access the dashboard the service principle account that was created during the AKS deployment will need a ClusterRoleBinding that assigns the K8s role dashboard-admin it. Run the following syntax from the Azure cloud shell to do this:

kubectl create clusterrolebinding kubernetes-dashboard -n kube-system --clusterrole=cluster-admin --serviceaccount=kube-system:kubernetes-dashboard

If the service principle account does not have the K8s dashboard-admin role you will see the following error when accessing the dashboard:

After the service principle account is all set go ahead and run the following syntax from Azure cloud shell.

az aks browse --resource-group CLUSTERRESOURCEGROUPNAME --name NAMEOFTHEAKSCLUSTER

Running that syntax will output a URL similar to the one shown in the following screenshot. Click on this and it will open the K8s dashboard in a new browser tab.

The following 3 screenshots show some of the K8s dashboard.

Read More

Multiple Linux VM Deployment ARM Template

I looked for an existing ARM template that would create multiple Linux VM’s. I found only one that creates some in a scale set. The use case I was working with did not call for a scale set so I needed a different template.

I found a simple ARM template for creating multiple Windows VM’s on Azure here. It had exactly what I needed for my use case but did not cover Linux.

I modified the template and uploaded to Github in case this is helpful to anyone else. The repo has two templates. There is one for Ubuntu and one for SUSE. When you deploy the template it will need the following parameters:

The ARM template will create an availability set (AS) with N number of VM’s put in that AS, network interfaces, and public IP’s for each VM along with a VNet and Subnet as shown in the following screenshot:

Here is the link to download the ARM Template:

https://github.com/Buchatech/Multiple-Linux-VM-Deployment-ARM-Template

Read More

WordPress as front-end for Azure Automation

With Azure Automation there are cases where you will need to have a form that end users can go fill out to kick off an automation runbook. Back with System Center Orchestrator we could use Service Manager’s self-service portal as the front end for our automations. This was a solution that worked well. With Azure Automation we do not have that luxury at least not yet we don’t. There is a community based Azure automation webhook Service Manager (SCSM) connector in the works. One of my colleagues Rob Plank is a part of this project and says it should ready to release very soon. This connector will allow you to use the SCSM portal as the frontend of Azure Automation via webhooks, know when a webhook expires, and see a runbooks job status. Here are some teaser screenshots of the  connector.

image001

image002

There also are a few posts out there on how to leverage other platforms as the frontend for Azure Automation these are “how to use SharePoint as the frontend of Azure Automation” by Anders Bengtsson and “how to use an ASP website as the frontend to Azure Automation” by a friend of mine and fellow Microsoft MVP Florent Appointaire. Well in this post I am going to show you how to use the popular platform WordPress as the frontend for Azure Automation. The cool thing here is that this is another instance of showcasing the ability to utilize Microsoft and Open Source technologies together. 🙂

Here are the steps at a high level

  • Have an Azure Automation account on Azure
  • Setup your runbook/s in Azure Automation
  • Setup a webhook on your runbook/s in Azure Automation
  • Have a WordPress instance
  • Install Ninja Forms plugin in the WordPress instance
  • Install the Webhooks add on for Ninja Forms
  • Setup your runbook frontend form/s
  • Configure the runbook frontend form/s to connect to the Azure Automation webhook

Let’s get started!

Step 1: Have an Azure Automation account on Azure

To get started with Azure Automation go here: https://azure.microsoft.com/en-us/documentation/articles/automation-intro. I am not going to cover this within this blog post.

Step 2: Setup your runbook/s in Azure Automation

For this testing this scenario and this post I grabbed a couple of Azure Automation runbooks built by the Microsoft AzureAutomationTeam and made available in the Azure Automation Runbook Gallery. These runbooks start and stop Azure virtual machines.

Runbook #1 Name:

Start-AzureV2VMs

Description:

This runbook connects to Azure and starts all VMs in an Azure subscription or resource group.

Runbook #2 Name:

Stop-AzureV2VMs

Description:

This runbook connects to Azure and stops all VMs in an Azure subscription or resource group.

Both runbooks have two parameters they need. These are:

param (

[Parameter(Mandatory=$false)]

[String]  $AzureConnectionAssetName = “AzureRunAsConnection”,

[Parameter(Mandatory=$false)]

[String] $ResourceGroupName

We need to pay attention to these when setting up the webhooks and these often become your fields on your front end form.

Step 3: Setup a webhook on your runbook/s in Azure Automation

Here are the steps to setup a webhook for an Azure Automation Runbook.

First off make sure your runbook/s are in a published authoring status.

image003

Within https://portal.azure.com Navigate to

YOURAZUREAUTOMATIONACCOUNT

Runbooks

YOURRUNBOOK (Start-AzureV2VMs)

Webhooks

From here click on the Add Webhook button.

image004

The Add Webhook blade will fly out. Here you will want to click on Create new webhook to make the next blade flyout.

Here you need to give your webhook a name, set to enabled, set when it will expire and COPY THE URL TO A SAFE PLACE.

NOTE: You will not be able to access the webhook URL after this.

image005

Click OK.

Next you need to click on Configure parameters and run settings. This is where you set the parameters from the runbook.

If your parameters are required you have to set them here. If they are optional you can leave them blank here and pass the data into the runbook from the frontend form via a $WebhookData object.

In my case I put AzureRunAsConnection directly in the webhook. I created a credentials asset in Azure Automation with the account containing the needed permissions to perform the actions from the runbook in my Azure account (Start/Stop VM’s).

I left the resourcegroupname blank as I will pass this in from the front end form. I left the Run Settings to run on Azure as I do not have a Hybrid Worker setup.

NOTE: A Hybrid Worker lets you run automation runbooks on premises in your data center.

image006

One you have the Webhook and parameters configured click on the Create button to actually create the webhook.

image007

You will now see your new webhook in the webhooks blade.

image008

Note that if you click on a webhook you will not see the URL. You can enable or disable the webhook, see when it expires, and access the parameters. This is shown in the following screenshot.

image009

Step 4: Have a WordPress instance

You can host WordPress on WordPress.org on a hosting account, internally or even on Azure. Here is a link to a tutorial on how to run WordPress on Azure. https://azure.microsoft.com/en-us/documentation/articles/app-service-web-create-web-app-from-marketplace.  I am not going to cover how to setup a WordPress instance within this blog post.

Step 5: Install Ninja Forms plugin in the WordPress instance

Here are the steps to install Ninja Forms WordPress plugin.

From within the WordPress admin dashboard click on Plugins.

Click on Add New.

image010

Search for Ninja Forms. Click on the Install button to add the plugin. Make sure you activate the plugin.

image011

You also could manually download and upload the plugin or load it directly into the plugins directory. I have shown you the steps for the easiest way to install it.

The Ninja Forms plugin page can be found here:

https://wordpress.org/plugins/ninja-forms

Step 6: Install the Webhooks add on for Ninja Forms

The Webhooks for Ninja Forms add on can be found here:

https://ninjaforms.com/webhooks-for-ninja-forms

This add on has to be purchased. It is $39 by itself for 1 WordPress instance.

After you buy it you will get the files for download. Again from within the WordPress admin dashboard click on Plugins.

Click on Add New. This time click on the Upload Plugin button and browse to your downloaded Webhooks for Ninja Forms zip folder.

After it is uploaded be sure to activate it.

The final step is to install the license for the add on. To do this Click on Forms>Settings>Licenses and input the key that Ninja Forms sent in the Webhooks Key field. Click on Save & Activate.

image013

Step 7: Setup your runbook frontend form/s

Next we need to build the actual form. To do this follow the list of steps.

Click on Forms>Add New. Give your form a Title.

Add a Textbox and put in the label of ResourceGroupName.

I like to make it Required.

image014

Add a Submit button to your form. I labeled it Start.

image015

In the following screenshot is what the form looks like. Note that I have both forms loaded on the same page.

image016

Step 8: Configure the runbook frontend form/s to connect to the Azure Automation webhook

Now is the last step. This is the step in which we configure the form to send data to the Auzre Automation webhook upon submission. This is doing it via POST method.

When editing the form click on the Email & Actions tab. Click on the Add New button.

Give this Action a name.

In the Type dropdown select Webhook.

Enter the Azure Automation webhook URL in the Remote Url field.

Select Post for the Remote Method.

For Args select enter the name of and select the field from your form of the parameters you need to send to the Azure Automation runbook.

You can see this all represented in the following screenshot.

image017

One of the cool things about this solution is we can test the webhook action before actually submitting it to make sure it will work as expected. This testing can be turned on by checking the Run in Debug Mode field. I have highlighted this in the screenshot in green. Checking this box and submitting the form will show debugging information like data sent and response.

Here is an example of what the result in Debug mode will look like:

image018

Make sure you uncheck the Run in Debug Mode field when you are ready to actually start your runbook/s.

Now let’s see what this looks like in Azure Automation when we submit the form.

I have a resource group named 6716vm with one VM in it named 6716vm. So I will enter 6716vm on the form. 6716vm will be passed to the runbook as the resourcegroupname.

image019

You can see the job running in Azure now.

image020

Within the job if you click on Input you can see it has 2 inputs. One is Webhookdata. This is where the 6716vm is located. The other is the Azureconnectionassetname. Remember we hardcoded this into the webhook itself. We can also see in the following screenshot that the job completed.

image021

If we look further at the webhookdata we can see several interesting things. We can see exactly where it put the 6716vm parameter for the resourcegroupname and we can see that this request came from my blog at www.buchatech.com.

image022

{“WebhookName”:”WPhook1″,”RequestBody”:”ResourceGroupName=6716vm”,”RequestHeader”:{“Accept”:”*/*”,”Accept-Encoding”:”deflate; q=1.0″,”Host”:”s1events.azure-automation.net”,”User-Agent”:”WordPress/4.5.3; http://www.buchatech.com”,”x-ms-request-id”:”0ae47ca6-46a4-4ba7-902e-6d33840add75“}}

Pretty cool right? Check out the VM now running:

image023

Now to shut it down I can go back to my WordPress and use the Stop Azure VM form. The possibilities here are endless. I know some of you may be thinking this is great but what if I want to control who can login to see this form and will it work with Active Directory. The answer is YES. WordPress has several plugins that integrate with Active Directly and even have SSO. A couple of these are Active Directory/LDAP Login for Intranet sites and Active Directory Integration. 

You can see that WordPress can make a great frontend for your Azure Automation runbooks. That is the end of the post. Happy automating!

Read More