DEV Community: Mike Brooks

CI/CD for WordPress on Azure with GitHub Actions

Mike Brooks — Thu, 21 Apr 2022 12:33:41 +0000

Running WordPress on Azure recently got a whole lot better. In February '22 Microsoft announced The new and better ‘WordPress on App Service’ with maintenance and performance enhancements and a streamlined deployment process.

I'm not going to pontificate about the many benefits of WordPress hosting on Azure suffice to say SLA, Scale and Security. My aim for this post is to address one concern: how to deploy custom code to your WordPress site running in Azure App Service.

By custom code, I am referring to plugins and themes. If you want to hack WordPress core, you're on your own 😁

Assumptions

Your code is in a GitHub repository
You will use the FTPS credentials of your web app. There is a dev.to article for that: Connect to Azure WordPress App via FTP
You'll use GitHub Actions for Continuous Integration / Continuous Deployment (CI/CD) to deploy code updates to your WordPress site.

Some Background

WordPress on App Service installs with an Application setting WEBSITES_ENABLE_APP_SERVICE_STORAGE set to true. This enables persistent storage for your site in an Azure Storage mount having the path /home OR ~/. Off of this path is the WordPress code (among other stuff like log files and backups).

As of April 13, 2022, the WordPress source code maintained by Microsoft includes three plugins in the path ~/site/wwwroot/wp-content/plugins. When you install a plugin via the wp-admin UI, this is the path into which they are installed. Themes follow the same pattern.

CI/CD For Custom Plugin and Theme Code

Needless to say, for custom code you'll want to have source code version control and an efficient deployment workflow. This is accomplished with GitHub repositories and GitHub Actions.

For the sake of example, my custom code is a fork of the public repository tommcfarlin/wp-hello-world.

To our custom code we'll add a directory for our GitHub Action, .github\workflows.

For our GitHub Action we'll use the FTP Deploy action available in the GitHub Marketplace.

In our .github\workflows directory we'll add a main.yml file into which we'll insert the following code:

on: push
name: 🚀 Deploy website on push
jobs:
  web-deploy:
    name: 🎉 Deploy
    runs-on: ubuntu-latest
    steps:
    - name: 🚚 Get latest code
      uses: actions/checkout@v2

    - name: 📂 Sync files
      uses: SamKirkland/FTP-Deploy-Action@4.3.0
      with:
        server: <mysite>.ftp.azurewebsites.windows.net
        username: ${{ secrets.WP_USER }}
        password: ${{ secrets.WP_PASSWORD }}
        protocol: ftps        
        server-dir: /site/wwwroot/wp-content/plugins/wp-hello-world/
        # dry-run: true

For this to work for your site, you need to:

Add Actions secrets for the FTPS credentials. In our example the secret names are WP_USER and WP_PASSWORD.
For the server: value replace the <mysite> placeholder with the unique FTPS endpoint prefix of your site.

Tips

Note the # dry-run: true attribute at the end of the action code. I recommend this for your initial testing of the GitHub Action.
Refer to the FTP Deploy documentation for other settings you can employ for your GitHub Action.

Going Deeper

CI/CD really shines when you have staged deployments. With Azure Web Apps you can have deployment slots for pre-production environments such as Dev, Stage, and QA. Each has its own FTPS Endpoint allowing you to leverage GitHub Actions for each stage of your code life-cycle.

In Closing

Thanks for reading this post. I hope you found it helpful. Feel free to share your feedback and suggestions for other readers.

Resources

Custom App Logging with Azure Monitor for Containers

Mike Brooks — Tue, 23 Jun 2020 20:47:03 +0000

Introduction
- Our Scenario
- Objective
- Solution
Implementation
- Prerequisites
- Step 1 - Invoking syslog in a PHP application
- Step 2 - Dockerfile configurations
- Step 3 - Docker CLI commands
- Step 4 - Deploy to AKS
In Closing
Resources
Acknowledgements

Introduction

If you use Azure, you probably spend time in Azure Monitor - Azure's comprehensive solution for collecting, analyzing, and acting on telemetry from your cloud and on-premises environments.

And, if you happen to run containerized workloads in Azure - say with Azure Kubernetes Service (AKS) or Azure Container instances (ACI) - you may already be tapping into Azure Monitor for containers. If you are new to this feature, in short...

Azure Monitor for containers gives you performance visibility by collecting memory and processor metrics from controllers, nodes, and containers that are available in Kubernetes through the Metrics API. Container logs are also collected.

For emphasis, I'll now repeat that last sentence...

Container logs are also collected.

