Skip to content

NDM #4

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
piranna opened this issue Jul 18, 2014 · 12 comments
Open

NDM #4

piranna opened this issue Jul 18, 2014 · 12 comments

Comments

@piranna
Copy link
Contributor

piranna commented Jul 18, 2014

https://github.com/npm/ndm

Seems it could integrate really well with NodeOS services... or maybe also reemplace it (at least at the user administration level) :-)

@seanewest
Copy link

I'm really into this idea. It would make NodeOS more minimal and would encourage package authors to publish services that would work across different OS's (ndm currently supports Mac, Ubuntu, and CentOS).

I currently have a PR in ndm to allow for global npm packages to be used directly as services. I think that would make this a more viable solution.

Maybe then NodeOS could just use npm proper and supplement it with ndm:

npm install -g <package>
ndm <cmd> -g <package>

@piranna
Copy link
Contributor Author

piranna commented Aug 4, 2014

Yes @seanewest, that's just my idea, install services with NPM and manage them with NDM :-)

@seanewest
Copy link

ndm recently got an upgrade. Here's how things might look if we swapped npkg for npm+ndm:

Installing Packages

Global packages can be installed with the familiar npm install -g which installs directly to $HOME/lib/node_modules. I would think this could be pulled off by setting the node prefix to $HOME.

Service Management

ndm install PACKAGE

This will start and daemonize a service directly from a global or local package. Local packages live in the node_modules directory that you are in (or of a parent directory). Global packages are resolved under $HOME/lib/node_modules.

ndm comes with a bunch of other subcommands that allow you to manage these services:

ndm remove PACKAGE
ndm start PACKAGE
ndm stop PACKAGE
ndm restart PACKAGE
ndm list-scripts PACKAGE
ndm run-script PACKAGE

Programmatic API

Control services programmatically:

ndm = require('ndm')('PACKAGE');
ndm.install();
ndm.remove();
ndm.start();
ndm.stop();
ndm.restart();
//...

@bcoe
Copy link

bcoe commented Aug 12, 2014

@seanewest I feel like the biggest difference between ndm and npkg is ndm's requirement for a service.json.

I use the service.json for npm Enterprise, which consists of several services which work in conjunction -- a service.json makes sense for this use-case. Perhaps, for the simpler single-service-use-case, we could have ndm fall back to looking for fields in the package.json?

I think switching out npkg for ndm could potentially be a great way for us to pool our resources @groundwater.

@piranna
Copy link
Contributor Author

piranna commented Aug 12, 2014

Perhaps, for the simpler single-service-use-case, we could have ndm fall
back to looking for fields in the package.json?

+1

@bcoe
Copy link

bcoe commented Aug 12, 2014

npm/ndm#60

@piranna
Copy link
Contributor Author

piranna commented Aug 12, 2014

I've review the NDM code and its mechanism is really simple, just only creates scripts to be exec by system service daemon. NodeOS doesn't have any of them, only the API of init. I find it better to have an API that a bunch of System V init files :-P so maybe NDM could wrap the scripts creation mechanism in an object, and calling its methods internally create the scripts or call the NodeOS init API.

@bcoe
Copy link

bcoe commented Aug 12, 2014

@piranna, @rmg also suggested exposing service script generation as an API rather than simply templates.

@bcoe
Copy link

bcoe commented Aug 14, 2014

I've refactored ndm so that it will look for fields in a sevice.json file before looking for a package.json:

npm/ndm#62

Here's a library that's been updated to run with ndm:

https://github.com/bcoe/thumbd/blob/master/package.json

Essentially, you can now have the service stanza in your package.json, which works something like this:

{
  "name": "thumbd",
  "scripts": {
    "start": "node ./index.js"
  },
  "service": {
     "args": ["arg1", "arg2"],
     "env": {
          "PORT": {"description": "HTTP port", "default": "8000"},
          "USER_UID": "ubuntu"
      }
  }
}
  • name is used for service name.
  • scripts.start is used for the entry point of he service.
  • service.args/service.env can be used to give hints about values the user must provide to run the service.

@piranna
Copy link
Contributor Author

piranna commented Aug 14, 2014

Shouldn't it be just the opposite, first look for service.json and if it's not found, looks for the service field?

@bcoe
Copy link

bcoe commented Aug 14, 2014

@piranna you're correct, I just had it reversed in the comment. It goes service.json which is useful for describing multiple-service dependencies, then package.json which makes sense for describing a single service.

@piranna
Copy link
Contributor Author

piranna commented Aug 14, 2014

You are welcome :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants