EFS should be independent of lifecycle of elasticbean environment

[lunatech]

The tutorial for Deploying a High-Availability WordPress Website talks about creating an RDS instance external to the elasticbean. The tutorial uses an EFS that is created using efs-mount in .ebextensions 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.

[mwunderl]

Hi lunatech. Thanks for pointing this out. I'll update the tutorial.

[ITmaze]

While it's true that a resource created inside EB will be destroyed if you delete the beanstalk, I'd like to note that it won't be destroyed if you scale up and then down again.

I think that a lot of emphasis has been placed on this resource being deleted phenomenon in relation to RDS and now EFS that there are some things that are being missed in the discussion.

Specifically, destroying a server is supposed to delete stuff. If you have physical hardware with a hard-disk and a database and uploaded files on it and you throw it away, the data is gone, which is why you have a backup and recovery process. Using EB should be no different.

The whole point of having EFS and RDS built by EB is that you can have a completely independent instance running for testing or upgrade purposes without ever running the chance of changing data on the live system, this is a good thing!

Having EB take care of it also means that the access is within the stack, no need to configure external variables, hostnames for databases, etc. All of this is transparent and therefore not something you need to maintain yourself, ie. less work for the developer in maintenance.

I'd hate to see this project lose the ability to create EFS within the EB stack, since it's the only project that actually does that in a predictable way. I have been attempting to work out how to make it build the stack without needing to manually configure IP addresses to map EFS, so the whole thing becomes turn-key.

I have been using EB for around 12 months now and the mantra from AWS to put your database outside EB is getting tiresome. There are good and valid reasons for leaving it inside, just don't expect to get a warning if you delete the stack. Though you could configure it to keep the database when the stack is deleted, I suspect a similar flag exists for EFS.

I suspect, but haven't tested, that this might be that flag: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-attribute-deletionpolicy.html

[mwunderl]

We won't remove including the file system in the stack by default. Both configurations have their use, and can be supported by the same code. All in one deployments are good for development and testing for the reasons you mentioned. Independent database/filesystem is more resilient for a production environment, as it lets you swap out your web tier or data tier at-will to perform blue-green deployments and failover. All in one deployments are not as flexible and will have downtime if either component fails.

Creation of the file system would require less configuration if you also created a VPC and subnets for the environment in a configuration file or external CloudFormation stack. That's something we can look into adding support for if you're interested.

Thanks,
-Michael

[jningtho]

Following this article with a different route such as creating RDS and EFS endpoint independently and not a part of the eb deploy, I am getting the following error while deploying:

ERROR: Service:AmazonCloudFormation, Message:Template format error: Unresolved resource dependencies [FileSystem] in the Resources block of the template
ERROR: Failed to deploy application.                                
                                                                      
ERROR: ServiceError - Failed to deploy application.

What I did? Followed https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/php-hawordpress-tutorial.html.

1. Created App/env via eb console.
2. Configured LB, AutoScaling, Network, Security.
3. Created a RDS instance separately, configured endpoint in the App variable
4. Configured all the app variable in the Config.
5. Removed the following files since the env was created through the dashboard:

• dev.config
• efs-create.config
• loadbalancer-sg.config

I don't see any reference to the EFS endpoint being declared anywhere as per the article.

Question? Should 'EFS_DNS_NAME' be declared in the app config variable?

[jningtho]

Just to add, I am able to mount EFS for now as per: https://parall.ax/blog/view/3212/how-to-run-scalable-wordpress-on-aws-amazon-web-services-tutorial

I am still interested to get an answer to my original Q.
Mush appreciated.