I have set up an elastic beanstalk deployment of Drupal to host a Drupal built website.
When I start up my ec2 instance, I go through the installation steps of setting up Drupal.
However, when the instance is Restarted, or Stopped, restarting the instance goes back to this page!
How can I configure the instance so that these installation steps do not need to be repeated even when the instance goes down. This is quite worrying as I am looking to host my website this way.
Any help on this issue would be greatly appreciated!
This step means that drupal can't find database or it can find it but installation is not done yet (required tables are not created). So if you pass installation and you see again this screen it can mean 2 things:
Your database configuration is lost, so drupal can't find DB.
DB configuration file is ok, but DB it self is lost so configuration must be done again.
So first check what is the problem in your case and then solve it. Probably since you are installing in instance, DB configuration is then recorded and then lost when your box expires. If so...find a way to make permanent change do config file (should be /sites/default/settings.php).
I am becoming familiar with DigitalOcean and deployments and practicing horizontally scaling our application. I created a small droplet and set it up to run our app, and then took a snapshot of it and created two more droplets from that snapshot. When I deployed a new version of my app to the first droplet, the one I created a snapshot from, the other two received the same code, without me scp-ing files to them. Is this normal?
The answer to this question is "no."
My issue was with nginx configuration - I forgot to change the config files for the new servers and was proxying requests to the old one, thereby returning responses from only one server.
A DigitalOcean snapshot is a copy of the image file of your droplet at the time the snapshot was made. Essentially it is an exact copy of your droplet.
What this means is it has all the same coding for your application. So if anything was specific to the original droplet (IP for example) you might run into some issues. So if the duplicates had proxy coding that the new application is no longer using, it is likely to run into such issues.
I have hosted an intranet website on WAMP server which is working as expected. Now i would like to configure a backup site to it. I mean if it goes down by any chance how do i counter that?
My challenge is i can not have the URL changed as its already been distributed to many users in the past.
My URL is like
http :/ /ipaddress/MyProject/Running/Index.html
I want to know, how do i have a backup website running on the same url to maintain high availability?
Since WAMP applications do not provide their own backup APIs, you need to stop all services if you want to take a full file-system level backup; otherwise you'll get a lot of "file locked" errors and/or your backups will be in an incoherent state.
So yes, you can just make a copy of your C:\wamp directory, but stop all your WAMP-related services before (and remember to restart them after).
any problem please comment me...)
use a slave server with the one using as a master not sure of the tech but I know windows allows two or more servers with same info on them both.
Suppose I create a site in Wordpress, which is running on Elastic Beanstalk. Now, on the running app I will create posts /pages, upload images, etc. That is, some data, videos, files and records in a database will be added to the running application.
3 questions:
If WordPress is running on Elastic Beanstalk with multiple Amazon EC2 instances actually running my WordPress install, then will those files propagate automatically to all running instances? And will this also happen, if a new EC2 instance is fired up - for example, to handle increased load?
From what I see in AWS console, I can deploy different versions of an app-- but as per scenario above, if I deploy a new version, wont I lose all the files uploaded directly into running app (i.e. files and database records)? How do I keep those and at the same time deploy a new version of my app?
The WordPress team keeps issuing upgrades. Can I directly upgrade my running WordPress install, through the web interface? Or do I have to first upgrade my local version of WordPress, and then upload the new version of the app to Beanstalk? If I have to upgrade my local version and then upload, then again I am back to point 1, i.e. changes made by users directly to the older version of running app. How do I preserve those changes?
I've been working on this as well, and have learned a couple of things that are relevant here -- your question about uploads in particular has been on my mind:
(1) The best way to handle uploads, it seems to me, is to either go the NFS/NAS route like you suggest, but one better than that is to use an Amazon S3 plugin for WordPress, so that any uploads automatically copy up to S3 and the URLs in your WordPress media library reflect the FQDN of your bucket and not your specific site. That way you could have one or ten WP nodes in your Beanstalk and media/images are independent of any one of those servers.
(2) You should absolutely be using RDS here. Few things are easier to work with and as stress-free as a Multi-AZ, reserved MySQL RDS instance. Either that or your own EC2 running MySQL that is independent of the Beanstalk, but why run that when RDS is so much easier?
(3) Yes you definitely have to commit changes to your Git repository or local file first (new plugins, changes to themes, WP upgrades) and then upload/install as a revision to the Beanstalk code. Otherwise, all the changes you make via the web interface to one node will never be in the new load for a new node -- in fact you'll have an upgraded database but an older set of code in the Beanstalk application, so it's likely to create errors of some kind or another.
I took an AWS architecture course, and their advice for EC2 and the Beanstalk is to start to think about server instances as very disposable -- so you should try to think about easy ways for your boxes to provision themselves in the bootstrapping process and to take over work for one another without any precious resources on just one box. So losing an instance should never be a big deal. (This is definitely not how we thought in the world of physical servers, where we got everything tweaked 'just so'.)
Good luck!
Well, I'm no expert, but since no one has answered, I'll give it my best shot.
You are absolutely right--kind of. While each EC2 instance does have 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 don't know how one would configure WP to utilize this, but that will likely be the solution.
I think this problem is solved by my answer to #1. As for the database, all of your EC2 instances should be pulling from the same RDS location. Again, while you could have MySQL running on each EC2 instance, in the interest of persistence, having a separate database makes more sense.
You, again, have most everything right. Local development should always precede live deployment. Upgrading locally then pushing to the live servers will make sure all of your instances remain identical.
Truth-be-told, I am still in the process of learning all of this too, as I said, I'm not an expert. Hopefully someone else will come along and give a more informed answer. However, the key conceptual hurdle here is the idea of elastic scalability--and the salient point of this idea is the separation of elements between what is elastic/scalable/disposable and what is persistent.
Hopefully that helps.
I have deployed a small Wordpress site on EB, S3 and RDS. S3 holds all static data, such as media uploads. This works through a plugin. RDS holds the database. EB holds the latest deployed application. The application is deployed from my dev environment, with a build script. This way, I just have to press one button and I redeploy.
I wrote an article about it here: http://www.cortexcode.com/wordpress-to-aws-code-example/
While it was at first annoying to work with, the speed of AWS is nice and now it's easier than ever. It used to be that I had to upload a bunch of files over FTP, this is way more efficient. :-)
As an 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 in combination with cloudfront. For Wordpress there is one plugin that really speeds up this ( not affiliated to them, just really like the plugin ). There is also an assets plugin, if you'd like to serve JS, CSS files from S3. For the EFS solution, take a look at the AWSlabs docs on git, and specifically this file on how they mount the uploads file.
In general, EBS is really great for Wordpress, but you'll need to think in a different mindset as compared to other hosting solutions ( shared hosting, managed hosting ).
OK I researched a lot on this particular issue, and this is what I learned--
(1) If a wordpress user uploads some files, then his files will be uploaded only to the virtual machine that is actually serving his request at that time. Eg if currently the wordpress site is cloud-deployed and is using 5 virtual machines, now when user makes request he is directed to one virtual machine-- the one with the lowest load at that point... His uploads are stored only on that server. Current Platform-as-a-service solutions (like Amazon Elastic Beanstalk and App Fog) do not have the ability to propagate the changes to all the running instances. Either that (propagate changes to all servers) or use a common storage by all running instances-- these are the only 2 solutions to this problem. (Eg of common storage would be all 5 running virtual machines using Network-Attached-Storage (NAS)... )
(2) With ref to platforms available currently like Amazon Elastic Beanstalk and App Fog, for example, even if user made changes directly to running app- these platforms rely on the local version of code (which the admin deployed initially to cloud)- and there is no way to update the local version of code (on admin's PC) with the changes made by a user to running app-- hence these changes viz, files are lost-- Similarly, changes in database by user to running app are also lost-- unless the admin is using exactly the same database for his local app (that he deployed to cloud)
(3) Any changes to running apps first have to be made to the local app on admin's PC and then pushed to cloud.
I am working on a Cloud PaaS that addresses all these concerns-- viz updates can be made to running apps, code changes made to running app are also updated in code repository accessible by user...The Proof of concept is ready, hopefully it will be as good as I hope it should be :) -- currently the only thing that is actually there is the website (anyacloudpanel.com) -- design work is going on :)
If there is some rule that I should not mention my website( Anya Cloud Panel) -- then I am sorry -- pls feel free to edit and remove my website URL from my answer :)
Thanks,
Arvind.
Deploying WordPress to AWS Elastic Beanstalk does require some change to the normal WordPress deployment as mentioned here a few times. To answer your questions, here is a great tutorial explaining stateless applications and how to deploy to Elastic Beanstalk:
Deploying WordPress to Amazon Web Services AWS EC2 and RDS via ElasticBeanstalk
Be careful if you use a theme from themeforest for example. Some of them are incompatible with wordpress S3 plugin. Then you're screwed, you can not deploy your wordpress on the cloud.
G'day
For security reasons, our CFAdmin (and accordingly RDS) is accessed via one domain, say cfadmin.ourdomain.com, and access the site via a different domain: www.ourdomain.com.
Via some miracle I have just been able to get both RDS and a server set up without RDS giving me "Could not initialize class com.adobe.rds.core.services.Messages" (this is a first), and will allow me to launch a debugging session. However it tries to hit the file I'm testing via cfadmin.ourdomain.com (and the actual website is not defined on that IIS website). I can understand why this happens, but I can't figure out how to tell the debugging config that the actual website is www.ourdomain.com.
It is not a possibility to have either CFIDE accessible on www.ourdomain.com, or the site accessible via cfadmin.ourdomain.com. So that cannot be part of a proposed solution.
Anyone have any ideas?
Oh: this is on CF9.0.1.
UPDATE:
Sorry, just to be absolutely clear... this is our dev environment. This is all running on my local PC. However the local server (a VM running on my workstation) is configured the same as the prod environment (for obvious reasons), down to how CFAdmin is accessed.
This is not the answer you will like :) Your security folks were right in the first place. CF Builder debugging is a development tool designed to be used on a dev system and it works well mostly in a local dev environment where CF+ Apache or IIS are running on your local workstation.
On a production server RDS itself is a weakness that you really don't want running in that production environment (sorry). Having said that here are my big ideas :)
Have your admin create a folder on cfadmin.ourdomain.com that points to your prod code. Depending on your code you might get that to work.
Point cfadmin.ourdomain.com to your production code directly (no folder). After all the CFIDE and other mappings used by RDS are aliases or virtuals anyway.
That's all I got sorry....