Categories
Geek Speak

WordPress / Elastic Beanstalk

The advantages are worth the effort – auto-scaling, minor updates, weekly restarts. The following is my build list —

  1. Create an EFS file system to hold uploads that persists through platform updates and are accessible on multiple environments.
  2. Add the default security policy for the default VPN to the EFS security group. This will save a lot of aggravation later.
  3. Create an RDS database to hold the data that persists through platform updates and is accessible on multiple environments.
    1. Don’t let Elastic Beanstalk build the database for you. It will automatically terminate it if you terminate the environment it was built by.
    2. Don’t be bullied into a large instance if you don’t need one. If you click enough you’ll find low-cost db instance sizes.
    3. Don’t implement multi-availability zones unless you are really ready.
  4. Create a CodeCommit repository to hold your configuration files and WordPress.
  5. Clone the repository to local working directory. This is a good time to work out all of the AWS CLI config and credentials monkey business.
  6. Create an Elastic Beanstalk application and environment
    1. Use the default VPN. Do not put it in a new VPN it will make things 10x harder.
    2. Make it autoscaling even if you set the min and max count to one. This will attach a load balancer to terminate HTTPS.
    3. Add the HTTPS listener on the load balancer before creating so that all of the HTTPS fun is baked in. Use an AWS domain wide certificate. There is no reason not to, they are free.
    4. Make sure to put the instance in the RDS security group. It will just make everything easier later when WordPress is trying to initialize. If your security environment is complicated, Elastic Beanstalk will croak here. There is a stupid 200 character limit on the security group list. This is especially egregious with the ‘new’ long names for resources.
    5. Attach you environment to all of the IP subnets that you can in your availability zone. There does not seem to be any downside to doing this.
    6. I used to say add in all of your environment properties here BUT, with Amazon Linux 2 environment properties are only available to root accounts. So, they are pretty much useless now.
    7. Create the environment.
  7. Once it is built navigate to the public DNS location and see the default ‘success’ page.
  8. Add a Route 53 DNS entry in you hosted zone that matches the certificate. This will make the WordPress configuration easier.
  9. Test out your new URL. Make sure the HTTPS is working without silly ‘unsafe’ warnings.
  10. Before you do anything else get the eb cli configured and attached to your repo, app, and environment.
  11. Extend the Elastic Beanstalk configuration with the WordPress necessities —
    1. Create a .ebextensions/options.config file to hold all of the database information and salts.
    2. Create an efs-mount.config file. The contents can be copied from AWS help on the topic — EFS mount Elastic Beanstalk. Make sure to put the correct EFS id and region.
    3. If you want a warning-free WordPress build, add a packages.config to force imagick on to the environment
      packages:
      yum:
      amazon-efs-utils: []
      ImageMagick: []
      ImageMagick-devel: []
      ImageMagick-perl: []
      commands:
      01_install_imagick:
      command: /usr/bin/yes ”| sudo /usr/bin/pecl install imagick
      test: ‘! /usr/bin/pecl info imagick’
    4. Now here’s the tricky part. Amazon Linux 2 on Elastic Beanstalk really does not want to support .htaccess files. The best workaround is to implement a wordpress.config file to place a file at /etc/httpd/conf.d/wordpress.conf. Place the directory rewrite instructions here so that WordPress can do the URL voodoo that it does.
      files:
      “/etc/httpd/conf.d/wordpress.conf”
      mode: “000744”
      owner: root
      group: root
      content: |
      <Directory “/var/www/html”
      Options FollowSymLinks
      AllowOverride All
      Require all granted
      RewriteEngine On
      RewriteBase /
      RewriteRule ^index.php$ – [L]
      RewriteCond %{REQUEST_FILENAME} !-f
      RewriteCond %{REQUEST_FILENAME} !-d
      RewriteRule . /index.php [L]
      </Directory>
    5. Now it is time to get a symlink configured to the EFS mount point. My EFS mounts to /wpfiles. The link has to be created AFTER the application is copied into /var/app/current. To make this happen create a file in .platform/hooks/postdeploy/01-symlink.sh. This is really a one-liner, mine looks like
      #!/usr/bin/env bash
      sudo -u webapp ln -s ${EFS_MOUNT_DIR} ${EFS_LINK_DIR}
    6. Check all of the ownership and permissions on the files you just created. Remember shell files have to be executable.
    7. Download WordPress and put it in the root of you repo.
    8. Do a little git magic – git add –all; git commit -am “initial build”; git push
    9. Deploy it all up to Elastic Beanstalk – eb deploy
    10. Try to navigate to your URL. If you did everything right it should tell you to configure WordPress.
    11. Once you are configured, have you theme picked out, have loaded your plugins, and cleaned up any lint, bring a copy back to your local repo, commit it and deploy it back up. This will serve as your application going forward.

I wrote a script to do that last step. I run it every time there is a WordPress, theme or plugin update.

Leave a Reply