Grav in Azure part 1 - Blog design using Grav CMS in Azure
In this post, I discuss my requirements for my blog, what I’ve chosen to build it with and why.
Table of Contents
My first project on Azure was a blog site, and in choosing the solution best for my needs, I had the following requirements: >+ Use an Azure based solution at least for the backend, but don’t be afraid to use other services that complement Azure. >+ Don’t use WordPress or anything with database backend >+ Avoid Infrastructure-as-a-Service(IaaS) as I don’t want to have to deal with day-to-day sysadmin activity (I get enough of that in my day job!) - but be prepared to maintain a CMS application >+ Be responsive and as available as possible >+ Not look awful (I am not a web developer!) >+ Be secure and scalable >+ Keep my costs as low as possible >+ Be able to blog on the go relatively easily >+ Be just geeky enough to satisfy the inner geek
I searched for a Content Management System (CMS) and one that kept coming up consistently and getting good reviews was Grav.
I liked the fact it is open source, renowned for being fast, with no database to manage, and backed by a source control repository (Bitbucket in my case) so it should be easy to port to another cloud platform later.
It also has plenty of plugins to make my life easier while still permitting some fiddling around to keep the geek happy. Some of those plugins (Admin for example) mean I can write blog posts or manage the site from the browser without writing anything resembling code (though I prefer to write Markdown and push via git - using Visual Studio Code on my laptop or Git2Go on my iPhone/iPad).
In reading blogs by Troy Hunt (renowned security blogger, developer of HaveIBeenPwned and an investor in ReportURI, to name a few), and also Scott Helme (Security researcher, creator of the aforementioned ReportURI and SecurityHeaders.com), I had become aware of and interested in CloudFlare.
Cloudflare offer a number of services across a network that, at time of writing, spans 155 datacentres globally including: + DDoS Protection (which is how I first heard of them) + Global Content Delivery Network (CDN) + Shared SSL Certificate + DNS + and many more
I wanted to explore them anyway and their free plan ($0/website/month) included the above and so much more (I’ll cover more on that in a future post).
Using Cloudflare helps with responsiveness and availability (CDN), Security and Scalability (I can move up tiers if traffic exceeds expectations) and cost management (did I mention they have a really good free tier to get started with?!)
As I’m learning as I go here, there isn’t a finalised design - this is more a Proof of Concept/learning exercise for me but to recap, I have opted for the following:
Backend 1. Azure App Service Plan (1x Free F1 dev/test for testing, >1x Shared D1 for Production in a single Azure region) 1. App Service (Windows, using Bitbucket for deployment) 1. Grav CMS
This may seem far too lightweight but remember the intention here is to minimise cost and also to test out Cloudflare on the frontend and see how far we can stretch it - the beauty of using an app service is I can easily change up the plan to one with increased performance and scale up/out options. This is also not a mission critical site - you wouldn’t spec something quite this low if it was! If I were to be using an exclusively Azure solution then I’d have multiple app service instances across multiple regions/zones with Azure Traffic Manager endpoints, Redis Cache etc.
Frontend 1. Cloudflare managed DNS 1. Cloudflare CDN (as the site is mostly static content rather than dynamic) 1. Cloudflare DDoS protection 1. Cloudflare end-to-end SSL/HTTPS 1. Cloudflare traffic/threat analytics 1. Cloudflare Opportunistic Encryption (HTTP/2) 1. Cloudflare Content Optimisation (Compression, Minify) 1. Cloudflare Always On (if Origin site on Azure goes down, static content served from Cloudflare cache)
The intent here is to reduce costs by serving less content direct from the origin site in Azure and so minimising resource usage (including data egress) and cost, improving speed (significantly beyond what the backend should be capable of), and improving/simplifying security.
Future posts will cover how to build it, and my experiences in running the site and lessons learned (was I too aggressive with my cost management/optimistic in my hopes for Cloudflare).
When I know, you’ll know :-)
As ever, I would welcome your comments below!