Amazon Elastic BeanStalk, WAR Files, Hot Reloading - clojure

I love the simplicity of Amazon Elastic Beanstalk.
However it seems rather difficult to hot-reload code. In particular, in reading about the WAR file format (Sun), it states:
One disadvantage of web deployment using WAR files in very dynamic
environments is that minor changes cannot be made during runtime. Any
change whatsoever requires regenerating and redeploying the entire WAR
file.
This is bad. I like to program in Clojure, which involves lots of testing / code reloading.
My question: what is the right way to to hot code reloading in Amazon Elastic Beanstalk?
Thanks!

Do your development on a local instance of Tomcat, an IDE like IntelliJ will automatically update your changes. Once you have reached a reasonable milestone, e.g. completed a story, then redeploy your war.

I ended up giving the Amazon Elastic Beanstalk route, and just ended up setting EC2 instances.

The tomcat installation on the ami's created via elastic beanstalk have hot reload turned off. #Rob's answer would be the way to go. I'm not sure why you'd want to do it any other way, to be honest.

Related

How can I deploy to Elastic Beanstalk using git pull instead of uploading the whole repo

Right now I'm using eb deploy to deploy an application to Elastic Beanstalk. However the upload process is relatively slow. I was wondering if it's possible to get Elastic Beanstalk to run git pull so that it's downloading the latest set of diffs instead of uploading the entire repository each time.
This is not possible.
You could however set up a separate environment that does a git pull every so often and deploys to beanstalk if there are changes.
The upload should be fairly quick instance to instance.
My suggestion would be to setup a clean Continuous Integration process using something like CodeShip or some other SaaS Service. Usually you can do this for free and it provides nice Continuous Delivery deployments straight to Elastic Beanstalk and a lot of other services.
I have written about it recently here and here to specifically do what you're aiming to accomplish.

How to sync Wordpress plugins between instances deployed with AWS Elastic Beanstalk?

Does anybody know how can I sync the plugins of a Wordpress deployed to AWS Elastic Beanstalk between all deployed instances?
I can easily deploy a Wordpress to EBeanstalk (even AWS give us a template for this) but if I install a plugin, it is installed in only one instance. There's no guarantee that any other user (or even myself) will access that instance again with the autoscaling happening. I already tested it and I could not access it in another instances.
I know the uploads folder will have the same problem, but there are already plugins to sync it with S3.
Thank you!
Research "stateless wordpress". I found a good starting point on Mike Otreva's site. In short, the solution involves building an example AWS Elastic Beanstalk environment and then using GIT to push your WP build. You'll need to set-up up a local Xamp environment in order to be able to GIT push your build. Once you do it this way, you'll never update plugins from the dashboard, instead you'll update your local build and then push the updates to your environment. You might even want to install a plugin that stops all automatic updates. I hope that helps some.

Deploying a war to Elastic Beanstalk with Pallet

I've got a Java servlet packaged in a war, and need to deploy it to Elastic Beanstalk. I can roll my own deployment script using Amazonica, but I'd rather leverage Pallet for this.
A Google search for "pallet elastic beanstalk" is not turning up anything useful, other than a "How to deploy a clojure web application to Amazon EC2" question on Stack Overflow. The answer looks quite promising, but it doesn't cover setting environment properties, and I'm not sure whether that group spec would create an Elastic Beanstalk environment or a regular EC2 one with Tomcat.
Has anyone done this? Is there a nice blog post or recipe for it?
Just to be clear, the war itself is not a Clojure app, it is just a war built with Maven from a Java project somewhere.
Since this is not an action that happens to an instance, for instance it does not change a member of a pallet group, I would recommend using clj-action to upload it using amazonica at the appropriate place in the phase.
I'm assuming that some instance (or group) you are deploying with pallet needs this web service to be in place so it can be configured to connect to it. In cases like this it would make sense to define a phase which uploads the war file and saves its configuration into the session. Then later phases on any instance in the deployment can see where the web service is available.
If it's only needed by one instance/group then it's fine to simply call amazonica (through clj-action) in the middle of the configure phase and then configure that instance to use the web service in the same plan-fn.

code deployments on EC2

There are quite a few resources on deployments of AMI's on EC2. But are there any solutions to incremental code updates to a PHP/Java based website?
Suppose I have 10 EC2 instances all running PHP / Java based websites with docroots local to the instance. I may want to do numerous code deployments to it through out the day.
I don't want to create a new AMI copy and scale that up to new instances each time I have a code update.
Any leads on how to best do this would be greatly appreciated. We use subversion as our main code repository and in the past we've simply done an SVN update/co when we were on one to two servers.
Thanks.
You should check out Elastic Beanstalk. Essentially you just package up your WAR or other code file, upload it to a bucket via AWS's command line/Eclipse integration and the deployment is performed automatically.
http://aws.amazon.com/elasticbeanstalk/
Elastic Beanstalk is exactly designed to do this for you. We use the Elastic Beanstalk java/tomcat flavor but it also has support for php, ruby, python environment. It has web console that allows you to deploy code (it even keeps history of it), it also has git tool to deploy code from command line.
It also has monitoring, load balancer, auto scaling all built in. Only a few web form entries to control all these.
Have you considered using a tool designed to manage this sort of thing for you, Puppet is well regarded in this area.
Have a look here:
https://puppetlabs.com/puppet/what-is-puppet/
(No I am not a Puppet Labs employee :))
Capistrano is a great tool for deploying code to multiple servers at once. Chef and Puppet are great tools for setting up those servers with databases, webservers, etc.
Go for a Capistrano . Its a good way to deploy your code on multiple servers .
As already mentioned Elastic Beanstalk is a good option if you just want a webserver and don't want to worry about the details.
Also, take a look at AWS CodeDeploy. You can have much more control over the lifecycle of your instance and you'd be looking at something very similar to what you have now (a set of EC2 instances that you setup). You can even get automatic deployments on instance launch with Auto Scaling.
You can either use Capsitrano or TravisCI.

Work-around for not being able to deploy multiple applications to a single EC2 instance using AWS Elastic Beanstalk?

We have a web app running using AWS Elastic Beanstalk (via Visual Studio 2010).
We now want a second site on the same server for development and presentation
purposes. I want to point to the new location for continuous deployment. Once
we are happy, I want to switch back to the original (production) destination.
I have been doing some reading online and it looks like having two sites
running on the same instance is not possible using Elastic Beanstalk?
We are currently running under the free tier and are trying to squeeze every penny
we can. Having to throw up another instance to host our pre-production environment
will halve the time we have allocated for free tier usage.
Any ideas?
It's not clear what exactly you want to do from your question. Elastic Beanstalk makes it very easy for you to roll back and forth between versions of your application. You can also easily terminate and recreate environments fairly quickly. If you don't need your "production" destination 100% of the time, couldn't you just shut it down when you're not using it?