Database connection error using MySql in Azure App Service

Well, if you’ve gone full speed ahead using the preview of MySql in Azure App Service you’ve noticed that it doesn’t work. WordPress gives you the “Error connecting to database” error.

To fix it you’ll need to add some application settings on your application.

Key: WEBSITE_MYSQL_ARGUMENTS
Value: –default_password_lifetime=0

Click “Save” and you’re all done.

website_password

What is Azure Resource Manager anyway?

When we talk about Azure there’s always a lot of mentioning of “ARM” or “Classic”. “Oh, are you running in classic mode? You should migrate it to ARM instead”. If you have no idea what ARM is or what it can do for you, you usually just nod your head and your life continues anyway. But not knowing about ARM in the year 2016 could be bad. It makes your life easier! It makes your resources more secure! You can decide who can deploy what! Michael Jackson did a song called “Bad“! (Oh, sorry about that, couldn’t help myself.)

Azure Service Manager

The OLD way of deploying resources to Azure is usually referred to as “Classic”, the more technical name is “Azure Service Manager” or ASM for short. In ASM when you deployed for example a virtual machine it looked like this:

Azure Service Manager VM deployment
Azure Service Manager VM deployment

This deployment had a mandatory “Cloud Service” acting as a container for the VM. It could also have an external IP address with a load balancer. When running in ASM-mode you needed to add your co-workers as co-admins on your subscription. This gave them the same rights as the owner except removing the above mentioned owner of course. But they could effectively add / delete any kind of resources in the subscription. Sounds dangerous, right? Well, ARM to the rescue!

Azure Resource Manager

Azure Resource Manager, ARM, brings the power of resource providers. They do just that, provide resources. There are a bunch of different ones and you can list them and see their status for your subscription using PowerShell.

Registered providers in a subscription.
Registered providers in a subscription.

Of course you could unregister providers if you don’t want to be able to deploy resources from a specific provider. This effectively lets the subscription owner make sure that only allowed resource types are deployed. In the same fashion you can register providers if you want to deploy resources.

Terminology

There are a bunch of different terms to keep track of to follow this discussion.

We have:

  1. Resource – This could be a VM, nic, vnet, public ip or another entity. A resource group can only be a member of one resource group. One.
  2. Resource group – A resource group is a container of resources. This could be resources of the same type or different types. They could belong to the same application, or not.
  3. Resource provider – The resource provider provides resources of a specified type. For example “Microsoft.Compute” provides computing resources and “Microsoft.Network” provides, you guessed it, networking resources.

The picture below show one resource group with different resources in the same resource group. This could be a web app for example, letting the developer deploy the application as one entity.

OR

You could have the resources in different resource groups. For example if you have DBA:s managing your databases, the Windows or Linux-admins manage your virtual machines and your storage guys or gals manage storage.

Resource group with app or resources.
Resource group with app or resources.

How you decide to group your resources is totally up to you. When deciding you also must take into account if you’re going to have one or multiple subscriptions, and if you’re going to use Role Based Access Control (RBAC) to secure access to your resources or resource groups.

You can find more information about ARM at https://azure.microsoft.com/en-us/documentation/articles/resource-group-overview/

Role Based Access Control (RBAC)

Another benefit of using ARM is that is supports RBAC right out of the box. This means that you can apply different roles on resources or resource groups, effectively managing who can do what to your resources. For example you could have one resource group containing virtual machines, where only a specific group of users would be able to delete these for example. Or imagine a web app where a defined set of developers would be able to deploy code to your application but not edit any other settings.

RBAC - assigning users or groups to different roles.
RBAC – assigning users or groups to different roles.

More reading on the subject of RBAC can be found at https://azure.microsoft.com/en-us/documentation/articles/role-based-access-control-configure/ or https://azure.microsoft.com/en-us/documentation/articles/role-based-access-control-what-is/.

Conclusion (or executive summary)

Azure Resource Manager lets you create resources from different providers. Grouping these into resource groups will let you see the cost per group on your bill. You can also assign different roles to either single resources or to all resources in a resource group. If you would like to you can also assign different policies to different resource types, effectively blocking who can do what to which resource. The resources come from resource providers, these can be registered/unregistered which will remove the ability to create any kind of resource from that specific provider.