aws-samples / aws-samples/eb-php-wordpress
EFS should be independent of lifecycle of elasticbean environment
- Dominant language
- PHP
- Stars
- 166
- Forks
- 92
- PR merge metrics
- No merged PRs in 30d
Description
The [tutorial for Deploying a High-Availability WordPress Website](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/php-hawordpress-tutorial.html) talks about creating an RDS instance external to the elasticbean. The tutorial uses an EFS that is created using [efs-mount in .ebextensions](https://github.com/awslabs/eb-php-wordpress/blob/8e5a386b56923443fd35ad9824db87f99faace64/.ebextensions/efs-create.config#L1) and is symlinked to ``wp-content/uploads``. The ``uploads`` directory in wordpress is used to store the media files.
Since this EFS volume is created through elasticbean, what this means is that if the EB is terminated, the files stored on ``uploads`` are deleted as well. The intent is that the ``uploads`` directory has non-ephemeral files that need to shared across all the instances. Deleting the files when the instance terminates is counter to this intent.
To be consistent, I think both the EFS and RDS should be created outside the elasticbean environment.
Contributor guide
Research direction
Start with the AWS High-Availability WordPress tutorial and .ebextensions/efs-create.config, then trace how the EFS volume is created and linked to wp-content/uploads. Compare that lifecycle with the externally created RDS instance. Done means the uploads EFS is external to the Elastic Beanstalk environment and persists when the environment is terminated.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, php, wordpress
- Domain
- cloud, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100