Though we’re an AWS Select Partner, we’ve typically not been too involved when it comes to AWS CloudFormation, including their orchestration technology. Though when our director, Greg Harvey, spoke with Will at LocalGovDrupal, a plan formed. Specifically in relation to reducing (ideally removing) the barrier to entry for those wanting to use the distribution as a base. So, maybe the AWS Marketplace is a potential channel for councils to try LocalGovDrupal?
A limitation right off the bat is that, to put a product in the AWS Marketplace, it kind of needs to be built with AWD CloudFormation. This provides a YAML or JSON formatted way of describing an AWS service that can be set up and configured automatically, resulting in an infrastructure that can be saved in code. Other products are similar, like Terraform from Hashicorp. Of course, there are AWS modules from Ansible modules, both of which are commercially maintained and community developed.
After some searching, Greg found the AWS Reference Architecture project for Highly Available Drupal in their aws-samples repository on GitHub. Granted, it’s now dated, but it is nice and complete, with DNS handling, SSL and CDN configuration out of the box.
- It's ancient and therefore running on old Drupal and Amazon Linux and PHP (7.0) version. So the first step would be to update that.
- Despite what the build parameters imply, it makes no effort to handle installing Drupal.
- LocalGovDrupal installs with composer, however, the install_drupal script provided assumes you can simply unpack a downloaded archive
- All instance types are the previous generation
- It can’t/won’t work in AWS regions (notably, London) that weren’t supporting the prerequisite products when it was made
As such, there’s work to be done. Greg said he could have opted to pack an Amazon Machine Image (AMI) and be done with it, but he wanted to drag the reference architecture into today in the name of learning more about CloudFormation. Plus, to hopefully, create a useful production release Marketplace product.
How it works
The master template defines the necessary CloudFormation parameters needed by the end customer to build the infrastructure and then install Drupal.
Then for each required element, it loads in a Resource sub-template is loaded. This will create the action element.
All the resource templates are in our repository (you can also locate them on AWS S3 for public use)
Using DependsOn, the order is set in the master template. Now, because the newvpc resource has no dependencies, it gets built first. However, everything from there depends on it because it builds a new VPC (Virtual Private Cloud) which is a standalone virtual network at AWS.
Once built and the new network is up and running, next is the securitygroups resource. This organises the creation of those virtual firewalls that separate the various parts of the infrastructure from one other and the outside world.
Following this, there's a lot of infra we can build at once. This is because it DependsOn the VPC and the Security Groups (SGs) existing.
Next comes (in no particular order) the:
- publicalb resource to create our load balancer to sit in front of our web servers
- bastion resource - an AWS Auto Scaling Group for EC2 (ASG) for creating a server to use as a base point for the SSH to jump off to the web server cluster
- efs resource - for mountable network disk
There are other resources that depend on the VPC and SGs, which have their own additional dependencies, namely the:
- elasticache resource. This will run up an ElastiCache cluster for Drupal caching via memcached. However, it has an additional dependency. It’s optional on the user entry form, so if you don’t select it, it doesn’t get built
- rdscluster resource. This creates an AWS Aurora (MySQL version) database cluster. It’s your only option in the reference architecture, but Greg changed this to offer a choice of:
- rdsinstance resource. This will create a standalone, single or multiple availability zone MariaDB instance, a single-AZ instance (essentially, a single database server) or a highly available multi-AZ instance. This is not as costly as a full Aurora cluster.
Once that is all sorted, CloudFormation can then create the ASG for the web servers. Similarly to the bastion resource but with a few more install needs:
- PHP and dependencies for LocalGovDrupal
- Drupal. Here, do so using composer and drush si (site install command)
This happens via a cloud-init script. Then, this gets described in the YAML file of the web template. Next, it’s built and executed by the wrapper AWS have created, called cfn-init (cfn short for CloudFormation).
After that, you may need to wait for 15 minutes before Drupal appears. This is because the composer install and drush si take time. Though if you log in to the AWS console, head to EC2 and Load Balancers you will see your new load balancer. What’s more, your Drupal website on its designated URL should be there too.
There are two more resources in the master template left to load; cloudfront and route53. These are options on the form, but if selected, (and once the web template has built the ASG successfully), these templates will be executed.
One creates a DNS record for your new Drupal website (only if using AWS Route 53 for DNS services).
The other puts the CloudFront CDN in front of your load balancer. Resulting in better performance, SSL as standard and DDoS protection (which Greg recommends as it’s inexpensive).
And there you have your stack! It’s best to find the basic LocalGovDrupal site that’s there to be played with.
Cool! So is it in the Marketplace?
Well, no, not yet. The crux is there’s uncertainty on how/who should do this and it needs discussion. Though, you can use it if you have an active AWS account.
Click “Launch Stack” next to your chosen region, fill in the form and there you have it!
Greg plans to continue developing this. Including adding more composer options, an option to load in the demo content project.
Keep visiting the repository.