Serverless Static Wordpress is a Community Terraform Module from TechToSpeech that needs nothing more than a registered domain name with its DNS pointed at AWS.
It creates a complete infrastructure framework that allows you to launch a temporary, transient Wordpress container. You then log in and customize it like any Wordpress site, and finally publish it as a static site fronted by a global CloudFront CDN and S3 Origin. When you’re done you shut down the Wordpress container and it costs you almost nothing.
The emphasis is on extremely minimal configuration as the majority of everything you’d need is pre-installed and pre-configured in line with industry best practices and highly efficient running costs.
- A domain name either hosted with AWS, or with its DNS delegated to a Route53 hosted zone.
- A VPC configured with at least one public subnet in your desired deployment region.
- Desired deployment region cannot be one of the following, as Aurora Serverless v1 is not yet supported there:
- Africa (Cape Town)
- Asia Pacific (Hong Kong)
- Asia Pacific (Osaka)
- Europe (Milan)
- Europe (Stockholm)
- Middle East (Bahrain)
- South America (São Paulo)
- AWS GovCloud (US-East)
- AWS GovCloud (US-West)
- China (Beijing)
- China (Ningxia)
Alternatives for Aurora Serverless will be supported in a future release.
Terraform best practice is to configure providers at the top-level module and pass them downwards through implicit
inheritance or explicit passing. Whilst the module and child-modules reference required_providers, it is also necessary
for you to provide a regional alias for operations that must be executed in us-east-1 (CloudFront, ACM, and WAF).
As such you should include the following in your provider configuration:
terraform {
required_version = "> 0.15.1"
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 3.0"
configuration_aliases = [aws.ue1]
}
}
}
provider "aws" {
alias = "ue1"
region = "us-east-1"
}
The ue1 alias is essential for this module to work correctly.
locals {
aws_account_id = "998877676554"
aws_region = "eu-west-1"
site_name = "peterdotcloud"
profile = "peterdotcloud"
site_domain = "peter.cloud"
}
data "aws_caller_identity" "current" {}
module "peterdotcloud_website" {
source = "TechToSpeech/serverless-static-wordpress/aws"
version = "0.1.0"
main_vpc_id = "vpc-e121c09b"
subnet_ids = ["subnet-04b97235","subnet-08fb235","subnet-04b97734"]
aws_account_id = data.aws_caller_identity.current.account_id
# site_name will be used to prepend resource names - use no spaces or special characters
site_name = local.site_name
site_domain = local.site_domain
wordpress_subdomain = "wordpress"
hosted_zone_id = "Z00437553UWAVIRHANGCN"
s3_region = local.aws_region
# Send ECS and RDS events to Slack
slack_webhook = "https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX"
ecs_cpu = 1024
ecs_memory = 2048
cloudfront_aliases = ["www.peter.cloud", "peter.cloud"]
waf_enabled = true
# Provides the toggle to launch Wordpress container
launch = 0
## Passing in Provider block to module is essential
providers = {
aws.ue1 = aws.ue1
}
}
Do not to set launch to 1 initially as the module uses a Codebuild pipeline to take a vanilla version
of the Wordpress docker container and rebake it to include all of the pre-requisites required to publish the Wordpress
site to S3.
The step to push the required Wordpress container from Dockerhub to your own ECR repository can be tied into your module instantiation using our helper module as follows:
Note this requires Docker to be running on your Terraform environment with either a named AWS profile or credentials otherwise available.
module "docker_pullpush" {
source = "TechToSpeech/ecr-mirror/aws"
version = "0.0.6"
aws_account_id = data.aws_caller_identity.current.account_id
aws_region = local.aws_region
docker_source = "wordpress:php7.4-apache"
aws_profile = "peterdotcloud"
ecr_repo_name = module.peterdotcloud_website.wordpress_ecr_repository
ecr_repo_tag = "base"
depends_on = [module.peterdotcloud_website]
}
The CodeBuild pipeline takes a couple of minutes to run and pushes back a 'latest' tagged version of the container, which is what will be used for the Wordpress container. This build either needs to be triggered manually from the CodeBuild console, or you can use this snippet to trigger the build as part of your Terraform flow:
resource "null_resource" "trigger_build" {
triggers = {
codebuild_etag = module.peterdotcloud_website.codebuild_package_etag
}
provisioner "local-exec" {
command = "aws codebuild start-build --project-name ${module.peterdotcloud_website.codebuild_project_name} --profile ${local.profile} --region ${local.aws_region}"
}
depends_on = [
module.peterdotcloud_website, module.docker_pullpush
]
}
Whilst this might feel convoluted (and you might ask: why not just provide a public customized Docker image?), it was felt important that users should 'own' their own version of the Wordpress container, built transparently from the official Wordpress docker image with full provenance.
Finally, if you wish to fully automate the creation and update of the domain's nameservers if it's registered in Route53 within the same account, you can add these additional snippets to include this in your flow.
resource "aws_route53_zone" "apex" {
name = "peter.cloud"
}
resource "null_resource" "update_nameservers" {
triggers = {
nameservers = aws_route53_zone.apex.id
}
provisioner "local-exec" {
command = "aws route53domains update-domain-nameservers --region us-east-1 --domain-name ${local.site_domain} --nameservers Name=${aws_route53_zone.apex.name_servers.0} Name=${aws_route53_zone.apex.name_servers.1} Name=${aws_route53_zone.apex.name_servers.2} Name=${aws_route53_zone.apex.name_servers.3} --profile peterdotcloud"
}
depends_on = [aws_route53_zone.apex]
}
See examples for full set-up example.
Check that the CodeBuild job for the container has built successfully.
Toggle the launch value of the module to 1, and re-run Terraform plan/apply, which will launch the instance of the
Wordpress management container.
First-time launch of container will take 5-6 minutes as the installation of Wordpress completes. You can check status if you wish in CloudWatch log groups for ECS. It will come up within a few seconds on subsequent launches.
The Wordpress management container will become available at http://wordpress.yourdomain.com (note HTTP, not HTTPS) by
default, unless you specified your own wordpress_subdomain prefix.
Default admin is: supervisor Default password: techtospeech.com
Change these on first log in or specify your own in module instantiation.
You will find WP2Static with S3 Add-on installed. Go to the WP2Static Menu->Addons, and click the 'Disabled' button to Enable the Add-on.
The configuration of the plugin has been set up such that no additional configuration is required unless you wish to change any options.
You may now edit Wordpress as you would normally, customize your site as you like, and when ready proceed to the 'Run' section of the WP2Static plugin, and click the 'Generate Static Site' button. This will take some minutes depending on the size of your site. When complete the site will be published in S3, and available via the public URL configured in your module definition.
Gentle reminder that no backup options are currently bundled with this module - the most effective means would be to generate and retain a backup from within Wordpress for maximum flexibility. We recommend the UpdraftPlus plugin.
If you experience issues with the publish element of WP2Static, you can retry. It can be more reliable to proceed to 'Caches' section and select to delete all caches. Currently you need to additionally delete the S3 deploy cache manually.
You should also try increasing the CPU/Memory allocated to the container. Undersizing the container can cause timeout issues that are currently not well handled in the plugin.
If the job fails immediately and your site has previously generated a sitemaps.xml file, ensure you restore the plugin that generates this file and the crawl job can fail fast if it cannot locate it. For all other features and issues relating to WP2Static, raise an issue on their repo. For any issues relating to this module, raise an issue against this repo.