Connecting an App to an Azure Database - Authorization

This chapter will take you through the process of connecting to an Azure Database. A connection to one or multiple databases can build the backbone for almost every commercial application. Therefore, we will discuss the benefits of using a hosted database versus running StatefulSets on Kubernetes itself. In addition, we will show you aspects of security, backup, disaster recovery (DR), authorization, and audit logging. The independent scaling of the database and the cluster will also be explored. We will break down the discussion of this chapter into the following topics:

• Extending an app to connect to an Azure Database
• Restoring from backup
• Reviewing audit logs
• DR options

Technical requirements

You will require the following tools for this chapter:

• A modern web browser such as Chrome, Firefox, or Edge
• The role-based access control (RBAC)-enabled cluster that was deployed in the last chapter and that is still running

Extending an app to connect to an Azure Database

All the examples that we have gone through so far have been self-contained; that is, everything ran inside the Kubernetes cluster. While there is a great advantage to being mostly cloud-agnostic, this is a huge disadvantage when it comes to managing state. Almost any production application has state and is generally stored in a database. In this section, we will launch the WordPress application, but this time we will use an external database managed by Azure.

WordPress backed by Azure MySQL

As with most applications these days, much of the hard work has already been done by the open source community (including those who work for Microsoft). Microsoft has realized that many users...

Restoring from backup

When you run a database within your Kubernetes cluster, high availability (HA), backup, and DR are your responsibilities. Setting up cron jobs to take backups and store them separately, and also ensuring that the instance is up and running, makes this a complicated operation. As a developer or an operator, running MySQL in production will not be your core competency and it is also unlikely to be for your company. Just as we don't manage our own Kubernetes cluster (we use the managed Kubernetes service), for production, we recommend that you keep life simple by using the managed option.

You can refer to https://docs.microsoft.com/en-us/azure/mysql/concepts-backup to find up-to-date information on the backup frequency, replication, and restore options.

Performing...

Reviewing audit logs

When you run the database on the Kubernetes cluster, it is very difficult to get audit logs should something goes wrong. You need a robust way of dynamically setting the audit level depending on the scenario. You also have to ensure that the logs are shipped outside the cluster. Unless you have RBAC enabled, and that the RBAC logs are correlated, it is difficult to determine whether anyone has made changes to the database server settings.

A managed Azure Database solves the preceding issues by providing a robust auditing mechanism via the Azure Portal.

Azure Database audits

A very powerful tool for troubleshooting is the Azure Database audit logs. You can review the basic logs by looking at the Activity...

DR options

Depending on your Service Level Agreement (SLA) and DR needs, you can add replicas to your MySQL server, as shown in the following screenshot:

A full list of backup, restore, and replication options are documented at https://docs.microsoft.com/en-us/azure/mysql/concepts-backup and https://docs.microsoft.com/en-us/azure/mysql/concepts-read-replicas.

Azure SQL HADR options

Naturally, the options are much better when you use Azure SQL Database than with MySQL. Brief highlights of all the options are listed and users are encouraged to choose their database server based on their own needs. You can create a test database to see the options yourself, as shown in the following screenshot:

The advanced options are shown...

Summary

This chapter focused on working with the WordPress sample solution that leverages a MySQL database as a data store. We started by showing you how to set up the cluster to connect the MySQL database by installing the Open Service Broker for Azure and leveraging the RBAC-enabled Helm tool. We then showed you how to install a MySQL database and drastically minimize the attack surface by changing the default configuration to not allow public access to the database. Then, we discussed how to restore the database from a backup and how to leverage the audit logs for troubleshooting. Finally, we discussed how to configure the solution for DR, and so satisfy your organization's DR needs by using Azure SQL geo-replication.

In the next chapter, you will learn how to implement microservices on AKS, including by using Event Hubs for loosely-coupled integration between the applications...