© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
Stefan,
I'm not certain what you mean by "something not used in the common images". To be clear, I do not even know how to make my own images. That's not to say I'm not certain I couldn't figure it out very quickly, but I never have as I personally do not think that is a good way of using EC2: I instead boot stock Ubuntu images (ami-688c7801 in this case) and then install packages on them. Currently, I do not any "custom" software other than my Python web application: everything I install comes from the default Ubuntu repositories.
(If required, I can provide the exact set of commands that I manually run to setup one of these EC2 servers. Unfortunately, I have so far been unable to fully automate the bootup of these systems as the server tends to lock up on me while I'm doing the install, but I remember thinking it was an unrelated issue to this one. I will do some testing of the fully automated boot of these servers tonight and see if I can reproduce those lockups again to see if they look at all related.)
So if you mean "am I making my own AMI that has some kind of modified system software", the answer is "definitely not". However, while I think that it is an amazing testament to modern engineering that I can reinstall and reboot computers from a thousand miles away, that is a fairly useless endeavor: the stock images are very "stock" and don't do anything at all, as far as I know, out of the box. To be putting any kind of load on them at all I'm certainly installing some software on it, even if that software is just a shell script fork bomb.
In my particular case, I install apache2 with mod_python and "pgbouncer" (from Ubuntu universe), a program from Skype that provides a PostgreSQL pooling proxy server. My python application connects to pgbouncer (which is listening on a named Unix socket and pretends to be PostgreSQL) instead of directly to my database server, which then keeps its own pool of connections to the actual database. This makes the 3200 Apache threads that I normally have running able to rapidly get a database connection without trying to coordinate local in-process pools.
Put differently: pgbouncer should be a fairly boring user-land process. If you are looking at it thinking it is some kind of cool kernel task that increases network security (maybe "bouncing" bad clients) or something, it (maybe sadly ;P) isn't. This software is actually the least popular (but I personally feel best ;P) choice in PostgreSQL pooling proxy servers, an already fairly narrow niche; therefore, I would find it highly unlikely if Timo was also using it, but maybe he will chime in with a "yeah! pgbouncer is AWESOME!" and prove me wrong.
-J