Managing ConnectionStrings and Environment Variables with WordPress on Azure

Library of Congress

One of the cool features of Azure is the ability to have a “deployment slot” for your web app.  Web app content and configurations elements can be swapped between two deployment slots, including the production slot. Deploying your application to a deployment slot has the following benefits:

  • You can validate web app changes in a staging deployment slot before swapping it with the production slot.
  • Deploying a web app to a slot first and swapping it into production ensures that all instances of the slot are warmed up before being swapped into production. This eliminates downtime when you deploy your web app. The traffic redirection is seamless, and no requests are dropped as a result of swap operations. This entire workflow can be automated by configuring Auto Swap when pre-swap validation is not needed.
  • After a swap, the slot with previously staged web app now has the previous production web app. If the changes swapped into the production slot are not as you expected, you can perform the same swap immediately to get your “last known good site” back.

As a web developer, this makes your life easy. Production and Staging can be exactly the same. How many times have you used a staging environment that was a different  OS version than production. “It works on staging but not on production” is the common quote.

When I’m told that my code is broken in production

Setting up deployment slots are pretty straightforward. You can read more about them on this Azure post. However, how do you handle the environment variables for each slot? I need my production code to access my production database.

There are 3 ways that this can be accomplished.

1. The RCP Way

The RCP Way stands for Rename, Copy and Paste. You would rename your connection string or variable file to connstring.stage or connstring.prod and then copy and paste the appropriate values in them. Works fine. However, when deploying from Git or some version tracker can get a bit tricky.

2. The If Then Way

IF “Production” THEN production values ELSE staging values. You can either get the ip address, domain name, server name or even a boolean value that if it signals that you are on production you load in the production values. This works fine but now your one file has 2 or more sets of variables that will need to be maintained.

3. Environment Variables

This is part of Azure which makes deployment slots work so well. I configure my values within Azure per environment. This way my code does nto have to have any usernames or passwords just the variables to store them in.

I am going to show a quick example of how to set up your WordPress Blog using the connection string variables within Azure. This can be applied to any application but I will use WordPress as the default.

Step 1. Create your web app.

I am not going into detail on how to create a wordpress web app but you can follow this tutorial to get that up and running.

Step 2. Find your connection string

This can vary. You might have a Virtual Machine that is custom hosting your database or you might use the default database within Azure. Either way finding your connection string can be done by determining the Username for the DB. the Password for the DB. The data source and DB name. You can also get this info from the wp-config.php file within your root of your WordPress website. You might want to look in there since we will be modding that file in a moment.

Step 3. Build your string

Once you have those 4 parts you can build together your connection string. Your string can look like this.

Step 4. Add your string to the portal

Go into your web app and choose All Settings then Application Settings.

Application Settings

The Application Settings blade will appear. Scroll down a bit until you see the section called “Connection Strings”.

There are 4 form elements that you can configure.

  • Name: This is your name of your connection string. MyClientDB or AnalyticsDB as examples. Whatever you name it, Azure will add a prefix to it that I will explain in a moment.
  • Value: This is your value. You connection string. See step 3.
  • Type: You can choose Custom, SQL Server, SQL DB or MySQL. When you choose any of these Azure appends the following text to the front of your “name”
    • SQL Server: SQLCONNSTR_
    • MySQL: MYSQLCONNSTR_
    • SQL Database: SQLAZURECONNSTR_
    • Custom: CUSTOMCONNSTR_

Note:

For .NET apps, these connection strings are be injected into your .NET configuration connectionStrings settings at runtime, overriding existing entries where the key equals the linked database name.

For PHP, Python, Java and Node applications, these settings will be available as environment variables at runtime, prefixed with the connection type. 

Now if I need to access my MySql connection string called MyClientDB, it would be accessed through the environment variable MYSQLCONNSTR_MyClientDB.

I then can create a deployment slot with the same connection string “name” but different values and my code will use those values to connect to staging or production data.

You can see how this would be valuable when you are moving from dev to test to prod. You can also use App Settings to store “app specific” data in there as well per environment.

Step 5. Update our WordPress

Remember I said we are going to need that wp-config.php, well if it is open great, if not please open it in your favorite code editor, mine is Visual Studio Code, a free download and works great.

The first couple of lines are comments but then there are a few “define” constants that the application will use.

Your file might have actual data in your file but that is fine. We will be replacing that with the values from our environment variable that we just created in Azure. To access it’s data you can call the get_env function to retrieve it.

At this point you have your connection string and you can $echo it out to see what comes back. To make it a bit easier to get each element of the connection string you can add this function to the top of the wp-config.php file.

This is a handy little function that coverts a string into an array with a predefined delimiter.

You can var_dump the returned value to see what is returned.

Then you can replace the 4 defined constants with the following:

Done!

Now you can deploy stage and prod and have your WordPress blog access different databases very easily.

Here is the link to the full file on GitHub

Leave a Comment

(1 Comment)

  • crawford jersey

    Lombardi’s comments on the Richards option in particular are actually worth sizing up. He or she told the particular Los Angeles Times’ Lisa Dillman the middle had to get modifications in our solution he completely ready on the offseason knowning that he’d had positive discussion posts considering the guru on the fact that entrance. In due course, everything you need arrived to a new judgment regarding figure.

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