Hi Tako,
well its somewhat easy.
First, you need to get an account - funnywise, you usually have one as you
can just login with your amazon.com account. Then you'd register yourself
for the services you want - here: EC2 (aws.amazon.com);
After that youre "in". To get started you need to understand how aws works.
In EC2 you can have "instances" - a dedicated virtual machine with
guaranteed cpu time and ram that is available in 5 flavours (power + ram -
differs in pricing, going from 0,10 per hour to over a dollar per hour -
pricing is shown on aws).
BTW, regarding the pricing: is right that aws doesnt let you try it for
free, however, my whole testrun did cost under a dollar, namely 0,57 USD.
Thats nearly "free" to me.
If a instance is shutdown, you'll loose *all* data in it and its reset to
pre-start (!) state. So even you have space in an instance, the data there
will be lost. To overcome this, you need space that can be mounted - this is
called EBS (Elastic Block Store). You can think of these as a real hard
drive that can be attached to 1 (only 1!) AMI instance.
BTW: all cations like new instance, storage and so on can be easily set up
by using the Amazon Management Cosole (webapp under console.aws.amazon.com
).
So the overview for a JR testrun is:
1 AMI Instance (small) <---connected-----> 1 ECB Volume
AWS offers much more services, but these are *not* necessary now (later it
may be useful to use additonal aws sotrage options for lower price/ sharing
between instances/ backup etc...)
So, after you get the first grip, you just need to start an instance at
first. As AMI image I would go with "ami-45997c2c" as this is a public one
that has java and tomcat on it (you also can build your own AMI local and
upload, but for testrun its waste of time, as over 1800 preconfigured AMIs
are available in US region and over 200 in EU region). Also make sure you
get a key-pair generated in first time use and download it - this is needed
for SSH root access to it later on.
After your instance is up and running you need to attach space. So you go
to ECB Volumes and add a new one. Make sure you create both (instance and
volume) in same (!) places called "availability zone" in aws (can be looked
up for the instance in case not configured explicitely in the console by
just klicking on the running instance). In case you create one in zone A and
the other in B you can't attach them together.
After ECB is setup and attached, you can access the instance using SSH and
your private key. Then simply create a directory and mount the volume to it
(remember: first time you need to format it). In case your instance is shut
off, or the ECB detached (do unmount first!), your data will be still
existing on your ECB volume and can be attached to any future instances (for
long term however, you should have a look at aws S3).
So after instance is running and storage mount, you then can config your
repository.xml to use the mount path for file based JCR repo. Then just
deploy your application to the tomcate via SFTP and voila, JCR on AWS
running. If you want to kill the instance, you can do so and then create a
new instance and repeat the app upload and in case storage path is equal all
should be working.
You'll notice that the URL changes all time - to overcome this you'll need
to grab a "aws elastic IP", a fixed IP that can be attached to instances and
wont change as long as you "possess" it (costs money depending if in use or
not - prices can be looked up under aws.amazon.com).
So, that'll should get you up and running. Further AWS and Java dependend
info under:
http://developer.amazonwebservices.com/connect/kbcategory.jspa?categoryID=130
Best,
Korbinian
Tako Schotanus schrieb:
"In an short attemp I tried to get from 0-AWS knowledge to a running JR
demo
app"
Hi Korbinian,
would you mind detailing a bit more how and what you did? I don't mean an
exact description but just a rundown of the services you used and such.
Is there a way to try what you did for free? Because I have the feeling
from
what I read that you always have to pay with Amazon?
It's one of the reasons I never tried any of the Amazon services and it
might be an advantage that Google has: in lots of places developers make
the
tech decisions and if Google allows you to try things out for free you're
more likely to take a look at it.
Cheers,
-Tako
On Mon, Apr 13, 2009 at 11:10, Korbinian Bachl - privat <
[email protected]> wrote:
well, even if one would be able to deploy JR, it would be a real joke, as
googles hard limitations (maybe they soften these later on) would make
files
over 1MB each impossible - this and the maximum 10MB response limit kills
nearly all java apps that are somewhat file related... Currently, im
really
unsure what market they target with GAE Java as the limitations makes
nearly
all java apps that might benefit most of such a cloud infrastructure
impossible, e.g:
Time per request 30 sec
-> and no threads + background = no data crunching...
Files per app 1,000
-> this one looks odd... I nowhere could find what a "file" by their
definition is, but a limit to 1000 real classes sounds a showstopper for
many apps
HTTP response size 10 MB
-> I still don't understand how one then could make backups from one owns
data...
Datastore item size 1 MB
-> that makes either fuzzy workarounds for larger data or it just won't
store anything bigger as 1 MB each
Application code size 150 MB
-> this sounds high enough
In the meantime I think that GAE Java will mostly help AWS or even Azure.
In an short attemp I tried to get from 0-AWS knowledge to a running JR
demo
app. It took me less than 30 minutes of reading and 5 minutes of setup
till
my first instance was up, had attached storage and a fix IP on it (used
some
sun AMI, had all on it for JEE5)...
As google will get similar price range for GAE as AWS is today, I dont
see
any use in investing more time on GAE just to avoid some of their
restrictions while there are other solutions on the market already that
nearly have no limits at all. Only hazzle from AWS I found out so far is
the billing + invoices that are not yet compatible with EU (european)
fiscal
needs.
Best,
Korbinian
Stefan Guggisberg schrieb:
On Sat, Apr 11, 2009 at 4:36 PM, Torgeir Veimo <[email protected]>
wrote:
has anyone been able to deploy a Jackrabbit repo within google AppEngine
for Java? - if yes, I would be interested in how to overcome the "no
file
messing allowed" limitation.
You'd have to implement a bundle persistence mechanism that works
with
JDO
and a JDO filesystem. Not too hard I think. The challenge probably lies
in
implementing an index storage implementation for lucene that works with
JDO.
agreed. i have never used jdo, but i would guess it doesn't support
RandomAccessFile-like
funtionality (which AFAIK is required by lucene).
however, the most 'challenging' restriction of the google appengine
sandbox is the lack of
thread creation support... this makes it virtually impossible to
deploy infrastructure
apps (like e.g. jackrabbit :(
cheers
stefan
--
Torgeir Veimo
[email protected]
