I just wanted to post an announcement that we've finally gotten out a point-update of the Project Mercury AMI. Just in case you were wondering if this project would continue, it will! I've been really excited and encouraged by all the positive feedback so far, so keep your ideas and questions coming. The 0.51-Alpha release includes a number of bugfixes and improvements, most notably it:
- Is based on the latest Pressflow including Drupal Core 6.14 and Simpletest 2.9
- Fixes the self-update process to merge correctly and pull from Pressflow's lovely new VCS home on Launchpad
- Includes the rc1 version of cacherouter
- Fixes postfix and s3 metadata issues so there's now a working MTA out of the box
Most importantly for people considering this stack for production deployments, we're now bundling 64-bit images with every release. The quickest way to find the AMIs is to keyword search for "mercury" in your favorite EC2 console. More information and AMI ids are below the fold. Let me know what you think, and what you'd like to see next!
The current AMIs are:
US
- 64bit: ami-e655b58f / PANTHEON-pressflow-mercury64-alpha-0.51.manifest.xml
- 32bit: ami-a855b5c1 / PANTHEON-pressflow-mercury-alpha0.51.manifest.xml
EU
- 64bit: ami-ee48639a / PANTHEON-pressflow-mercury64-alpha-0.51.manifest.xml
- 32bit: ami-ec486398 / PANTHEON-pressflow-mercury-alpha0.51.manifest.xml
Privacy Warning: In an effort to keep track of how wide the interest is in these images, we're including a small, completely anonymous "phone home" ping in the boot script that will alert the getpantheon.com server that an instance was launched. If you want to run the Mercury stack without this, you can build it based on the wiki instructions. Other than this little curl request, the stack is exactly the same.
Roadmap: It seems clear (and isn't terribly surprising) that there's a fair amount of interest in running this stack in production, so I'd like to move towards something stable sooner rather than later. That means addressing issues of persistent storage, as well as double/triple-checking the rest of the stack for sanity. However, I'm hoping we can get there before the end of the year. Those who are bold are welcome to take the stack (or the wiki instructions) and run with them.
As always, let me know what else you'd like to see. As we move towards the end of the Alpha phase, I'll be pulling together a more formal roadmap and feature set.
Comments
EU Amis
Now available in Europe:
32 bit: ami-ec486398
64 bit: ami-ee48639a
https://pantheon.io | http://www.chapterthree.com | https://www.outlandishjosh.com
Awesome!
I'm very anxious to try these out. Does sharing these AMI's take a while though? I can't see them yet.
Tobias Sjösten
Should be ready!
See my screenshot. Let me know if you're still having issues.
https://pantheon.io | http://www.chapterthree.com | https://www.outlandishjosh.com
That's odd. I'm not see the
That's odd. I'm not seeing the same as you are and the AMI's are clearly marked as public.
Check my counter screenshots out. Am I missing something obvious?
Tobias Sjösten
This is the same for me. I
This is the same for me. I installed a US version in the mean time and am loving but I can't see the EU instances of Mercury to install which is what I need. Love what you've done. What are we missing?
The images are in! However,
The images are in!
However, they still wont work for me. When I try to fire one up, all I get is The AMI ID 'ami-a855b5c1' does not exist. This goes for both the x86 and 64bit AMI.
Tobias Sjösten
mmm....I still can't see them
mmm....I still can't see them for EU?
:(
Very strange / very sorry
Somehow the EU Mercury images were marked as private. Very sorry for this. They are now public.
https://pantheon.io | http://www.chapterthree.com | https://www.outlandishjosh.com
I just watched your
I just watched your screencast - this looks really interesting.
I love the idea of deploying web-servers via cloud hosting, because it provides so much scalability, portability and could potentially be used as a way to level the playing field between larger organisations with money and clout and regular people with good ideas. Cloud-hosting in this way reminds me of a scene described in a book by Bruce Sterling; there's a situation where some characters have need of a semi-permanent dwelling - they decided on a location and the technology actually instructed and aided the characters to do the actual construction work themselves.
Maybe I'm being too cynical, but there's something about the situation that seems a little too good to be true. To use a cliché, I think that there's a risk when all our eggs are in the same basket. It gives Amazon a huge amount of responsibility, and power - and it leaves me slightly worried.
But congratulations for making this project possible. I'll be signing up for an account to test it, very soon.
If it sounds too good to be true...
Indeed. There are definite drawbacks and cautions here. I'm working on a good rundown of these for my presentation at DrupalCampPDX/BadCamp, etc.
The upside is there are a lot of new players here, and interoperability is on the rise:
http://libcloud.org/
Beware the buzz, but it's getting pretty exciting!
https://pantheon.io | http://www.chapterthree.com | https://www.outlandishjosh.com
Hi Josh, This may not be
Hi Josh,
This may not be related to Mercury, but Amazon in general. But is the security supposed to be configured form the AMI or does Amazon take care of all of that?
How is the AMI hardened security wise?
Cheers,
G
****Me and Drupal :)****
Clickbank IPN - Sell online or create a membership site with the largest affiliate network!
Review Critical - One of my sites
Both
EC2 includes a built-in firewall that by default only allows access on ports 80 and 22 (HTTP and SSH). You can configure this to the nth degree.
Beyond that, the AMI is not "hardened" other than running only clean/safe code and up to date drupal. It also will update its Ubuntu packages on boot. In general my philosophy around esoteric server configuration for the sake of security is that it tends to be a losing proposition unless you have internal security/sysadmin expertise. Otherwise, the solution is generally to follow simple best practices and not open up unneeded services.
https://pantheon.io | http://www.chapterthree.com | https://www.outlandishjosh.com
APC issue with cron
Hi Josh,
I tested the AMI and found out that when running cron.php with cacherouter enabled, the memory limit is hit rather fast. Especially when you have lot's of modules and even some apachesolr indexing.
So my quick solution in settings.php: when cron is triggered, don't use apc.
<?php# Cacherouter: use APC for all local caching
if ($_SERVER['SCRIPT_NAME'] != '/cron.php') {
$conf['cache_inc'] = './sites/all/modules/cacherouter/cacherouter.inc';
$conf['cacherouter'] = array(
'default' => array(
'engine' => 'apc',
'shared' => FALSE,
'prefix' => '',
'static' => FALSE,
'fast_cache' => TRUE,
),
);
}
?>
Interesting
I will have to look into this for the next release. Not sure why this would be driving up the memory utilization.
https://pantheon.io | http://www.chapterthree.com | https://www.outlandishjosh.com
cron + apc
When having many modules enabled such as ApacheSolr, Subscriptions, ... which all do their job on cron time, I guess that's the reason why cacherouter goes over it's memory. I don't know whether that makes sense, but all I can saw is that when use this fix, I don't get mem problems anymore.
varnish time out
Forgot to mention, but in order to run cron successfully, I had to change the Varnish time out from 60s to 300s. Otherwise, I got a 503 'service not available' answer. Other than that, the AMI runs flawless so far.
What manages the self update process?
A self update process for Pressflow sounds like a dream come true- how does it work? What manages the process? Is it something in Pressflow or another piece of the Mercury stack?
Script
Right now it's just a function of the initial boot script calling a bzr merge when it rolls out.
In the future we will be looking at creating some services that will allow people to get remotely-managed pressflow updates as well as other infrastructure upgrades. That's a ways off though. ;)
https://pantheon.io | http://www.chapterthree.com | https://www.outlandishjosh.com
Saw Robert Douglass twitter
Saw Robert Douglass twitter about Distro Module today. Wasn't sure how relevant it would be as a solution to making Pantheon an updating service, but thought I'd at least mention it.