Giter VIP home page Giter VIP logo

terraform-aws-serverless-static-wordpress's Introduction

terraform-aws-serverless-static-wordpress

Test Suite follow on Twitter

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

Architecture

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

Name Description Type Default Required
aws_account_id The AWS account ID into which resources will be launched. string n/a yes
cloudfront_aliases The domain and sub-domain aliases to use for the cloudfront distribution. list(any) [] no
cloudfront_class The price class for the distribution. One of: PriceClass_All, PriceClass_200, PriceClass_100 string "PriceClass_All" no
ecs_cpu The CPU limit password to the Wordpress container definition. number 256 no
ecs_memory The memory limit password to the Wordpress container definition. number 512 no
hosted_zone_id The Route53 HostedZone ID to use to create records in. string n/a yes
launch The number of tasks to launch of the Wordpress container. Used as a toggle to start/stop your Wordpress management session. number "0" no
main_vpc_id The VPC ID into which to launch resources. string n/a yes
s3_region The regional endpoint to use for the creation of the S3 bucket for published static wordpress site. string n/a yes
site_domain The site domain name to configure (without any subdomains such as 'www') string n/a yes
site_name The unique name for this instance of the module. Required to deploy multiple wordpress instances to the same AWS account (if desired). string n/a yes
site_prefix The subdomain prefix of the website domain. E.g. www string "www" no
slack_webhook The Slack webhook URL where ECS Cluster EventBridge notifications will be sent. string "" no
snapshot_identifier To create the RDS cluster from a previous snapshot in the same region, specify it by name. string null no
subnet_ids A list of subnet IDs within the specified VPC where resources will be launched. list(any) n/a yes
waf_acl_rules List of WAF rules to apply. Can be customized to apply others created outside of module. list(any)
[
{
"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"
}
]
no
waf_enabled Flag to enable default WAF configuration in front of CloudFront. bool n/a yes
wordpress_admin_email The email address of the default wordpress admin user. string "[email protected]" no
wordpress_admin_password The password of the default wordpress admin user. string "techtospeech.com" no
wordpress_admin_user The username of the default wordpress admin user. string "supervisor" no
wordpress_subdomain The subdomain used for the Wordpress container. string "wordpress" no

Modules

Name Source Version
cloudfront ./modules/cloudfront n/a
codebuild ./modules/codebuild n/a
lambda_slack ./modules/lambda_slack n/a
waf ./modules/waf n/a

Outputs

Name Description
cloudfront_ssl_arn The ARN of the ACM certificate used by CloudFront.
codebuild_package_etag The etag of the codebuild package file.
codebuild_project_name The name of the created Wordpress codebuild project.
wordpress_ecr_repository The name of the ECR repository where wordpress image is stored.

Requirements

Name Version
terraform >= 0.15.1
aws ~> 3.0
random ~> 3.1.0

Resources

Name Type
aws_acm_certificate.wordpress_site resource
aws_acm_certificate_validation.wordpress_site resource
aws_cloudwatch_log_group.serverless_wordpress resource
aws_cloudwatch_log_group.wordpress_container resource
aws_db_subnet_group.main_vpc resource
aws_ecr_repository.serverless_wordpress resource
aws_ecs_cluster.wordpress_cluster resource
aws_ecs_service.wordpress_service resource
aws_ecs_task_definition.wordpress_container resource
aws_efs_access_point.wordpress_efs resource
aws_efs_file_system.wordpress_persistent resource
aws_efs_mount_target.wordpress_efs resource
aws_iam_policy.wordpress_bucket_access resource
aws_iam_role.wordpress_task resource
aws_iam_role_policy_attachment.wordpress_bucket_access resource
aws_iam_role_policy_attachment.wordpress_role_attachment_cloudwatch resource
aws_iam_role_policy_attachment.wordpress_role_attachment_ecs resource
aws_rds_cluster.serverless_wordpress resource
aws_route53_record.apex resource
aws_route53_record.wordpress_acm_validation resource
aws_route53_record.www resource
aws_security_group.aurora_serverless_group resource
aws_security_group.efs_security_group resource
aws_security_group.wordpress_security_group resource
aws_security_group_rule.aurora_sg_ingress_3306 resource
aws_security_group_rule.efs_ingress resource
aws_security_group_rule.wordpress_sg_egress_2049 resource
aws_security_group_rule.wordpress_sg_egress_3306 resource
aws_security_group_rule.wordpress_sg_egress_443 resource
aws_security_group_rule.wordpress_sg_egress_80 resource
aws_security_group_rule.wordpress_sg_ingress_80 resource
random_id.rds_snapshot resource
random_password.serverless_wordpress_password resource
aws_iam_policy_document.ecs_assume_role_policy data source
aws_iam_policy_document.wordpress_bucket_access data source