Azure Monitor for containers collects stdout and stderr from container workloads deployed to AKS (or ACI).

Knowing this, all one needs to do is route custom application logs to stderr (or stdout) to take advantage of Azure Monitor for containers.

In this post, I will walk you through an example implementation using a simple php application and Rsyslog, the rocket-fast system for log processing.

Our Scenario

We have a containerized PHP application running in Azure Kubernetes Service (AKS). In our application, we leverage the syslog php function to generate custom log messages, which in turn are consumed by a user defined log handler.

Objective

Collect the log messages in Azure Monitor for containers for real-time observation and analysis in a Log Analytics workspace.

Below are screen captures from Azure Portal that show the expected custom log output in:

The Live Data (preview) feature (Figure 1)
A Log Analytics workspace (Figure 2)
The Logs displayed for our container running in Azure Container Instances (Figure 3)

Figure 1

Figure 2

Figure 3

Solution

In our container image we install the rsyslog library; configure a user defined syslog log handler; and route the messages to stderr.

Syslog recognizes the following severity levels for log messages:

Numerical Code	Severity	Description
0	emerg	system is unusable
1	alert	action must be taken immediately
2	crit	critical conditions
3	error	error conditions
4	warning	warning conditions
5	notice	normal but significant condition
6	info	informational messages
7	debug	debug-level messages

In our example implementation, we will evaluate for two severity levels: error (3) and info (6).

The implementation steps below are taken from this GitHub repo to which I contributed

snp-technologies / AKS-Custom-App-Log-Demo

Implementation

Prerequisites

This article assumes experience with Docker containers, Kubernetes and Azure. This article does not describe the steps to install an AKS cluster. Links to a Quickstart tutorial is provided in Resources.

This article uses a simple PHP application for the implementation. If you're not a PHP programmer, don't despair - the principals covered here are generally applicable to other languages.

Please note that our image operating system is from the image debian:stretch-slim.

Step 1 - Invoking syslog in a PHP application

The following code example is a simple, single page application I spun up for a "custom application logging with syslog demo". For the demo,
query strings are used to trigger the log handler, such as:

?value=0 // Triggers an Error log as a result of division by zero.
?value=2 // Triggers an Information log.

The application code:

<?php
echo '<H1>Syslog Demo</H1>';

// Fetch the URL query string and assign to a variable. 
$qstring = $_SERVER['QUERY_STRING'];

parse_str($qstring, $output);

$value = $output['value'];

// For an error evaluation, we divide 1 by $value.
// A value of 0 will throw a division by zero error.
function inverse($x) {
    if (!$x) {
        throw new Exception('Division by zero.');
    }
    return 1/$x;
}

// Get formatted datetime to include in messages.
$access = date("Y/m/d H:i:s");

try {
    echo "<p>Inverse of value " , $value , " is " , inverse($value) , "</p>";
    $message = "Inverse of value succeeded";
    $severity = LOG_INFO;
    $logtext = "INFORMATION: at " . $access . "\n" . $message . "\n" . $_SERVER['REMOTE_ADDR'];
    _log($severity, $logtext);

} catch (Exception $e) {
    $message = $e->getMessage();
    echo '<p>Caught exception: ',  $message, "</p>";
    $severity = LOG_ERR;
    $logtext = "ERROR: at " . $access . "\n" . $message . "\n" . $_SERVER['REMOTE_ADDR'];
    _log($severity, $logtext);
}

// Open and close connection of system logger.
function _log($priority, $text) {
  openlog("myApp", LOG_PID | LOG_PERROR, LOG_LOCAL0);  
  syslog($priority, $text);
  closelog();
}

?>

Step 2 - Dockerfile configurations

To enable syslog support in our container image, we install the rsyslog library:

RUN apt-get update; \
    apt-get install -y --no-install-recommends \
    rsyslog \
    ;

Later in our Dockerfile, we configure a custom log handler for our application logs:

RUN echo "local0.* /var/log/apache2/myapp.log" >> /etc/rsyslog.conf

We then configure the log to go to stderr using a symlink, and we re-set ownership of the /var/log/apache2/ just as first set in our base image php:7.3-apache-stretch:

RUN \ 
  ln -sfT /dev/stderr "/var/log/apache2/myapp.log"; \
  chown -R --no-dereference "www-data:www-data" "/var/log/apache2/"

Step 3 - Docker CLI commands

Build a container image:

docker build -t applogdemo .

Test it locally:

docker run --name applogdemo --rm -i -t applogdemo

The log output local test results should look similar to:

