In this post, we’ll go ahead and build that web app and deploy the code from the repo to the web app, at the end of which we will have a blog site live and ready to view (with further configuration/optimisation needed).
What you will need
An Azure account
A git repo with the grav blog site skeleton in it (see my previous post)
I’m using a Windows 10 laptop - so to follow along exactly, you’ll need the same - though I’m sure most steps will work just about the same on a Mac or a Linux desktop, albeit using different desktop apps/tools.
To get started, login to https://portal.azure.com and at the top left, click on Create Resource:
In the Search the marketplace field, enter Web app:
In the suggested search terms, you should see Web App, click on it:
In the results, click on Web App:
On the Web App blade that is displayed, click on Create:
You will now see a Web App Create blade as shown below (because I already have an App Service Plan available, it is prefilled for me here but you can easily create your own new App Service Plan - in fact it’s mandatory you create one if you don’t already have one):
Now, lets go through the fields in the form:
App name: this is the name your app will have when created, but also becomes the subdomain of the URL to your new webapp, so if you name it myblog, the url will be myblog.azurewebsites.net. name must be unique in Azure - a green tick symbol will be shown at the right-hand side of the field if the name typed is unique, otherwise a red X will be shown.
Subscription: Select the subscription to the web app should be created against/associated to/billed against.
Resource Group: You can either Create New or Use Existing - in my case I will Use Existing. Note here that the location of the resource group should be the same as where your App Service Plan is located (later in the process). I’m going to use a resource group I already created for my web apps in the West Europe region. If you choose to create new, select that option and the. enter the unique name for that group. A naming convention helps as the amount of Azure infrastructure/assets you have grows - I’ve gone with a moniker that means something to me, followed by an acronym for the region (weu = West Europe) and finally the type of resource, in this case rg.
OS: I may go into reasons to choose one vs the other in a future blog post, but for this tutorial, click on Windows
Publish: Choose whether to deploy Code or a Docker Image - for this tutorial, we want to deplay from code in a Git repo, so click on Code
App Service plan / Location: I already have an app service plan that I will use for my web app, but let’s go through most of the process of creating a new one as you may be starting from scratch.
Click on App Service plan / Location
A new blade will open as shown below:
Click on Create new
Enter a unique name for your app service plan
Choose a region from the dropdown list (same region as the region your web app resource group is in)
Click on the Pricing section to choose the pricing level suitable for your workload. For this tutorial, click on Dev/Test then select a D1 which is the cheapest non-free
price plan available (remember, we’re trying to see how fast and responsive a blog site we can build for as little outlay as possible)
Click on Apply
The completed blade should now look like this:
Click on OK
This will take you back to the blade for configuring the new web app.
From here the blade will look something like the screenshot below (with your own unique names):
You may not need Application Insights for your own needs, but for the purposes of this blog series, click on On to enable it and select the same region as your webapp and resource group.
Click on Create
You may notice the following initially once you have clicked on Create:
After a few minutes, the app will have been created, as shown by a notification like the one shown below:
Clicking on Go to resource will, somewhat unsurprisingly, take you to the overview page for the new resource:
At this point you might be tempted to think you are done, but there are a few more steps required to complete the configuration - bear with me!
On the left-hand side, under the Development Tools heading, click on Extensions
Click on Add
Click on Choose Extension
Scroll down the list until you find an extension called Composer and click on it
Click on Accept Legal Terms
Click on OK
Click on OK
You should see a notification like the below when the extension has been added
You should also now see it in the list of installed extensions
Under the Settings heading on the left, click on Application Settings
Change PHP version to the highest available (from 5.6 to 7.2 at time of posting) or highest supported by Grav and click on Save
You will see a notification as shown below:
When completed you will see a notification, the example below shows the creation of the app, installation of the Composer extension and update to the app settings:
Now, we need to tell the web app where it’s code comes from:
Under the Deployment heading on the left, click on Deployment Center
You will see screens like below showing the various options available:
Because I’ve already used bitbucket for app deployment, it has the name of my account showing already:
For the purposes of this tutorial, click on Bitbucket
You have the option to Change Account (or indeed add one if one is not already associated), or continue with the current account - click the appropriate option for you:
On the next screen, select a Team, Repository and Branch to deploy - below is an example from this site:
You should now see a screen like below - click on Finish to complete the configuration
You should also be notified as follows:
You should now see a screen like below, showing a pending deployment:
Now, at this point, you’re expecting nothing but success, a sea of green, right?
Wrong!
For reasons not fully understood, it’s quite common at this stage for it to fail:
Now, if you click on the blue book icon under the Logs heading, you will see more information as show below:
So, remember that Composer extension we installed? Sometimes I’ve noticed that despite it claiming to be successfully installed, it doesn’t work.
If this happens, you’ll want to go back to Extensions, and click on the Composer extension, then click on Delete and confirm when prompted.
Then repeat the installation as shown earlier.
Once done, go back to Deployment Center
Click again on the logs for the failed deployment, and click on the Redeploy button.
Click on the Overview tab.
Click on the URL to your new website (blogname.azurewebsites.net):
Now, theres one little gotcha I fell foul of when I first deployed my website and started to write and publish blog posts - as soon as I navigated away from the homepage I started to get page not found (404) and security errors.
I quickly resolved this by realising that I needed a web.config file (since this is a Windows web app on IIS - other config files apply that work for other OS/Webserver combinations) that would permit access.
Luckily, the skeleton site contains a webserver-configs directory with sample configs (e.g. web.config, .htaccess and others).
So, to begin with simply copy webserver-configs/web.config to the root directory of your repo and commit/push and problem solved!
You can make further changes to this config file later and you will likely need to for security and performance reasons - more on this in a future post about optimising Grav.
One last thing in this post - you’ll want to ensure the site always runs with HTTPS in this security conscious world, so:
Click on Scale up (App Service Plan) under the Settings section on the left-hand side
Click on Custom Domains
Turn HTTPS Only to On
And you should see it confirmed:
In part 4, we’ll configure DNS and Cloudflare, to further improve the security, resilience and performance of what is otherwise a site that is not that resilient or performant at present (we are running on a D1 instance after all!)
If you like what I do and appreciate the time and effort and expense that goes into my content you can always
