search

cloudius-systems / capstan

Capstan, a tool for packaging and running your application on OSv. http://osv.io/capstan
Other
363 stars 82 forks source link

Running an application without Capstanfile #82

Open penberg opened 10 years ago

penberg commented 10 years ago

We could have something like:

$ capstan run app.war

and have Capstan detect that it's a WAR file and pull a base image that has a servlet container like Tomcat in it.

tzach commented 10 years ago

How would Capstan knows which servlet container to pull? there can be more than one Other containers may expect the WAR file in a different location

This remind me of buildpacks, which are design for similar function: define runtime support for your application https://devcenter.heroku.com/articles/buildpacks

nyh commented 10 years ago

On Mon, Apr 28, 2014 at 5:26 PM, Tzach Livyatan notifications@github.comwrote:

How would Capstan knows which servlet container to pull? there can be more than one Other containers may expect the WAR file in a different location

We more-or-less solved this in the "modules" infrastructure, and Capstan should follow suite.

Namely, you need to define a feature name, say "war-runner". A "war-runner" is any package which knows how to run a war you put in /war (or whatever). We can then have two modules, jetty and tomcat which both "provide" this war-runner. Running a war "requires" war-runner. Now, somebody can build an image from jetty plus a war, or an image from tomcat plus a war - or if you try just a war without specifying either tomcat or jetty, it requires "war-runner" - which may either complain that one wasn't chosen, or bring up a default choice (say, tomcat).

I don't know what Capstan is planning to do similar to these "provides" and "requires" feature. Perhaps use the similar capabilities of RPM?

This remind me of buildpacks, which are design for similar function: define runtime support for your application https://devcenter.heroku.com/articles/buildpacks

Reply to this email directly or view it on GitHubhttps://github.com/cloudius-systems/capstan/issues/82#issuecomment-41564279 .

Nadav Har'El nyh@cloudius-systems.com

dorlaor commented 10 years ago

On Mon, Apr 28, 2014 at 5:51 PM, nyh notifications@github.com wrote:

On Mon, Apr 28, 2014 at 5:26 PM, Tzach Livyatan <notifications@github.com

wrote:

How would Capstan knows which servlet container to pull? there can be more than one Other containers may expect the WAR file in a different location

We more-or-less solved this in the "modules" infrastructure, and Capstan should follow suite.

Namely, you need to define a feature name, say "war-runner". A "war-runner" is any package which knows how to run a war you put in /war (or whatever). We can then have two modules, jetty and tomcat which both "provide" this war-runner. Running a war "requires" war-runner. Now, somebody can build an image from jetty plus a war, or an image from tomcat plus a war - or if you try just a war without specifying either tomcat or jetty, it requires "war-runner" - which may either complain that one wasn't chosen, or bring up a default choice (say, tomcat).

I don't know what Capstan is planning to do similar to these "provides" and "requires" feature. Perhaps use the similar capabilities of RPM?

Seems like it's a combination of Capstan and the module system. There are also buildpacks by CloudFoundry. It certainty requires investigation.

However, for running simple jar we could use a Capstan file but I was interested in the most simple command line scenario where you only have one liner and ZERO files/config.

Even if one day we'll implement buildpack, the above would still be interesting. Buildpack should be a different git hub issue

This remind me of buildpacks, which are design for similar function: define runtime support for your application https://devcenter.heroku.com/articles/buildpacks

Reply to this email directly or view it on GitHub< https://github.com/cloudius-systems/capstan/issues/82#issuecomment-41564279

.

Nadav Har'El nyh@cloudius-systems.com

Reply to this email directly or view it on GitHubhttps://github.com/cloudius-systems/capstan/issues/82#issuecomment-41567492 .