When Done, You Will

We have a lot to cover – so let’s get going!

Create Our API App

The first resource we are going to create is an API App; this unsurprisingly is where our API code will run. To do so, log-in to Azure (or if you don’t have an account, you’ll need to create one), and click “Create a resource”:

 Again, I’ll mention the point that the following screenshots were correct at the time of writing, but given the fast pace of change in Azure, they may be subject to change.

Fundamentally though, resource creation in Azure is not that difficult, so small UI changes should not stump someone as smart as yourself!

In the “search box” that appears in the new resource page, start to type “API App”; you will be presented with the API App resource type.

Select “API App,” then click “Create.”

WAIT! Before you click Create, click the App Service plan/location.

After clicking the Service Plan, click “Create new.”

On the “New App Service Plan” widget, enter an App Service Plan name, and pick your location, then click the Pricing Tier.

After, click the Pricing Tier.

We have selected the cheapest tier with “Free Compute Minutes,” although please be aware that I cannot be held responsible for any charges on your Azure Account! (After I create and test a resource if I don’t need it – I “stop it” or delete it).

Then click OK.

Then click “Create” (ensure your new App Service Plan is selected).

After clicking Create, Azure will go off and create the resource ready for use.

You will get notified when the resource is successfully created; if not, click the little “Alarm Bell” icon near the top right-hand side of the Azure portal.

Here you can see the resource was successfully created; now click “Go to resource.”

This just gives us an overview of the resource we created and gives us the ability to stop or even delete it. You can even click the location URL, and it will take you to where the API App resides.

As we have not deployed anything, you’ll get a similar landing page as shown in Figure 13-13 (of course for reasons already mentioned, it may look a bit different, but that is of no consequence to us at this point).

Create Our PostgreSQL Server

Now, there are a number of different ways that you can create a PostgreSQL database on Azure, but I’m going to take a slightly unorthodox route and spin up a PostgreSQL Server in a Container Instance in Azure (think Docker containers).

Azure Database for PostgreSQL Servers

I’ve configured the most basic example of this that I could.

Container Instance Pricing

Now, I don’t need to tell you that “you get what you pay for” in this life, so clearly the Azure Database for PostgreSQL option is a purpose-built resource that’s designed to work as a database, whereas the container option I’m taking is in no way optimized for Production performance!

Warning!

If you restart the PostgreSQL container instance that we create in the next section, it essentially resets, and you will lose your configuration and data relating to it – just something to bear in mind.

From a learning (and cost!) perspective, I still think this option is acceptable. If, however, you are moving to a “real” Production environment, then you’ll really need to look at something a little more fit for purpose.

So back in Azure, once again click “Create a Resource,” and this time search for “Container Instances.”

Select “Container Instances” from the options drop-down, and you should be displayed the Container Instances detail screen; click “Create” to continue.

You’ll get taken to the Basics tab on the creating wizard; fill out the details as relevant to you; however, the image name must be postgres.

1. 1.

   Your subscription.

    
2. 2.

   Resource group (I’d make this the same as the one you placed the API app into).

    
3. 3.

   Container name can be anything, but I’d name it something that identified it as a PostgreSQL server.

    
4. 4.

   Region (I’d make this the same as the one you placed the API app into).

    
5. 5.

   Image Source: Select Docker Hub (this is where we’ll get our postgres image).

    
6. 6.

   Image Type: Select Public (the postgres image we use in the next step is publicly available on Docker Hub).

    
7. 7.

   Image Name: As mentioned earlier, this needs to be the exact name of the image on Docker Hub, so in this case postgres.

    
8. 8.

   OS Type: Select Linux.

    
9. 9.

   Size: Leave these as the defaults.

    

When you’re happy click “Next: Networking >.”

And supply the following details in the Networking Tab.

1. 1.

   Select “Public” for a public IP Address (note this can change if the container restarts).

    
2. 2.

   Add a DNS name label as the IP Address can change if the container restarts.

    
3. 3.

   Add the standard 5432 TCP port for PostgreSQL.

    

When you’re happy, click “Next: Advanced >.”

And enter the following details on the Advanced tab.

1. 1.

   Set the Restart Policy to “On Failure.”

    
2. 2.

   Create an “environment variable” for the Postgres password for the default database; the Key you should use for this is

    

POSTGRES_PASSWORD

The choice of password (the value) is up to you. In my case, I used

