Sydjs – Deploying Node.js and Staying Sane

Deploying Node.js
and staying sane

SYDJS 2011-02-16 18:00:00 MICHEIL SMITH

Quick Introduction

Micheil Smith
• An Engineer at Votizen (votizen.com)
• A core contributor to Node.js
• Current Node.js Documentation Lead
• Author of ‘node-websocket-server’
• Twittter: @miksago
• Email: micheil@votizen.com


What is Node.js

• Evented I/O For V8 JavaScript
• http://github.com/ry/node
• http://nodejs.org


In other words, you can build
some really awesome shit.


BUT!


Deployment can be an
utter pain in the ass.


Why?


• Git based deployment honestly sucks
• Existing solutions do work, but aren’t perfect
• Rolling it ourselves is too much work


Git based deployment
honestly sucks
• Having multiple remotes isn’t much fun
• Repositories become out of sync
• Writing post-receive hooks is awful
• Can only really push to one server at a time


Existing solutions do
work, but aren’t perfect
Existing tools require you to work outside of
JavaScript & don’t integrate with the node.js
ecosystem.


Rolling it ourselves is
too much work
Nobody honestly wants to spend heaps of time
writing stuff just so they can get their code into
production.


A Way
Forward


Look, Learn, Create
• Other platforms have solutions
• What do we need in deployment?
• NPM exists, make use of it


Other platforms have
solutions
Java: CruiseControl
Ruby: Capistrano, Bundler
Twitter: Murder
Python: Fabric


What do we need in
deployment?
• Simple Configuration
• Versioning & Rollbacks
• Logs (well, duh, right?)
• Integration with NPM


NPM exists, make
use of it
NPM is great:
• It’s in the background
• It can handle a lot of the hard work
• Package.json ﬁles are great, use them


The
Proposal


`npm install deploy`
The idea is to have a tool that:
• Doesn’t require too much setup
• Makes use of existing standards & extends them
• Doesn’t get in the way; you can do without it
• Stand-alone, not part of an existing tool


How’s it work? (part 1)

• Made up of two components:
• client-side CLI
• server-side daemon


How’s it work? (part 2)
Client-side: (Developer side)
• The application directory has a deploy.json
• A user or global .deployrc file

Server-side:
• A daemon for accepting deploys is running
• A global .deployrc file


deploy.json
Much like package.json, but contains:
• which servers to deploy to
• any dependencies that can’t be found on NPM
• any scripts to be run at different phases of
deployment
• location of the source code repository


Example
{
"name": "brandedcode-blog",
"repository": {
"type": "git",
"url": "git@github.com:miksago/brandedcode.git",
"path": "./blog"
},
"servers": [{
"host": "blog.brandedcode.com",
"port": 49700,
}],
"dependencies": {
"brandedcode-common": {
"type": "git",
"url": "git@github.com:miksago/brandedcode.git",
"path": "./brandedcode-common"
}
},
"scripts": {
"deploy": "scripts/deploy.js"
}
}


Server-side .deployrc
A json ﬁle, telling the daemon the following:
• where to place code for certain sites
• users from which to accept deploys
• various other conﬁguration


Example
{
"users": {
"micheil": {
"salt": "...", "password": "..."
},
"mikeal": {
"salt": "...", "password": "..."
}
},
"servers": {
"brandedcode.com": {
"users": ["micheil"],
"path": "/home/micheil/sites/brandedcode.com/"
},
"thenoded.com": {
"users": ["mikeal", "micheil"],
"path": "/home/deploy/sites/thenoded.com/"
}
},
"daemon": { "port": 4970 }
}


The server-side daemon

• A thin node net.Server
• Uses a protocol similar to netstrings + json
• Uses gzipped tarballs to transfer files
• Maintains logs and handles user management
• Could use alternative file-transfer methods


When?


Not yet.

Over the next few months.

https://github.com/votizen/deploy


Other issues in deployment

• Ensuring your server is always up
• Managing settings & configuration
• Binding to privileged ports but not running as root?


Ensuring your server is
always up
• Use the tools that come with your OS, eg:
• Ubuntu has upstart
• Solaris has SMF
• Debian has Sysvconfig (can probably get Upstart)

• Monitor your processes
• Just to keep resources in check really.

Managing settings &
configuration
A few options available on the modules wiki page:

https://github.com/ry/node/wiki/Modules


Another way for Settings
Management
• Keep settings & commonly done stuff as a central
module.
• Use something like settings.js:
• https://gist.github.com/824688

Ask me after the talk and I can go into further detail


Binding to privileged ports
but not running as root?
• Fairly easy to do with Node:
• first start with a umask of 007
• bind to the privileged port
• use process.setgid() and process.setuid() to drop
down privileges


Thanks for
listening


• Votizen.com
• Twittter: @miksago
• Email: micheil@votizen.com


Any
thoughts or
questions?

Sydjs – Deploying Node.js and Staying Sane

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (7)

Similar to Sydjs – Deploying Node.js and Staying Sane

Similar to Sydjs – Deploying Node.js and Staying Sane (20)

Recently uploaded

Recently uploaded (20)

Sydjs – Deploying Node.js and Staying Sane

Editor's Notes