errorsandglitches / wordpress-cloud-formation Goto Github PK

Problem

After WordPress is installed, the root path returns a 503 Service Temporarily Unavailable.

Problem

As a last step when ensuring that the system is robust, I killed the EC2 instance. All the plugins that were installed are now gone since they are not being persisted on the EFS instance.

Solution

Fix it so the plugins don't disappear after killing the instance. Specifically, the wp-content folder should be persisted.

Problem

There are some instructions such as creating the alias that need the properties of the resources. Instead of having users provide this data on the CLI, these can be retrieved by using the output of the CF stack as well as possibly needing a few AWS calls. But this simplifies the command and reduce the change of manual error (cough cough).

Solution

Add stack output to the template and use this in later instructions.

Problem

The databases for the WordPress servers should already exist in the EFS volume and be used by the Docker containers when starting on the new EC2 instance. However, after killing the instance, the WordPress websites start in the un-configured state i.e. /wp-admin/install.php.

Problem

S3 credentials are required to send the image data from the WordPress server to S3. Instead of keeping the creds in the DB, which is unsafe, the credentials of the EC2 instance can be used instead.

Solution

1. Create a public bucket in the cloud formation template
2. Update the IAM role of the EC2 instance to permit read/write access to the bucket
3. Delete the credentials from the WordPress DBs

Problem

The network bandwidth of the host is limited. Leverage S3 instead.

Solution

Add S3 in diagram and inspire people to use that.

Problem

The architecture has changed multiple times since I started the project and the architecture drawing, at least, is out of date. After pushing all the changes and getting it fully working, the README.md needs to be revisited.

Solution

Revise the README.md

Problem

When the block device mappings are not specified, the root volume is only 8GiB. Additionally, the default behavior is to
create another EBS volume of 22GiB, which is available to the instance, but not mounted.

Solution

Create a custom Block Device Mapping in the CF template