5 Mar
2012
5 Mar
'12
12:20 p.m.
Hi everybody,
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.
In the current state, it allows to build an XWiki distribution that
can be deployed on Amazon Beanstalk
(http://aws.amazon.com/elasticbeanstalk/) and can also take advantage
of the Amazon S3 Blobstore (http://aws.amazon.com/s3/) for storing
attachments.
The project is extensible, so other environments could be supported
(e.g., Openstack SWIFT blobstore, http://swift.openstack.org/) and
also deployment that are dynamically configured when started in
virtual machines that are started up in other platforms.
If you want to have a look you can find it here:
https://github.com/fmancinelli/xwiki-platform-cloud
For the moment I've put it on my personal GitHub account but I'll move
it to XWiki contrib as soon as possible.
Thanks,
Fabio
P.S.: If you want to experiment with it, Amazon provides a free usage
tier (http://aws.amazon.com/free/)
23 Mar
23 Mar
3:49 a.m.
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." :-)
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.
For details:
http://lists.xwiki.org/pipermail/users/2012-March/022342.html
https://plus.google.com/118051488912335163531/posts/Hb3FDqSZmPQ
https://plus.google.com/118051488912335163531/posts/RSJhfJTz1Lj
-- Niels
http://nielsmayer.com
3:43 p.m.
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:
Thanks.
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." :-)
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
9 Apr
9 Apr
3:50 p.m.
On Fri, Mar 23, 2012 at 3:43 PM, Fabio Mancinelli
<fabio.mancinelli(a)xwiki.com> wrote:
On Fri, Mar 23, 2012 at 3:49 AM, Niels Mayer
<nielsmayer(a)gmail.com> wrote:
FYI I wrote such a blog post on my personal blog:
http://blog.fabio.mancinelli.me/2012/04/06/XWiki_in_the_cloud.html
Of course, if it's interesting for the community, we could also
republish it on XWiki.org blog.
-Fabio
On Mon, Mar 5, 2012 at 3:20 AM, Fabio Mancinelli
<fabio.mancinelli(a)xwiki.com> wrote:
Thanks.
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." :-)
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
> For details:
> http://lists.xwiki.org/pipermail/users/2012-March/022342.html
> https://plus.google.com/118051488912335163531/posts/Hb3FDqSZmPQ
> https://plus.google.com/118051488912335163531/posts/RSJhfJTz1Lj
>
> -- Niels
> http://nielsmayer.com
>
4596
days inactive
4631
days old
3 comments
2 participants
participants (2)
-
Fabio Mancinelli -
Niels Mayer