If you’ve been following this series, you know that I am trying to keep these posts short and to the point. I apologize in advance for the length of this post. Part 1 of this series focused on defining the requirements and selecting a Content Management System (CMS) platform, while Part 2 of this series came up with the initial decision for a platform: Deploy this in Azure using Azure’s Platform as a Service capabilities to remove servers (and their potential outages or compromises) from the risk equation when deploying WordPress on the Internet.

First, I’m going to make an assumption; I’m going to assume that if you are reading about how to deploy WordPress on Azure, you already have an Azure Subscription. If you don’t… Well, here’s the link to create one. It’ll give you $200 in free credit for the first month, as well as some popular services for free.

Now, down to brass tacks. You have an Azure subscription with some credit that’s burning the proverbial hole in your wallet? Let’s figure out a way to spend it. Do that by first logging in to Azure. There are three ways I connect to Azure: using the Azure Portal, using Visual Studio Code, and using a Shell.

Method 1: The Azure Portal

The easiest way to connect to Azure is using the Azure Portal. It’s available at https://portal.azure.com. It’s the GUI, and what most people start working with when they think of Azure. When you click on that link, you should be redirected to a login screen similar to this image:

Azure Portal Login Screen (User)

After entering your e-mail you used to create your Azure Subscription from above, you’ll get prompted for a password. (*NOTE: Stratum has customized the Azure Portal login page, which may be different depending upon your login credentials.)

After you enter your password and click “Sign in”, you should be ready to go. The portal page looks something like the following:

Azure Portal – Successful Login

That’s it. You’re logged in and ready to start on building the application scaffolding for your blog site. The next post in this series will cover what scaffolding is required, and how you can go about creating them.

Or… you can read on, and learn about two OTHER ways to connect to Azure.

Method 2: Visual Studio Code

As I’ve written previously, I’m a “Server Bubba”. Technically, I think I’m more of an “Infrastructure Bubba”, as I like networks, firewalls, and load balancers as much as my beloved servers… You can imagine my disdain for Microsoft when they decided to provide developers a mechanism to connect and edit production-level applications AND infrastructure in a Development IDE.

Then I started using Visual Studio Code. And I now understand why Microsoft made it so easy for developers. Push-button deployments, integration with source code management, and visibility into some of the inner workings of Azure are just some great things to experience with VS Code. It’s nicely integrated using the Azure Account Extension, the Azure Resource Manager Tools Extension and the Azure App Service Extension, which make it possible to connect, manage, and deploy our simple little WordPress installation to the Azure App Service Platform. In fact, I might just install every extension here.

VS Code has some other extensions that make this tool even more valuable when thinking about deploying a WordPress site:

  • PHP Extension to edit the WordPress source files
  • MySQL Extension to manage MySQL

Soooo, how do we connect using VS Code? It’s about seven steps, and only because I make it harder than it really needs to be:

StepActivity
Install VS Code1. Install Visual Studio Code. It’s available here.
Launch Extensions Marketplace2. Open Visual Studio Code and open the Extensions Marketplace using the keys ctrl + shift + x
Install Azure Account Extension3. Search for Azure Account extension and select install.
Reload VS Code4. Once the extension has been installed, restart VS Code.
Open Command Palette5. Open the command palette by using the key combination ctrl + shift + p
Sign in to Azure6. In the command palette, type:Azure: Sign In
Enter Credentials7. Enter your credentials in the browser window

Still not nerdy enough for you? Well, how about doing this only via the command line? It’s actually my preferred way.

Method 3: Using a Service Principal

Many people will say that this isn’t really authenticating to Azure as you, but I disagree. In every organization I’ve ever worked in, people responsible for infrastructure management and deployment have what are affectionately called “admin accounts”. They are user accounts with admin privileges in one way, shape, or form that allow the person to assume the role they need. I, on the other hand, want to only manage one set of credentials. I’d rather have a deployment engine (which *I HOPE* becomes another series at some point) be responsible for the deployment.

In the meantime, I created myself a Service Principal. (There is a really great tutorial here.) I created one so that my user only has read-only on Azure Subscriptions, but I can create/update/delete using my SP.

Then, when logging in using PowerShell, I only need login while defining my Service Principal and Service Principal key. (Author’s note: you’ll see this referenced many different ways, including: Client ID Key, Password, or Secret just to name a few.)

So, what does this look like? The code is actually quite simple. (Author’s note: Many people try to do this in a single line; I am not one of those people. I see code I write a lot, or things that may happen several times in a script, and create functions. The snippet below is one of these.)

#########################################
#    Function Block
#########################################

function New-AzSPCreds {

  Param (
      [parameter(mandatory=$true)][string]$sp,
      [parameter(mandatory=$true)][string]$sppw
  )
  $secpasswd = ConvertTo-SecureString $sppw -AsPlainText -Force
  $creds = New-Object System.Management.Automation.PSCredential ($sp, $secpasswd)

  return $creds
}

function New-AzConnection {
  Param (
      [parameter(mandatory=$true)][string]$tenantID,
      [parameter(mandatory=$true)][string]$SubID,
      [parameter(mandatory=$true)][string]$SP,
      [parameter(mandatory=$true)][string]$SPPW,
  )
    try {
         $creds = New-AzSPCreds -sp $SP -sppw $SPPW
         connect-azaccount -ServicePrincipal -credential $creds -tenant $tenantID -Subscription $SubID
    }
    catch{
      write-host "Error Authenticating."
    }
}

Now, in any script you want to authenticate, you can just use the functions above to authenticate using any Service Principal by passing the appending the following line to the end:
New-AzConnection -tenantID <your_tenant_id_here> -SubID <your_sub_ID_here> -SP <your_SP_here> -SPPW <your_sppw_here>

Author’s Note: I should add that there are other command-line tools to do this, from Python to Bash Scripts, to Windows Command Line Interface. I’m using PowerShell with the latest version (as of this writing) of the Az PowerShell module.

Summary

If you’ve hit this point, you’ve now seen three different ways to authenticate to Azure. In Part 4 of this series, we’re going to begin building the scaffolding for this app. In other words, now is when we start building out the resources necessary to deploy our app.

Architecture for Amateurs Part 3: Connecting to Azure

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.