pa55w0rd!

Warning!

As you can see our PostgreSQL password is in plain text; again this is not a production-suitable solution. We are using it for (cheap!) testing purposes only.

If you pop back to Chapter 7 where we set up an instance of PostgreSQL locally using Docker Desktop, there is a bit more of a discussion on these settings – so we don’t need to go over old ground here. Just a point of note, however, the environment variable for the PostgreSQL DB password (POSTGRES_PASSWORD) is exactly the same as the one we used when setting up our local Docker instance.

Click “Review and Create” (we can skip the “Tags” tab).

You should see “Validation Passed” at the top of the screen; when you’re happy, click Create, and in a similar way to the API App, Azure will go off and create your resource.

You’ll get notified when both your resources are set up: by clicking All resources, you can see everything we have created.

Connect and Create Our DB User

As before we want to create a dedicated user to connect in and use our database, the exercise is also a great opportunity to test that our PostgreSQL container instance is up and running.

First, we need to get the Fully Qualified Domain Name (FDQN) of the container instance, so in Azure find your container instance resource, and select it; this will display a number of details, most important of which is our FDQN.

Make a note of the FDQN, and move over to DBeaver, and create a new connection to a PostgreSQL instance – this is exactly the same as when we connected into our local instance, the only differences being the host and possibly the password for the postgres user (depending on what you set in the container instance environment variables).

Remember to tick “Show all databases” on the PostgreSQL tab.

You can test the connection or press Finish to setup our connection to our Azure-based instance.

And again, check that the role was created and that it has create database rights.

Along with the FDQN, set aside the user ID and password for later.

Configure Our Connection String

OK, so go back to your list of Azure resources, and select your API App Service. On the resulting screen, select Configuration in the Settings section as shown here.

Click OK, and you’ll see the connection string has been added to our collection.

Configure Our DB User Credentials

So, add them as an Application Setting as follows.

Again, just be careful that the User ID attribute name is exactly the same as the local user secret name and what your app is expecting to ingest when it creates the connection string as shown next.

Click OK, and you’ll see the new UserID application setting.

Configure Our Environment

See Figure 13-35.

I’ve shown my setup as it appears in Azure in Figure 13-36.

Again, I know I keep repeating myself, but you need to make sure the Names of these configuration items are the same as their Development counterparts, as that is what our application is expecting – please double-check these! The values of these items I have to leave up to you to get correct!

Warning!

Every time you make a configuration change, you need to save it - see Figure 13-37.

Make sure you click Save to apply your changes (when starting out with this stuff, I didn’t and spent a lot time trying to understand what was wrong!).

Creating Our Azure DevOps Release Pipeline

Back in Azure DevOps, click Pipelines ➤ Releases.

The click New Pipeline.

On the next screen, select and Apply the Azure App Service deployment template.

Don’t forget to Save. When you do, you’ll be presented with the following.

Just click OK.

Click back on the “Pipeline” tab, then on Add (to add an artifact).

Click Add. Then click the lightning bolt on the newly created Artifact node.

In the resulting pop-up, ensure that Continuous deployment trigger is enabled, then click Save.

You’ll get asked to supply a comment when turning this on; do so if you like.

Click Releases; you’ll see that we have a new pipeline but no release; this is because the pipeline has not yet been executed.

Wait! What About EF Migrations?

Nowhere in our CI/CD pipeline have we accounted for this step, where we tell Azure it has to create the necessary schema in our PostgreSQL DB. There are a few ways we can do this, but the simplest is to update the Configure method in the Startup class.

This approach means that migrations will be applied when the app is started for the first time.

For clarity, the Configure method changes are highlighted in Figure 13-51.

Save your changes and Add, Commit, and Push your code as usual; this should trigger the build pipeline.

When the Build Pipeline finished executing (successfully), click “Releases.”

You’ll see the Release Pipeline attempting to deploy to Azure And eventually it should deploy (you may need to navigate away from the Release Pipeline and back again).

Note: Yours will be named differently.

Now fire up Postman, and prepare to make a GET request to retrieve all our commands (we won’t have any yet).

Remember to append: /api/commands to the base URL

Then click Send.

If the deployment and Azure configuration were successful, you’ll get an empty payload response and an OK 200 Status.

Double-Check

Just to double-check everything, let’s make a POST request to create some data.

Finally, if you’re brave enough, click “Send” to make the request.

And again, we have success!