A requested loooooong elaboration.
Assumes one has looked at Java Service Wrapper and somewhat familiar with it's basic workings.
As indicated SBT has already published my app into a Maven / Nexus internal repository. This is the binary artifact repo which also contains imported third party libraries.
Say on my target PROD deploy node I have roughly the following directory tree with the "bootstrap" files itemized below which we provision them onto a virgin box "automagically" (details elided).
/myapp
/bin
/conf
/bin
/lib
In my /bin directory are 2 files. wrapper and myapp
- wrapper: is a exe used by Java Service Wrapper. Window/Linux/Mac 32/64 bit native.
- myapp: Is a renamed out of the box bash script again from Java Service Wrapper.
So both of these are "generic", application agnotic and are never touched (nor is sbt-launch.jar).
In my conf directory: myapp.conf, myapp.launch and wrapper.conf
- myapp.conf is a standard "configgy-like" configuration file for your app.
- myapp.launch is the sbt-launcher config file.
- wrapper.conf the Java Service Wrapper configuration file.
./lib has two jars
- sbt-launcher.jar #generic
- wrapper.jar #generic
myapp.launch contents are a pretty obvious sbt-launch configuration.
[scala]
version: 2.9.0-1
[app]
org: odp
name: myapp
version: 2.0.86
class: com.myapp.MainXsbti
components: myapp
cross-versioned: true
resources: ./conf
[repositories]
# URL to my internal Nexus repo which contains EVERYTHING necessary.
[boot]
directory: ./lib
[log]
level: info
Mark H added the resources: property for me a while back. This is appended to the classpath of the class loader minted by sbt-launch lto run/aunch myapp's main(). This resources myapp to find "resources" such as logback.xml and myapp.conf the app's configgy file.
wrapper.conf is Java Service Wrappers standard conf file. In general all your JVM command line arg stuff is in there, heap sizes, ping monitoring etc.
So that is a base bootstrap. One could imagine say a naive ssh/scp + script to create the dir tree and copy over the few files. That would reduce the bootstrap to Linux box with Java installed, a generic "deploy" account + ssh key pair + 1 bash script. We do something a bit more sophisticated, but you get the idea. Just get the above over 1-time to provision a virgin node. Paul's conscript approach works as well. Many cats with skins.
To manually start the app (again never manually start PROD but automate the invoking of the below).
- Edit myapp.launch to the desired application version to deploy, say 3.4.34
-
./bin/myapp start
Whew... pauses to take a breather.
What happens...
- generic Service Wrapper bash shell "myapp" is run with "start" arg.
- this runs the wrapper binary.
- which reads all the ./conf/wrapper.conf file for JVM config stuff etc.
- which launches a "nanny" jvm and a sbt-launcher jvm which ultimately runs myapp
- sbt-launcher now ...
- pulls down all necessary jars, compiler lib, 3rd party, the whole 9 yards from the Nexus repo into ./lib
- and finally sbt-launch puts together a classloader with all the newly downloaded app jars and deps and runs myapp's main ().
- since its all local copied once a version is deployed, even if you "lose" the Nexus repository any local cached myapp version can be run.
All of this is out-of-box functionality driven by config files.
Before this gets tooooo looooong. Your main is something like this.
Main () is a nested doll of Service Wrapper's main() wrapping, SBT launchers main() wrapping MyApp's main().
object Main {
---
// allows for standard command line launch
def main (args: Array[String]): Unit = {
Init.initialize (args)
}
}
class MainXsbti extends xsbti.AppMain with Logging {
....
def run (launchConfig: xsbti.AppConfiguration) = {
class Exit (val code: Int) extends xsbti.Exit
...
Main.main (launchConfig.arguments)
...
new Exit (0)
}
}
Java Service Wrapper offers various levels of main() wrappers as well which offer tighter coupling to the monitoring nanny etc. So you could get a nested doll of MainWapper ( MainXsbti (MainMyApp))). Depends how fancy your tap dance is.
Ok that's the quick and dirty. We use paxos to ensure we don't get split-brain deployments, a guaranteed oracle of truth on what the "true" version a node should be running (if you are not running the correct version you don't join the cluster). Somewhat along the lines of say using ZooKeeper to hold the correct app version and other config values. One could eliminate most of (all) the config files.
Ray
On Wed, Jun 29, 2011 at 6:17 PM, Jason Zaugg
<jzaugg <at> gmail.com> wrote:
Am Mittwoch, 29. Juni 2011 23:26:51 UTC+2 schrieb Ray Racine:
In a very similar vein, one can use sbt-launcher as a deployment system.
We've been using the sbt-launcher for application deployment for a long time and it has worked out really well.
Can you elaborate? What command line and config file(s) do you use to get sbt-launch.jar to run your application?
-jason
--
You received this message because you are subscribed to the Google Groups "simple-build-tool" group.
To view this discussion on the web visit https://groups.google.com/d/msg/simple-build-tool/-/4_JYgFa3ByIJ.
--
You received this message because you are subscribed to the Google Groups "simple-build-tool" group.
To post to this group, send email to simple-build-tool <at> googlegroups.com.
To unsubscribe from this group, send email to simple-build-tool+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/simple-build-tool?hl=en.
RSS Feed