[ ok ] Starting enhanced syslogd: rsyslogd.
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.2. Set the 'ServerName' directive globally to suppress this message
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.2. Set the 'ServerName' directive globally to suppress this message
[Sat Jun 20 20:34:48.662731 2020] [mpm_prefork:notice] [pid 40] AH00163: Apache/2.4.25 (Debian) PHP/7.3.13 configured -- resuming normal operations
[Sat Jun 20 20:34:48.662809 2020] [core:notice] [pid 40] AH00094: Command line: '/usr/sbin/apache2 -D FOREGROUND'

While the container is running, in your browser enter some URL's to invoke the log handler, such as:
http://localhost/?value=0, http://localhost/?value=2, etc.

You should see additional log output similar to:

myApp[41]: ERROR: at 2020/06/29 14:18:15
myApp[41]: Division by zero.
myApp[41]: 172.17.0.1
172.17.0.2:80 172.17.0.1 - - [29/Jun/2020:14:18:15 +0000] "GET /?value=0 HTTP/1.1" 200 366 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:7
7.0) Gecko/20100101 Firefox/77.0"
"-" - - [29/Jun/2020:14:18:15 +0000] "GET /?value=0 HTTP/1.1" 200 366 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 F
irefox/77.0"
myApp[42]: INFORMATION: at 2020/06/29 14:18:30
myApp[42]: Inverse of value succeeded
myApp[42]: 172.17.0.1
172.17.0.2:80 172.17.0.1 - - [29/Jun/2020:14:18:30 +0000] "GET /?value=4 HTTP/1.1" 200 268 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:7
7.0) Gecko/20100101 Firefox/77.0"
"-" - - [29/Jun/2020:14:18:30 +0000] "GET /?value=4 HTTP/1.1" 200 268 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0"

Now that we have validated the application locally, let's prep the image for publishing to our preferred container registry, Azure Container Registry (Docker Hub or other registry is fine). Let's tag the image:

docker tag applogdemo myacr.azurecr.io/applogdemo:v1

Let's push to our preferred container registry.

docker push myacr.azurecr.io/applogdemo:v1

Step 4 - Deploy to AKS

To deploy the container, we use the following Kubernetes YAML manifest.

Note the inclusion of a Service resource.

If you are interested in deploying to Azure Container Instances, please refer to the Quickstart tutorial link provided in Resources.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: applogdemo
  labels:
    app: applogdemo
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: applogdemo
  template:
    metadata:
      labels:
        app: applogdemo
    spec:
      containers:
        - image: myacr.azurecr.io/applogdemo:v1 // Placeholder
          name: applogdemo
          ports:
          - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: applogdemo-service
  namespace: default
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
  selector:
    app: applogdemo
  type: LoadBalancer

Customize the image: value in the containers: spec if the deployment.yml manifest, e.g.

containers:
    -
        image: myacr.azurecr.io/applogdemo:v1

Finally, deploy the kubernetes manifests using the commands:

   kubectl apply -f manifests/deployment.yml

Step 5 - Validate the deployment

Validate the deployment by accessing the website via the IP Address exposed by the Kubernetes LoadBalancer service. To identify the IP Address, use the command:

$ kubectl get svc drupal-service
NAME             TYPE           CLUSTER-IP   EXTERNAL-IP      PORT(S)        AGE
drupal-service   LoadBalancer   10.2.0.50    52.151.xxx.xxx   80:32758/TCP   10d

Test the application just as done for local testing.
Once you have called a sequence of URL's with the ?value=<some integer> query string go to the Azure Monitor for containers blade in Azure Portal to view your custom application logs.

In Closing

In this article we have covered the basic configurations necessary to enable custom application logging for Azure Monitor for containers.

From a log analysis standpoint, we've only scratched the surface in this post. Explore the Kusto query language to craft a wide variety of reports. Create alerts based on log metrics. Pin and share custom log dashboards.

Please feel free to share your questions and comments in the discussion below. Thanks - Mike 😃

📚 Resources

👏 Acknowledgements

I would like to thank Firoz Shaik for his review of this post and insightful recommendations.

Drupal File Persistence in Azure Kubernetes Service (AKS)

Mike Brooks — Fri, 05 Jun 2020 12:32:27 +0000

Introduction
Drupal file persistence use cases
Prerequisites
Configuration steps
- Step 1 - Dockerfile commands
- Step 2 - PersistentVolume and PersistentVolumeClaim resources
- Step 3 - Add volumes & volumeMounts fields to the K8s Deployment
In Closing
Resources
Acknowledgements
Addendum

Introduction

