Deploying WordPress on an elastic beanstalk?

Question

Suppose I created a site in Wordpress that runs on Elastic Beanstalk. Now, in the running application, I will create posts / pages, upload images, etc. That is, some data, videos, files and records in the database will be added to the current application.

3 questions:

• If WordPress runs on Elastic Beanstalk with multiple instances of Amazon EC2 actually running my WordPress installation, will these files automatically spread to all running instances? And this will also happen if a new instance of EC2 is running - for example, to handle the increased load?

• From what I see in the AWS console, I can deploy different versions of the application, but according to the above scenario, if I distribute the new version, I will not lose all the files loaded directly into the running application (i.e. files and records Database)? How to save and simultaneously deploy a new version of my application?

• The WordPress team continues to release updates. Can I directly update the installed version of WordPress via the web interface? Or do I need to update the local version of WordPress first, and then upload the new version of the application to Beanstalk? If I need to update the local version and then download, then I will return to step 1 again, i.e. Changes made by users directly to an older version of the running application. How to save these changes?

Answer 1

OK I researched this problem a lot and this is what I found out -

(1) If a Wordpress user uploads some files, his files will only be downloaded to a virtual machine that actually executes his request at that time. For example, if the wordpress site is currently deployed in the cloud and uses 5 virtual machines, now when the user makes a request, he is sent to one virtual machine - the one with the lowest load at this point ... Its downloads are stored only on this server. Modern solutions for the platform as a service (for example, Amazon Elastic Beanstalk and App Fog) do not have the ability to distribute changes in all running instances. Either this (distribute changes on all servers), or use shared memory for all running instances - these are the only 2 solutions to this problem. (For example, all 5 running virtual machines using Network-Attached-Storage (NAS) will be shared storage ...)

(2) If you look at the platforms currently available as Amazon Elastic Beanstalk and App Fog, for example, even if the user made changes directly to running applications, these platforms rely on the local version of the code (which the administrator deployed initially to the cloud) - and no the ability to update the local version of the code (on the administrator’s computer) with the changes made by the user to run the application - therefore, these changes, in particular, will be lost. Likewise, changes to the database by the user to run the application are also lost - if the administrator does not use the exact same database for his on-premises application (which he deployed to the cloud)

(3) Any changes in running applications must first be made to the local application on the administrator’s PC, and then click on the cloud.

I am working on a cloud PaaS that solves all these problems: viz can be added to run applications, code changes made to the running application are also updated in the code repository accessible to the user ... The proof of concept is ready, I hope it will be so well, as I hope, it should be :) - currently the only thing that actually exists is the website (anyacloudpanel.com) - the design work is ongoing :)

If there is a rule that I should not mention my website (Anya Cloud Panel), then I'm sorry - pls feel free to edit and remove the URL of my website from my answer :)

Thanks, Ervind.

Answer 2

I am also working on this, and you learned a couple of things that are relevant here: your question about downloads in particular was on my mind:

(1) The best way to handle downloads, in my opinion, is to either switch to NFS / NAS, as you suggest, but better than using the Amazon S3 plugin for WordPress, so that any downloads are automatically copied to S3, and the URLs in the WordPress library reflect the fully qualified domain name of your bucket, not your specific site. Thus, you can have one or ten WP nodes in your Beanstalk, and the media / images are independent of any of these servers.

(2) You must absolutely use RDS here. Few things are easier to work without stress, like Multi-AZ, a reserved instance of MySQL RDS. Either this, or your own EC2 working with MySQL, which is independent of Beanstalk, but why run it when RDS is much easier?

(3) Yes, you must first make changes to your repository or local Git file (new plugins, theme changes, WP updates), and then download / install Beanstalk code as a revision. Otherwise, all changes made via the web interface to one node will never be in the new download for the new node - in fact, you will have an updated database, but an older set of code in the Beanstalk application, so it can create errors one or another type.

I took a course in AWS architecture, and their recommendations for EC2 and Beanstalk - to start thinking of server instances as very one-time - so you should try to think about how your mailboxes can support themselves during the boot process and take on work with each other without any precious resources on just one box. So losing a copy will never be a big problem. (This is definitely not the way we thought in the world of physical servers, where we all set up "just like that.")

Good luck

Answer 3

Well, I'm not an expert, but since no one answered, I will give him the best shot.

• You are absolutely right. Although each instance of EC2 has some local storage, it is destroyed and reset with each new instance. Because of this, Amazon has things like Elastic Block Storage and S3 for persistent files. I do not know how to configure WP to use this, but this is most likely to be a solution.

• I think this problem was solved by my answer to # 1. As for the database, all your EC2 instances should be pulled from the same RDS location. Again, although you can use MySQL for each instance of EC2, in the interest of conservation, having a separate database makes more sense.

• You, again, have everything you need. Local development must always precede live deployment. Upgrading locally and then moving to live servers ensures that all your instances remain identical.

In truth, I am still studying all this, as I said, I am not an expert. I hope someone else comes and gives a more informed answer. However, the key conceptual barrier here is the idea of ​​elastic scalability, and the main point of this idea is the separation of elements between what is elastic / scalable / disposable and what is persistent.

Hope this helps.

Answer 4

The deployment of WordPress for AWS Elastic Beanstalk requires some changes to the usual deployment of WordPress, as mentioned here several times. To answer your questions, here is a great tutorial explaining stateless applications and how to deploy to Elastic Beanstalk:

Deploy WordPress for Amazon AWS EC2 and RDS Web Services through ElasticBeanstalk

Answer 5

I have deployed a small Wordpress site on EB, S3 and RDS. S3 contains all static data, such as media downloads. This works through the plugin. RDS stores the database. EB has the latest deployed application. The application is deployed from my dev environment with a build script. So I just need to press one button and I will go over.

I wrote an article about it here: http://www.cortexcode.com/wordpress-to-aws-code-example/

While at first it was annoying to work, AWS speed is good, and now it's easier than ever. It used to be that I had to upload a bunch of files via FTP, it is much more efficient. :-)

Answer 6

In addition to all the great answers already:

1) I can highly recommend EFS, but also S3 for media files, so they are served from high-availability regions combined with a cloud area. For Wordpress, there is one plugin that really speeds up this (not related to them, I just really like the plugin). There is also a plugin for assets if you want to serve JS, CSS files from S3. To solve EFS, consider AWSlabs docs on git, namely this file on how they mount the uploads file.

In general, EBS is really great for Wordpress, but you need to think in a different way compared to other hosting solutions (hosting, hosting).

Answer 7

Be careful, for example, if you use a theme from a theme. Some of them are not compatible with the Wordpress S3 plugin. Then you are screwed, you cannot deploy your WordPress in the cloud.