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

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; https://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

How to add SUSE Linux image to Azure Stack

In Azure Stack you can publish your own images essentially virtual machines that can be used when deploying a new virtual machine. This is handy for publishing servers that need to be pre-configured in a certain way for consumers of your cloud. In order for your published images to show up as an option in compute within Azure Stack the images need to be added to the Platform Image Repository (PIR) within the Compute Resource Provider (CRP).

SUSE has recently published a pre-built SUSE Linux Enterprise Server 12 SP1 image that has been prepped specifically for Azure Stack. This image is ready to go and can be published to the CRP’s PIR without any needed prep of the virtual machine. In this blog post I am going to walk through the steps I took to add this image to my Azure Stack.

SUSE already has an image out there for Azure. The SUSE image used on Azure does not work right now on Azure Stack. As of right now Azure and Azure Stack have different “initialization code”. In the future I would expect these to be the same. The SUSE image also includes SUSE/azurectl a command line tool that helps you manage SUSE updates from a Linux VM hosted on Azure. More info on this here: https://github.com/SUSE/azurectl. To download the SUSE Azure Stack image go to https://download.suse.com and complete the fields as show in the following screenshot.

AS-Suse-1

You will be brought to a login page to access the download. If you do not have a SUSE account sign up for one and login. You will see the actual download at that point. Go ahead and download it onto your Azure Stack Host.

AS-Suse-2

Extract the SLE-12-SP1-Server-Azure-Stack-x86_64.vhd and copy it to C:\ClusterStorage\Volume1\Share\VM.

AS-Suse-3

Microsoft has the steps for adding images to Azure Stack’s Platform Image Repository (PIR). The process is essentially running a PowerShell script. The script is included with Azure Stack. The script creates the image directory needed in C:\ClusterStorage\Volume1\Share\CRP\PlatformImages, the JSON file in that directory, and makes a copy of the VHD in that directory. The JSON file contains the meta data about the image that shows in the Azure Stack Portal. Here is the link to the Microsoft document: https://azure.microsoft.com/en-us/documentation/articles/azure-stack-add-image-pir/

Here are the steps for running the script:

In PowerShell navigate to:

D:\CRP\VM\Microsoft.AzureStack.Compute.Installer\content\Scripts

Run this script in PowerShell:

.\CopyImageToPlatformImageRepository.ps1

NOTE: My DATAIMAGE drive letter was D. You may have a different letter.

You will be prompted for the following:

  • PlatformImageRepositoryPath use this \\SOFS\Share\CRP\PlatformImages\
  • ImagePath I put C:\ClusterStorage\Volume1\Share\VM\SLE-12-SP1-Server-Azure-Stack-x86_64.vhd
  • Publisher I put SUSE
  • Offer I put LinuxServer
  • Sku I put SUSE-Linux-Ent-12-SP1
  • Version I put 12.0.0
  • OsType I put Linux

AS-Suse-4

NOTE: These prompts are used to populate the JSON file for the image. Here is an example of the JSON file:

{

“Publisher”:”SUSE”,

“Offer”:”LinuxServer”,

“Sku”:”SUSE-Linux-Ent-12-SP1″,

“Version”:”12.0.0″,

“PlatformImage” :{

“OsDisk” : {

“OsType”:”Linux”,

“FileName”:”SLE-12-SP1-Server-Azure-Stack-x86_64″

}

}

}

Alternatively you could run the script as:

.\CopyImageToPlatformImageRepository.ps1 -PlatformImageRespositoryPath ‘\\SOFS\Share\CRP\PlatformImages’ -ImagePath ‘C:\ClusterStorage\Volume1\Share\VM\SLE-12-SP1-Server-Azure-Stack-x86_64.vhd’ -Publisher ‘SUSE’ -Offer ‘LinuxServer’ -Sku ‘SUSE-Linux-Ent-12-SP1’ -OsType ‘Linux’

As long as the script worked you should have the following as an end result in C:\ClusterStorage\Volume1\Share\CRP\PlatformImages:

AS-Suse-5

AS-Suse-6

If you have the Azure Stack portal open close out of the browser and go back in. It should be listed as an available image in Compute as shown in the following screenshot.

AS-Suse-7

Notice the difference between a Windows image and a Linux image. The Linux image gives you an authentication option of Password or SSH Key.

Windows Linux
 AS-Suse-8  AS-Suse-9

Read more

CentOS supported on Hyper-V

Microsoft officially supports CentOS on Hyper-V now. This is great news because CentOS is the flavor of Linux i prefer to use. I will go back to running this instead of SUSE on Hyper-V. Here is a great blog post about installing the integration for CentOS running on Hyper-V: http://www.ms4u.info/2011/05/centos-added-as-supported-guest.html Here is a link on … Read more

Remove SIP & Pool Info from AD accounts

I recently moved from OCS 2007 to Lync 2010. We decided to remove the OCS 2007 deployment and start over fresh with Lync as OCS was deployed before our time and did not seem like a clean deployment. When uninstalling we ran into some errors when un-prepping the forest and domain using LCSCmd.exe. We did get OCS uninstalled so we decided to move forward.

I was able to get Lync 2010 deployed just fine. However when I went to add users that existed on the OCS 2007 deployment to the new Lync 2010 pool and Lync would not let me add them

Lync gave an error message of “Filter failed to return unique result, “[SipAddress: sip: user@domain.com]” due to their Active Directory accounts having the old SIP address and pool information on them.

image

What I did to fix this is removed the old pool and SIP address from the accounts of the users in Active Directory. Here are the steps:

Read more

Tether Android without root access

I found this app on the Android Market called Easytether. It shares your Android phone Internet connection with your laptop or PC. This app does not require root access and it is supported on Windows XP/Vista/7 , MAC and Linux. There are two versions of this app the Lite version and the paid version. There … Read more