As we know, websites are a composite of structured and unstructured data. Text on the webpage may be hard-coded or dynamically aggregated from a database into an HTML file. Image files such as a jpg in-line with page text are independently requested from a file storage location.

Content management system (CMS) frameworks such as Drupal and WordPress expect to read and write unstructured data files to a directory path, typically on the web server. In the case of Drupal, this file storage location is the /sites/default/files/ directory. For WordPress, it is the wp-content/uploads/ directory.

Containerized applications that read and write unstructured data require an external file store resource that persists the files outside the container. This is because containers, by their nature, are ephemeral. Should the container restart or be updated with a new version, then "zap" ⚡ state written to the running container is gone. The container solution for file persistence is to mount storage to the machine (VM or bare metal) that hosts the container.

In the case of Kubernetes, our containers run in so-called "pods" which can horizontally scale across a cluster of VM nodes. As such, a "read write many" solution is necessary so that all pods have access to a common file share not pinned to a single node in the cluster.

In this article we cover a technique to achieve such file persistence in the context of Drupal running in Microsoft's managed service for Kubernetes, Azure Kubernetes Service (or AKS for short).

While our example uses Drupal, the principals are common to other CMS frameworks based on PHP, such as WordPress and Joomla. With some refactoring, the techniques used in this solution can be applied to other CMS frameworks.

Drupal file persistence use cases

This tutorial considers three Drupal uses cases for file persistence:

Drupal file system for a single-site Drupal instance
Drupal watchdog log, as well as logs for PHP errors and Apache access
Drupal administration files such as a hash_salt for one-time login links, cancel links, form tokens, etc.

Prerequisites

Despite the rudiments covered in the introduction above, this article assumes experience with Drupal, Docker containers, Kubernetes and Azure.

This article does not describe all of the prerequisites to run Drupal on AKS. For a more comprehensive view, visit this GitHub repository to which I contributed:

snp-technologies / Azure-Kubernetes-Service-Drupal8

The method described here uses Azure Files, a managed file storage solution from Microsoft. A static Azure Storage account and File shares are necessary. You can create these from the Azure Portal by following the steps in Quickstart: Create and manage Azure file shares with the Azure portal. As in the Quickstart, for non-production scenarios I recommend the StandardV2 account kind with Locally-redundant storage (LRS) replication. In this tutorial we'll create three files shares corresponding to the aforementioned use cases:

files
apache2logs
configs

In Azure Storage Explorer, the resulting Azure Storage account and File shares should look like this:

Alternatively, you can Create an Azure file share using the Azure CLI.

Configuration steps

Step 1 - Dockerfile commands

In the Dockerfile you use to build your container image, include commands to define the directory paths which we will later assign to volumeMounts in our Kubernetes deployment manifest. Let's consider the Dockerfile commands for each File share:

files

RUN mkdir -p /var/www/html/docroot/sites/default/files

This command assumes that our website DocumentRoot is set to /var/www/html/docroot. This can be done in a apache2.conf file have the line:
DocumentRoot /var/www/html/docroot

apache2logs

In our example Dockerfile we use this base image:
FROM php:7.3-apache-stretch

We are going to use the default location for Apache logs /var/log/apache2/, and also use this directory for PHP and Drupal logs.

For the PHP log we include the following command:

RUN { \
  echo 'error_log=/var/log/apache2/php-error.log'; \
  echo 'log_errors=On'; \
  echo 'display_errors=Off'; \
  } >> /usr/local/etc/php/php.ini

For the Drupal watchdog log we include the following command:

RUN echo "local0.* /var/log/apache2/drupal.log" >> /etc/rsyslog.conf

This command assumes a local installation of Rsyslog in our container.

configs

RUN mkdir -p /var/www/html/config

Step 2 - PersistentVolume and PersistentVolumeClaim resources

In this step we compose a Kubernetes manifest with instructions to define
PersistentVolume and PersistentVolumeClaim resources in our AKS cluster.

Before we do that, however, we need to create a Kubernetes secret to hold the credentials to access our Azure Storage account. The secret manifest YAML is as follows:

apiVersion: v1
kind: Secret
metadata:
  name: sa-secrets
type: Opaque
data:
  azurestorageaccountkey: <BASE_64_ENCODED_STORAGE_ACCOUNT_KEY>
  azurestorageaccountname: <BASE_64_ENCODED_STORAGE_ACCOUNT_NAME>

This Secret resource will be referenced by our PersistentVolume resource.

You can find the Azure Storage credentials in the Access keys setting in Azure portal, for example:

