On Fri, Mar 23, 2012 at 3:49 AM, Niels Mayer <nielsmayer(a)gmail.com> wrote:
On Mon, Mar 5, 2012 at 3:20 AM, Fabio Mancinelli
<fabio.mancinelli(a)xwiki.com> wrote:
at XWiki we are participating in different research activities, many
of them focused on cloud computing.
As a part of this research efforts we've build this project that
allows you to deploy XWiki in different cloud environments.
From my experience, I'm not sure it's a "research activity" anymore --
seems
almost ready for "prime time." :-)
Thanks.
I've had good success using
http://jelastic.com
and generic XWiki Enterprise
3.5 to bring up
http://trainspodder.com test site in very little time.
Yep, Jelastic is very nice indeed.
Though Jelastic takes a different path for configuring applications.
It gives you access to the config files of your application and has an
interface for uploading/saving additional files. Which is very nice,
btw [1].
The approach used by Amazon, but also by other cloud environments like
CloudFoundry[2] or Heroku[3], is to pass configuration data via
environment variables.
In this way you don't have to fiddle with your web application before
starting it. The WAR always stays the same.
The proof-of-concept was built by taking into account this approach:
database configuration is completely overridable using environment
variables. In the case of Amazon Beanstalk, the JDBC endpoint comes
from the JDBC_CONNECTION_STRING that you fill in the Beanstalk console
before starting the web application.
In Cloud-Foundry or Heroku it would be the same. Basically the only
thing that is different is how these variables are named and what they
contains (e.g., Cloud-Foundry uses JSON for describing services) But
the principle stays the same.
The proof-of-concept can also be easily extended by writing a
component like
https://github.com/xwiki-contrib/xwiki-platform-cloud/tree/master/xwiki-pla…
for Cloud-Foundry or Heroku, and you'll have the support for these two
environments without touching anything else.
I think that adding the support for specifying environment variables
in Jelastic environments would have a great value, and it would make
step 4 in the tutorial
http://blog.jelastic.com/2012/02/21/how-to-deploy-xwiki-to-jelastic-cloud-s…
superflous :)
Of course Amazon is not the a panacea... There are a lot of problems
with it. Maybe I need to find the time to write a more detailed blog
post about how to use this proof-of-concept and to highlight the
shortcomings I encountered.
Thanks,
Fabio
[1] ...Above all if you compare that to the nightmare of changing the
'max_allowed_packet' property in an Amazon RDS databse instance :)
[2]
https://github.com/SpringSource/cloudfoundry-samples/wiki/Cloud-foundry-env…
[3]
http://devcenter.heroku.com/articles/config-vars