terraform-aws-serverless-static-wordpress's People

Contributors

krutisfood avatar petewilcock avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

terraform-aws-serverless-static-wordpress's Issues

Cloudfront without Lambda@Edge

I noticed that you're using Lambda@Edge to handle default root objects in subdirectories. That's a good solution that works with OAI, but there's another way to do this. This is documented at https://aws.amazon.com/premiumsupport/knowledge-center/cloudfront-serve-static-website/ under "Using a website endpoint as the origin, with access restricted by a Referer header"

  1. S3 bucket policy configured to allow access based on referrer header (set to a secret key)
  2. S3 static website hosting, with index document enabled as index.html - unlike cloudfront, this works on subfolders
  3. Cloudfront distribution pointing to the static website URL (rather than the S3 bucket) with referrer header set

ECS Task is not able to start due to "standard_init_linux.go:228: exec user process caused: no such file or directory"

I was able to follow all the steps until the launching-container-customize-wordpress-and-publish-static-site part where changing the launch value to 1 triggers the task execution which constantly fails.

Every task try to constantly initialize but fails due to the error "standard_init_linux.go:219: exec user process caused: no such file or directory". Example:
image
image

Code build ran successfully and generated the "latest" image, which is the one failing when being run:
log-events-viewer-result.txt

I was able to download the image and replicate the issue by running it locally:
image

Code Build Fails on line 62 of main.tf under CodeBuild Module

Error I get when executing Terraform Init, validate, and plan. I Created a Blank Dir on Windows Server 2019 and Copied the text from your example code and modified it for my aws environment. See Screenshots Attached. I will admit I am new to Terraform, so maybe I am missing something small. I had to split my Main.tf into 2 screenshots.

main.tf -1
image

main.tf -2
image

provider.tf
image

Directory Structure on Server
image

Appears to Pull code just fine, seems to have trouble pulling the zip file in Error
image

Error: Invalid count argument

Hi there,

First of all, I want to thank you for creating such a great approach to serverless static wordpress. I can't wait to try it out. However, I got an error.

I tried to use your script with -> "terreform init" and it worked. However, when I tried to "terraform apply" I got an error. I am a newbie with Terreform and I don't know how to fix it. Please check the attachment and advise!

Screen Shot 2022-04-05 at 11 27 52

Screen Shot 2022-04-05 at 11 25 58

Mysetup zipfile:
wordpress-serverless-stati.zip

I am looking forward to hearing from you soon.
Best Regards,
Sang.

Invalid Count Argument

Hi there! Very new to Terraform. Any advice is appreciated.

Error message:
Error1

Main.tf 1 - Account ID Hidden
MainTF1

Main.tf 2
MainTF2

VPC:
VPC

Subnets:
subnets

Provider.tf:
provider

Thank you! Really enjoying working on this.

Generate static site fails fast with 500 error

When generating a static site, getting a 500 error straight away.

This is the error on the container logs:

[Tue Mar 22 08:13:24.798527 2022] [php7:error] [pid 114] [client 1.2.3.4:30368] PHP Fatal error:  Uncaught WP2StaticGuzzleHttp\\Exception\\ClientException: Client error: `GET http://wordpress.example.com/http://wordpress.example.com/wp-sitemap.xml` resulted in a `404 Not Found` response:\n<!DOCTYPE html>\n\n<html lang="pt-PT">\n\n<head>\n\t<title>P\xc3\xa1gina n\xc3\xa3o encontrada &#8211;</title>\n<meta name (truncated...)\n in /var/www/html/wp-content/plugins/wp2static/vendor/leonstafford/wp2staticguzzle/src/Exception/RequestException.php:113\nStack trace:\n#0 /var/www/html/wp-content/plugins/wp2static/vendor/leonstafford/wp2staticguzzle/src/Middleware.php(69): WP2StaticGuzzleHttp\\Exception\\RequestException::create()\n#1 /var/www/html/wp-content/plugins/wp2static/vendor/leonstafford/wp2staticpromises/src/Promise.php(204): WP2StaticGuzzleHttp\\Middleware::WP2StaticGuzzleHttp\\{closure}()\n#2 /var/www/html/wp-content/plugins/wp2static/vendor/leonstafford/wp2staticpromises/src/Promise.php(153): WP2StaticGuzzleHttp\\Promise\\Promise::callHandler()\n#3 /var/www/html/wp-content/plugins/wp2static/vendor/leonsta in /var/www/html/wp-content/plugins/wp2static/src/DetectSitemapsURLs.php on line 125, referer: http://wordpress.example.com/wp-admin/admin.php?page=wp2static