To output base64 encoded strings for use in your secrets manifest, use the command:
echo -n "<string to encode>" | base64 -w 0

OK. Now that we've gotten that out of the way, we can turn our attention back to our PersistentVolume and PersistentVolumeClaim resources. The YAML example below illustrates the creation of a PersistentVolume and a PersistentVolumeClaim to be used for our public file system path.

Please note...

Our use of the azurefile storageClassName in the PersistentVolume spec. This StorageClass as well as azurefile-premium are Kubernetes resources provided out-of-the-box in AKS.
In the mountOptions we set the file share access control. uid=1000 refers to user d8admin added in our Dockerfile and uid=33 refers to the group which happens to be www-data provided by the container's base image (see the Addendum for a how-to).

apiVersion: v1
kind: PersistentVolume
metadata:
  name: filespv
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: azurefile
  capacity:
    storage: 5Gi
  azureFile:
    secretName: sa-secrets
    shareName: files
    readOnly: false
  claimRef:
    namespace: default
    name: filespvc
  mountOptions:
  - dir_mode=0777
  - file_mode=0777
  - uid=1000
  - gid=33
  - mfsymlinks
  - nobrl

---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: filespvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: azurefile
  resources:
    requests:
      storage: 5Gi

Similarly, PersistentVolume and PersistentVolumeClaim resources can be created for the apache2logs and configs File shares.

Step 3 - Add volumes & volumeMounts fields to the K8s Deployment

The final step to ensure file persistance is to make our Drupal pod(s) aware of the Azure Files' persistent volume claims, and associate each claim with a path in our container.

In our Kubernetes deployment YAML manifest we add .spec.containers.volumeMounts and .spec.volumes fields.

For example:

 spec:
      containers:
        - image: <registry>/<image-name>:<tag>
          name: drupal
          ports:
          - containerPort: 80
          volumeMounts:
          - mountPath: /var/log/apache2
            name: apache2-vol
          - mountPath: /var/www/html/docroot/sites/default/files
            name: files-vol
          - mountPath: /var/www/html/config
            name: config-vol
volumes:
        - name: config-vol
          persistentVolumeClaim:
            claimName: configpvc
        - name: files-vol
          persistentVolumeClaim:
            claimName: filespvc
        - name: apache2-vol
          persistentVolumeClaim:
            claimName: apache2pvc

A complete deployment example can be found in the aforementioned GitHub repo.

In Closing

In this article we have covered the basic configurations necessary to enable file persistent for a Drupal deployment in Azure Kubernetes Service.

Drupal containerization and Kubernetes orchestration are a craft and there are many opinions on how to do it. The technique described here is one of many options for file persistence. I encourage you to explore the storage options to determine what is best your use case, whether it is Azure Files, an NFS server, GlusterFS, or even a storage abstraction layer such as Rook or Portworx.

Please feel free to share your questions and comments in the discussion below. Thanks - Mike 😃

📚 Resources

👏 Acknowledgements

I would like to thank Gousiya Sayyad for her technical know-how and review of this post.

Addendum

To get the uid and gid values for my mountOptions properties, I bash into my container running locally, for example:

SNP+mike@MIKE-T570 MINGW64 ~
$ winpty docker exec -it drupal8aks bash
root@6cc24a823fb3:/var/www/html# id -u d8admin
1000
root@6cc24a823fb3:/var/www/html# id -g www-data
33

DEV Community: Mike Brooks

CI/CD for WordPress on Azure with GitHub Actions

Assumptions

Some Background

CI/CD For Custom Plugin and Theme Code

Tips

Going Deeper

In Closing

Resources

Custom App Logging with Azure Monitor for Containers

Table of Contents

Introduction

Our Scenario

Objective

Solution

snp-technologies / AKS-Custom-App-Log-Demo

Implementation

Prerequisites

Step 1 - Invoking syslog in a PHP application

Step 2 - Dockerfile configurations

Step 3 - Docker CLI commands

Step 4 - Deploy to AKS

Step 5 - Validate the deployment

In Closing

📚 Resources

👏 Acknowledgements

Drupal File Persistence in Azure Kubernetes Service (AKS)

Table of Contents

Introduction

Drupal file persistence use cases

Prerequisites

snp-technologies / Azure-Kubernetes-Service-Drupal8

Configuration steps

Step 1 - Dockerfile commands

files

apache2logs

configs

Step 2 - PersistentVolume and PersistentVolumeClaim resources

Step 3 - Add volumes & volumeMounts fields to the K8s Deployment

In Closing

📚 Resources

👏 Acknowledgements

Addendum