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 protected]> wrote: > On Wed, Mar 4, 2015 at 4:01 PM Paul Hoadley <[email protected]> wrote: > >> Hi John, >> >> On 5 Mar 2015, at 7:13 am, John Huss <[email protected]> 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. > > John > > >> >> -- >> Paul Hoadley >> http://logicsquad.net/ >> >> >>
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
