I have created my Elastic Beanstalk application with Wordpress to test. However I am struggling to understand the best way of managing changes in dynamic content online and development changes locally.
I upload my initial Wordpress Installation to my AWS Bucket
I run the initial Wordpress Setup
-- Lets presume that I have included a live theme and uploaded some products and time has progress, changes are made online, new products added to WooCommerce etc..
I make a new page template locally and want to upload to the Bucket
I use EB Deploy, but when I do this all content online in my Bucket is overwritten with the local content.
Now I do of course accept this is by design, but how is the problem best addressed?
Does anyone have any advice to offer with managing content of this sort in the AWS EB?
The instances managed by EB have to be considered disposable. This means that they can disappear without notice.
If the changes are dynamic (eg: files are being uploaded) you cannot store those files in the file system of the instances as they are disposable.
In addition, have in mind that if you scale to several instances, you will have different instances managing different data sets (eg: you upload a file to only one instance, not to all of them).
There are several approaches you can try, for example:
Use a Network File System (NFS) server: in a separate instance, setup a NFS server and set up the EB instances to mount a remote mountpoint at startup. With this approach you can centralize the storage for all your EB instances.
Check out the EFS service from AWS. It's like a NFS server but Amazon flavored. Haven't checked it out yet but it looks promising.
To resolve these problems I created a couple of extra S3 buckets, the first for images and the second for css, js and alike.
Since this was a Wordpress, WooCommerce installation, I commissioned the S3 Offload plugin from Delicious Brains (https://deliciousbrains.com/wp-offload-s3/) ehich was a little expensive but this moved and monitored content of this sort and copied off to the other S3 buckets and allowed the 'EB Deploy' to leave the working content untouched.
Related
I would like to have a scalable infrastructure for my wordpress site. We currently have the following:
A cloudfront that serves the website
A load balancer and target group with only one registered target in it
An RDS.
The WP server (on which config, and wp-content is).
We have several thousands of pages in the wordpress instance, and sometimes we need to make changes, invalidate caches in the cloudfront to serve the new content. Doing this on a lot of pages can create a huge load on the server, and make it unreachable or super slow. So we thought about adding an autoscaling group, which would spin up new instances if the load is too high, and remove then when necessary.
To do so, I believe we need to move the wp-content folder to a shared directory (between all the servers). Is it a correct assumption first of all?
So I naturally created an EFS, which I mounted on a copy of my wordpress server, then rsync all the files with permissions in the efs.
Then as suggested all over the net, I added the following in my wp-config.php:
define('WP_CONTENT_DIR', '/mnt/efs/wp-content'); where /mnt/efs/wp-content is directory on the efs.
From this point, the website worked as expected, I could see some traffic on the EFS monitoring page when viewing pages.
To make sure all the files are correctly shared and copied in the wp-content, I deleted /data/app/wp-content/ folder (it shouldn't be used, as I referenced wp-content to be in my efs).
And my site started acting weirdly. Some formatting disappeared, buttons are native and not customized etc. The console shows a lot of 404 also with following errors:
www.mysite.eu/:1 Access to font at 'https://www.mysite.fr/wp-content/themes/mysite/dist/fonts/icomoon/icomoon.ttf' from origin 'https://www.mysite.eu' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
GET https://www.mysite.fr/wp-content/plugins/js_composer/assets/lib/bower/font-awesome/webfonts/fa-solid-900.woff net::ERR_FAILED 200
Looks like there are no fonts, no plugins, no themes anymore.
So, quite a few questions:
Do I need to keep both local wp-content and shared wp-content? If so, if I install a plugin or a theme, would it be available for other servers as well?
Do I really need an EFS? Or data is fully stored in DB, and wp-content can live on its own for each server?
Are there any other steps in moving the wp-content folder? Maybe specific steps for some plugins?
Is my architecture lacking anything for what I would like to achieve (scale up and down based on demand), or does that make sense?
Thank you!
Don't put wp_content on a shared file system (s3 bucket). It contains a lot of theme and plugin code, and running code from s3 can cause performance trouble and crank up IOPS costs. Instead, use a plugin to offload your site's uploaded media files (jpg, etc) to the s3 bucket, then clone the site.
Use a shared persistent object cache if you can. redis is a good choice.
AWS has a tutorial about doing this, without the cache, on Lightsail. https://aws.amazon.com/getting-started/hands-on/launch-load-balanced-wordpress-website/
I'm going to write a Wordpress plugin which allows me to automatically migrate between two Wordpress sites. (copying all files + database backup from server A to B)
Now I try to figure out what would be the easiest and efficient way to copy the created backup files from one server to the other. It should transfer these files directly.
Maybe something like a REST call? (All servers with the plugin are waiting for a request and then start with the download of the file).
Are there better ideas?
I have a site with a large number of images, I'd like to host these on a remote cloud storage solution as we're getting close to our storage limit on the current server.
I can get a remote cloud storage service setup, what needs to be done on wordpress configuration to use this as the new folder for uploads?
Thanks
Specifically for AWS S3:
The company I work for use this: https://deliciousbrains.com/wp-offload-s3/ and it's worked a treat!
This should handle the automatic upload of your old media, plus updating your posts/pages. To be safe, download a local copy of your WP and database, and run all it locally using a test bucket. Or, have a back up on to hand if the upload doesn't work. Can't be too safe!
We've only had one issue with it this past week and it's when you upload a file but change the file extension afterwards, it never off-loaded that particular image to S3 and continue to load the old /wp-content/<year>/<month> version.
After recent upgrade to latest WordPress version, media uploads no longer work. They return missing temp folder error.
I found out that WP thinks that /wwwroot/wp-admin/ is the temp folder, that's where it is trying to send uploads.
I tried everything to force it to change within WordPress. Setting WP_TEMP_DIR, even tried rewriting core function that looks for temp folder in /wp-includes/text/Diff.php and setting static path.
Nothing works. I don't really know much about Azure, so it's been a pain in the butt.
My last resort is to install and use Azure Storage plugin for WP, but that's last resort.
Anyone can shed some light on this issue? Would greatly appreciate it.
UPDATE: Site is a Azure website, it does not use Azure instance.
http://www.windowsazure.com/en-us/home/features/web-sites/
I'm not to sure about Azure but you can change the tmp directory WordPress uses by using the command below. Make sure to make a folder in your home directory before doing so.
wp-config
define('WP_TEMP_DIR','/link-to-your-folder-you-just-made');
First of all, you should never store anything on an Azure instance, consider it volalite storage just like RAM - if the instance goes down or even gets randomly restarted you could literally get a brand new virtual machine with a new file system and lose everything.
That being said, you can safely RDP into the instance - create a directory (c:\temp for example) and as long as the IIS account has rights over the directory you won't have any issues using it as scratch storage. I would use Andy's approach above (I don't know wordpress, but I know Azure) and simply make sure that it points to a directory that you can use as temp and that the IIS user can safely use.
You may want to log in to the VM with RDP if only for the additional reason that it will give you great insight in how Azure structures the file system for the software it runs, you will see 3 drives and if memory serves one of them is purely a scratch drive that you can use. But it's not persistent, consider that it can get cleared at any moment.
Hope this helps,
I just changed the server one of my sites is hosted on. In doing so, I lost all the images. The CCK file upload fields show "ghost" data but contain no actual image data as they did before the site transfer.
All my data is fine, however.
Is there a way to prevent this so all my images are maintained?
Thanks
You can transfer files with rsync directly or use drush to rsync. You'll need to have ssh access to the servers to get this to work.
Here's some info on setting up your drush aliases:
http://www.leveltendesign.com/blog/dustin-currie/synchronize-one-drupal-site-to-another
http://drupal.org/project/drush
If you're performing this task once you could also use scp to copy files from the destination:
http://www.go2linux.org/scp-linux-command-line-copy-files-over-ssh
If you're on a shared hosting platform, just FTP the files over old school style.