Looks like the same issue reported here: https://staticword.press/t/404-error-when-crawling-sitemap/368/7, fixed in this commit: elementor/wp2static@59540b1

Think the issue is that the package under modules/codebuild/codebuild_files/serverless-wordpress-wp2static.zip was generated on Jun 19, 2021 and the package v7.1.7 containing the fix on Sep 5, 2021.

is this still maintained?

The idea is awesome but what I think what we have now is far from the promise.

I've been struggling since yesterday, solving all kind of issues and I'm wondering whether it's still maintained

I'm on latest TF v1.1.4

Redirect www <-> apex domain

For SEO, I always figure it's better to pick out a canonical domain - whether that's www.example.com or example.com. It would be nice if the redirect Lambda would handle redirecting you from any non-canonical domains to the canonical one.

Explanation of WAF?

I consider myself relatively smart about AWS but I'm having trouble understanding what WAF will do for a static site. I see there are three rules enabled, the first blocking IPs by reputation which may help reduce costs. The second, bad inputs are meaningless to a static site, and the bot control rule set doesn't block anything, just tags traffic from bots in the panel. Maybe the docs could explain a little more about why you might want this option?

Replace Lambda@Edge with CloudFront functions

There are various issues with the use of Lambda@Edge and management of log groups, some of which stem from the regional nature of the CloudFront Edge caches. Replacing this simple functionality with CloudFront functions won't affect cost, should reduce execution time, and sidestep some of the existing limitations.

Error VPC Does not Exist when it does during Terraform Apply - Windows Server 2019

Using Screenshotted Code in main.tf and provider.tf I get the VPC Error below. Error says VPC does not exist when it clearly does in my AWS Account. Thanks again Pete, love this code and what it is gonna do for me. Also enjoying figuring this out.
Note: The code has provisioned alot in my account successfully just stuck on this thing.

Error

image

VPC in AWS Account in us-east-1

image

Main.TF -1 - Account ID hidden on purpose
image

Main.TF -2
image

Provider.TF
image

Really struggling to get this working...

Hi,

Love the idea of this, but I'm really struggling to get the Terraform module working - any ideas would be great!

I cloned this GitHub repository, then opened the main.tf file in the docs/examples folder.

