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: create resource

In the Search the marketplace field, enter Web app: marketplace search

In the suggested search terms, you should see Web App, click on it: suggested search terms

In the results, click on Web App: search results

On the Web App blade that is displayed, click on Create: web app 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): empty create blade

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: List AppSvc plans
    • Click on Create new New App svc blank
    • 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) D1 plan
    • Click on Apply
    • The completed blade should now look like this: completed app svc
    • 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): Complete webapp blade
  • 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: Validating Validation complete
  • After a few minutes, the app will have been created, as shown by a notification like the one shown below: New webapp created
  • Clicking on Go to resource will, somewhat unsurprisingly, take you to the overview page for the new resource: Overview

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 Extensions
  • Click on Add Add Extension
  • Click on Choose Extension Choose Extension
  • Scroll down the list until you find an extension called Composer and click on it Composer List
  • Click on Accept Legal Terms Legals
  • Click on OK Legal OK
  • Click on OK Extension OK
  • You should see a notification like the below when the extension has been added Extension Add Notifiy
  • You should also now see it in the list of installed extensions Composer Installed
  • Under the Settings heading on the left, click on Application Settings App Settings1
  • 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 PHP Save
  • You will see a notification as shown below: App settings updating
  • 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: Notifications
  • 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 Deploy Section
    • You will see screens like below showing the various options available: deploy opts 1
    • Because I’ve already used bitbucket for app deployment, it has the name of my account showing already: deploy opts 2
    • 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: Account choice
    • On the next screen, select a Team, Repository and Branch to deploy - below is an example from this site: Repo Config
    • You should now see a screen like below - click on Finish to complete the configuration Repo final
    • You should also be notified as follows: Deployment setup success
    • You should now see a screen like below, showing a pending deployment: 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: Failed Deploy

Now, if you click on the blue book icon under the Logs heading, you will see more information as show below: fail log

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.

Delete Composer

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. Successfully deployed

Click on the Overview tab.

Click on the URL to your new website (blogname.azurewebsites.net):

New site running

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 Scale Up
  • Click on Custom Domains
  • Turn HTTPS Only to On HTTPS On And you should see it confirmed:

HTTPS on Notify

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!)