Re: first version of deployment config scripts for Ubuntu/AWS
Re: first version of deployment config scripts for Ubuntu/AWS
- Subject: Re: first version of deployment config scripts for Ubuntu/AWS
- From: John Huss <email@hidden>
- Date: Thu, 05 Mar 2015 15:42:34 +0000
Oh, I should say also -- I have a Play 2 app running on beanstalk deployed inside a docker container also. Play provides built-in support for building a docker image. However, it is not complicated to do yourself (with WO for example)
.
I still have some other WO apps running internally outside of amazon. When the container server is out of beta I plan to move them to amazon. They use EOF and are database-heavy, so many app instances are required in order get a reasonable number of database connections. With a WAR deployment many instances means many machines, which is more expensive than necessary compared to running multiple instances on a single machine -- which is what the container service allows you to do.
On Thu, Mar 5, 2015 at 9:31 AM John Huss <
email@hidden> wrote:
On Wed, Mar 4, 2015 at 4:01 PM Paul Hoadley <
email@hidden> wrote:
You're missing out big time using the traditional deployment model on AWS. If you instead use an deployment model that includes an elastic load balancer you get a ton of benefits:
1) it automatically replaces dead instances.
2) it can automatically scale up if needed
3) lots of free monitoring graphs, etc
4) highly available = the load balancer never fails (unlike wotaskd and pals)
For simplicity I recommend using elastic beanstalk and deploying a WAR file. But you could also build a docker image and deploy a traditional app instead (using beanstalk), but without the cruft of wotaskd and javamonitor.
In the long term - the AWS container service is in beta and allows deploying docker images across a fleet of EC2 instances. This the best model for deploying WO apps since you typically want to have multiple app processes running on each machine rather than a single monolithic process (which is what WAR deployment gives you).
Are you doing any of this in practice? How do you handle session persistence?
Yes, I have a very high traffic WO app deployed this way -- but it is purely web services and _javascript_, no components. It used EOF originally, but now uses Cayenne instead.
I have another app which is a more traditional one with many pages deployed this way as well, but it is not really in use yet. It has passed testing and works well.
I'm not doing session persistence. My web service/_javascript_ app doesn't use sessions; the other app does. The elastic load balancer supports sticky sessions, so sessions are routed to the same instance. This isn't ideal for many reasons but it is the same thing you get with a traditional deployment, so it's not a point for or against anything.
It's easy to get started with a WAR deployment - the only thing you have to do that isn't built-in is to put your web service resources in the WEB-INF/static folder and set the base url for them. The standard build.xml file should be changed to do this automatically, but no one maintains wolips anymore.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden