terraform-aws-serverless-static-wordpress

Introduction

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.

Architecture Overview

Pre-requisites

• 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.

Provider Set-up

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.

Module instantiation example

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.

Launching container, customize Wordpress and publish static site

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.

Troubleshooting

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.

Inputs

[
  {
    "cloudwatch_metrics_enabled": true,
    "managed_rule_group_name": "AWSManagedRulesAmazonIpReputationList",
    "metric_name": "AWS-AWSManagedRulesAmazonIpReputationList",
    "name": "AWS-AWSManagedRulesAmazonIpReputationList",
    "priority": 0,
    "sampled_requests_enabled": true,
    "vendor_name": "AWS"
  },
  {
    "cloudwatch_metrics_enabled": true,
    "managed_rule_group_name": "AWSManagedRulesKnownBadInputsRuleSet",
    "metric_name": "AWS-AWSManagedRulesKnownBadInputsRuleSet",
    "name": "AWS-AWSManagedRulesKnownBadInputsRuleSet",
    "priority": 1,
    "sampled_requests_enabled": true,
    "vendor_name": "AWS"
  },
  {
    "cloudwatch_metrics_enabled": true,
    "managed_rule_group_name": "AWSManagedRulesBotControlRuleSet",
    "metric_name": "AWS-AWSManagedRulesBotControlRuleSet",
    "name": "AWS-AWSManagedRulesBotControlRuleSet",
    "priority": 2,
    "sampled_requests_enabled": true,
    "vendor_name": "AWS"
  }
]

Modules

Outputs

Requirements

Resources