Updated the various settings - including setting the locals.profile value to a valid AWS CLI profile that has full Admin rights to the AWS account in question. (this profile works in the AWS CLI and the secret doesn't start with + or any other non-alphanumeric character as I read that this can cause an issue)

I ran Terraform plan - which gave an error as various modules weren't installed and to run a Terraform init
So ran Terraform init on that folder - when it finished installing
Ran Terraform plan again and got this error:

Error: error configuring Terraform AWS Provider: error validating provider credentials: error calling sts:GetCallerIdentity: InvalidClientTokenId: The security token included in the request is invalid. │ status code: 403, request id: 1065464e-1b5d-4735-96e7-4aa6b19e727c │ │ with provider["registry.terraform.io/hashicorp/aws"], │ on provider.tf line 13, in provider "aws": │ 13: provider "aws" { ╵ ╷ │ Error: error configuring Terraform AWS Provider: error validating provider credentials: error calling sts:GetCallerIdentity: InvalidClientTokenId: The security token included in the request is invalid. │ status code: 403, request id: 6cca823c-9c4c-4995-b71f-3b46995cfe9a │ │ with provider["registry.terraform.io/hashicorp/aws"].ue1, │ on provider.tf line 17, in provider "aws": │ 17: provider "aws" {

And haven't managed to get any further - any ideas?

Permissions denied publishing to S3

Hitting on the following error during the S3 Addon deploying stage:

[Mon Apr 25 09:51:12.909555 2022] [php7:error] [pid 188] [client [IP]:16220] PHP Fatal error:  Uncaught exception 'Aws\\S3\\Exception\\S3Exception' with message 'Error executing "PutObject" on "https://s3.eu-west-3.amazonaws.com/[BUCKETNAME]/[PAGE}/index.html"; AWS HTTP error: Client error: `PUT https://s3.eu-west-3.amazonaws.com/[BUCKETNAME]/[PAGE}/index.html` resulted in a `403 Forbidden` response:\n<?xml version="1.0" encoding="UTF-8"?>\n<Error><Code>AccessDenied</Code><Message>Access Denied</Message><RequestId>20VCEZ (truncated...)\n AccessDenied (client): Access Denied - <?xml version="1.0" encoding="UTF-8"?>\n<Error><Code>AccessDenied</Code><Message>Access Denied</Message><RequestId>20VCEZ4CPGENM5S3</RequestId><HostId>eBueDDL8qCDSc3GOnBtFO/qsrqKJ6784v3P/2KZh9tuR5QyRNpSoGGz+XagONO+VgoPSUtXU68U=</HostId></Error>'\n\nGuzzleHttp\\Exception\\ClientException: Client error: `PUT https://s3.eu-west-3.amazonaws.com/[BUCKETNAME]/[PAGE}/index.html` resulted in a `403 Forbidden` response:\n<?xml version="1.0" encoding="UTF-8"?>\n<Error><Code>Ac in /var/www/html/wp-content/plugins/wp2static-addon-s3/vendor/aws/aws-sdk-php/src/WrappedHttpHandler.php on line 195, referer: http://[SITENAME]/wp-admin/admin.php?page=wp2static

Looks like it's the same issue reported here: elementor/wp2static#797. Confirmed that can workaround change the Object ACL under the S3 Publishing Options to private. Did i miss something on my setup, or is this a required setting that could be defaulted?

Also this elementor/wp2static#537 talks about similar issue and the IAM role permissions are different. Going to have a try with those

ResourceInitializationError: failed to validate logger args: create stream has been retried 1 times: failed to create Cloudwatch log stream: MissingEndpoint: 'Endpoint' configuration is required for this service : exit status 1

Hello Guys,

I think one last piece is missing for me to make this Pete's masterpiece to work.

I think Docker and Cloudwatch are not communicating well, but when I check TaskDefinition , it seems that containerDefinitions are set correctly. Something I might have missed during Terraform apply, or what might it be. When I check Cloudwatch log groups, indeed I do not see any streams, but isn't this started by aws logger?
Thank you

"ipcMode": null,
"executionRoleArn": "arn:aws:iam::961477247679:role/inexhaustible_WordpressTaskRole",
"containerDefinitions": [
{
"dnsSearchDomains": null,
"environmentFiles": null,
"logConfiguration": {
"logDriver": "awslogs",
"secretOptions": null,
"options": {
"awslogs-group": "/aws/ecs/inexhaustible-serverless-wordpress-container",
"awslogs-region": "http://inex.life.s3-website-us-east-1.amazonaws.com",
"awslogs-stream-prefix": "ecs"
}
},

Automatically invalidate CloudFront upon WP2Static S3 Deploy

The WP2Static S3 addon allows invaliding CloudFront distributions when deploying. An invalidation would make index.html (and other likely cached paths) immediately update when new content is posted.

I think it would take the following:

  1. Update the ECS task execution role to allow invalidating the CloudFront distribution created by the cloudfront module.
  2. Either:
    a. Document manual configuration changes for the S3 Deployment add-on (see also #69); or,
    b. Automatically update the configuration for the user (see #15)

WordPress upgrade path?

I guess EFS is used for wordpress files, allowing plugins and such to be installed in a persistent way. Is there an upgrade path for WordPress? Would you update the container, or just do it inside wordpress to update the EFS copy?

Using SSL

The original blog post states:

By default, your WordPress installation will become available at http://wordpress.yourdomain.com (Why no SSL for this part? Check The Long Version for details)

Checking the long version SSL is mentioned:

I need SSL, so I use Amazon Certificate Manager (ACM) for a free certificate which is validated by DNS records that get added to my Hosted Zone automatically by Terraform. This is all still part of this single module. Cool.

The ACM certificate exists in us-east-1 and the DNS records have been updated in Route 53 eu-west-1. My security group has port 443 open in the outbound rules (Egress from Wordpress container to world on HTTPS).

The site cannot be accessed over https://wordpress.mydomain.com. What am I missing?

Route53 entries not honouring `site_prefix` variable

Perhaps I'm missing something, but can't see how the implementation of the Route53 entries honours the site_prefix variable.

The www record is not taking the site_prefix variable https://github.com/TechToSpeech/terraform-aws-serverless-static-wordpress/blob/master/r53.tf#L3.

Also the apex record will always manage the apex record, which may not be the desired outcome.

On my scenario, i have got an existing website with an already set www and apex records which i don't want to change. I want an additional recordset to test this module that would run in parallel with the existing website.

Woudn't it make more sense for this module to only manage the recordset defined and in site_prefix and give the users the flexibility of managing their apex and www records differently?

That could also help address #43, by giving users the possibility of setting the non-canonical address to another endpoint which would handle the redirect.

Error in Cloudwatch Logs for Lambda

Pete looks like I am all set, but it looks like 2 resources are trying to use the same cloudwatch group.

I torn down everything and reran to get this error from clean run.
image

But previously I got this indicating that 2 objects want to use the same cloudwatch group.
image

Not sure what those are doing yet, but figured I would point it out. I assume it does not hurt anything just causes an error in terraform apply.

Error Bootstrapping VPC

Attempting to run terraform apply with the example gives the following error

│ Error: Invalid count argument
│
│   on vpc_setup/vpc.tf line 92, in resource "aws_route_table_association" "main_subnets_public":
│   92:   count          = length(data.aws_subnet_ids.main_public.ids)
│
│ The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many
│ instances will be created. To work around this, use the -target argument to first apply only the resources that the count depends
│ on.
╵
╷
│ Error: Invalid count argument
│
│   on vpc_setup/vpc.tf line 101, in resource "aws_route_table_association" "main_subnets_private":
│  101:   count          = length(data.aws_subnet_ids.main_private.ids)
│
│ The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many
│ instances will be created. To work around this, use the -target argument to first apply only the resources that the count depends
│ on.```

Docker build is not executed

So, I have an terraform infra built, image:base in ECR simple wordpress and now I want to CodeBuild

I have wordpress-docker.zip in S3 referenced in CodeBuild also. Run Build

and

[Container] 2022/06/01 14:06:59 Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: docker build -t $IMAGE_REPO_NAME:$IMAGE_TAG --build-arg aws_account_id=$AWS_ACCOUNT_ID --build-arg aws_region=$AWS_DEFAULT_REGION --build-arg ecr_repo_name=$IMAGE_REPO_NAME -f Dockerfile_serverless_wordpress .

Can't see any logs too, so I am lost in where to come up with next. I don't see a thread around Docker, hope I am not the first one with CodeBuild problems 😨

If you can please help.
Dro

PostBuild experiences: WP_admin Slow as F* even though CPU & Mem util at around 60 %

$$ update $$

So, I uploaded the my backup Wordpress - It's a large 20GB with 39 plugins. The long story short - it is slow as shit, even though, when I see Cloudwatch metrics both memory and CPU are not in 100 % shit.

Anybody knows how to make it work faster?? Any Wordpress guy here? I can't imagine working in it in the back - posting a blog or something with this performance where you have to wait 2 minutes to just click to another WP page.

In the text, there is written that this solution could be used also for a large website not just 200 hits per day websites. So, any ideas? @petewilcock maybe ? :P


Hello Everyone.

Some notes further I want to remark here:

So, the infra is now standing and I was able to log into Wordpress.

I logged into it and backup my website through All_in_one_WP_migration.

Two things have happened. The first Spot Fargate is too slow and pain in the ass for to work in WP_admin. Will probably need something bigger.

Another thing is backup plugins like mentioned are overriding your plugins, with that being said also plugins that Pete predefined for us - WP2static and WPS3 or something like that.

So, I think I should mention it that this might happen as well.

Thanks

Slack slash command to start WordPress container

It would be nice if Slack could be used to start and stop the WordPress container. I guess this would need to be another lambda and an API gateway. Since it just needs to set desiredCount, it should be doable with a single lambda while still returning within the five seconds Slack requires.

Add healthCheck to ECS Task Definition

ECS Task definition lacks a healthCheck block. This means ECS is unable to determine the health of the container and will report 'Unknown' under 'Health Status', even when container is healthy.

module.codebuild.local_file.php_ini can cause unnecessary TF changes

One issue with the module.codebuild.local_file.php_ini resource, whenever Terraform executes on a new machine it will trigger a replacement as the file does not exist.

It's a known thing as per https://registry.terraform.io/providers/hashicorp/local/latest/docs/resources/file

Note about resource behaviour
When working with local files, Terraform will detect the resource as having been deleted each time a configuration is applied on a new machine where the file is not present and will generate a diff to re-create it. This may cause "noise" in diffs in environments where configurations are routinely applied by many different users or within automation systems.

When using ephemeral machines to run terraform this causes the terraform to detect this as a change every time. In one side is a nuisance to have TF reporting changes when they actully there are none.

The biggest issue however is that when this resource changes, it triggers the following resource updates:

  • module.codebuild.local_file.php_ini
  • module.codebuild.data.archive_file.code_build_package
  • module.codebuild.aws_s3_object.wordpress_dockerbuild
  • null_resource.trigger_build

So images are being build and stored in ECR with no changes, which is an unecessary cost.

2 things come to my mind that we could consider:

  • An alternative implementation to the local_file resource
  • A mechanism to define retention for ECR images

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.