Added by Erik Drolshammer, last edited by Erik Drolshammer on Mar 25, 2009  (view change)

Labels:

deployment deployment Delete
rpm rpm Delete
Enter labels to add to this page:
Wait Image 
Looking for a label? Just start typing.

Strategy 1: add war archive to a pre-installed webserver

Typically multiple webapps in one instance of WebSphere, Weblogic, Tomcat (or Jetty).
cargo-maven-plugin?
was-m-p?
etc.

Distribution as war or ear.
Requires a preconfigured webserver.
Probably not easy to automate, since you cannot know upfront which webapps will be running there.
Possible to use JNDI and share resources etc.

It should be possible to use the dependency functionality of RPM together with yum to let jetty rpm be a transitive dependency of the webapp. This seems like a good idea, since we can then let Mortbay maintain the jetty rpms while still get full automation.

Strategy 2: Bundle a lightweight servlet container with the distribution

Reduce complexity, since each webapp can be configured and deployed in isolation from the rest. Easiest to fully automate.

Wanted status

Automated installation/deployment of servlet container
Automated configuration of servlet container
Automated deployment of war file
Automated upgrade of servlet container
Automated upgrade of app
Automated removal of servlet container and app

Proposed solution

Bundle jetty + jettyConfig + appConfig + war file in a rpm.

Example: archiva

  • Install jetty as a standalone servlet container
    • it's not installed, just laid out in a directory with jsw and ready to go
    • minimal jetty is start.jar and jetty.jar
  • Add/change configuration if needed
    • Separate jetty config from webapp config.
  • Dump the war file into jettys hotfolder
  • Add symlinks to start scripts or the actual scripts to /etc/init.d to make the webapp start at boot.

Questions

When is each strategy appropriate?

Advantages and disadvantages of each?

Comments  (Hide Comments)

From Johannes:
I've done similar stuff in the past and would welcome any progress in this area. I don't know if my requirements are relevant for your situation, but here's what I've done.

My requirements

  • One (or in worst case, two) deployed artifacts
  • Max two commands to install in a new environment
  • Max one command to upgrade and restart an existing installation
  • Able to have multiple installations for a single user on the same host for more agility in terms of test environments
  • Requirements for server: Only base OS (Linux, Solaris, OS X, Windows support) and Java JRE.
  • Support (at least via scripting) to pull down the latest version from the repository with cron for continuous deployment (maybe not needed)
  • As an advocate for this sort of deployment, I want install on Windows without anything weird installed, so I can demonstrate the technology in many settings
  • Externalized and standardized configuration. The most important things to externalize is the port and database connection settings.
  • Standardized logging configuration and log files that survive upgrades
  • Very little code in the Maven modules for the project, so that the solution appears industrialized and standardized

The strategies I've used are somewhat different from the strategies you describe:

  1. ZIP-file with Jetty JAR, WAR files, configuration files + a script for installing and upgrading and another script for starting, stopping, and restarting. Created with appassembly-maven-plugin and maven-assembler-plugin. This didn't work properly on Windows, even with Cygwin (mainly due to symlinks).
  2. Executable JAR created with onejar-maven-plugin. The JAR-file contains Jetty JAR, WAR files and configuration, and unpacks itself to temp directory on execution. This worked on Windows. The main problem was that it required lots of magic bootstrapping code in a separate project.
Posted by Erik Drolshammer at Mar 10, 2009 08:10

From Totto:

I´m more in the BootstrapDaemon, ProvisioningConfigService and mobile services (jupp.. Jini and JavaSpace - master-worker) ballpark... In this scenario it kinda turns into BootStrapDaemon and WebStartURIProviderService and pull-deployment... but then I´m a "Java IS the platform" kinda guy

Keep up the good work - admins will love you forever

Posted by Erik Drolshammer at Mar 10, 2009 08:11
All content on this wiki is licensed under a Creative Commons Attribution 3.0 Unported License.