Grav in Azure part 3 - Creating an Azure Web App with code deployed from Git
In my last post, Grav in Azure part 2 - Creating a Git Repo with Grav code in it, I demonstrated how to setup a Git repo in Bitbucket with the Grav Blog Site skeleton code, ready to be deployed as a web app in Azure.
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.
It should now deploy successfully.
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!)