This post is now on my blog at http://blog.brunomlopes.com/2015/07/should-i-put-projectlockjson-in-source.html
Tugberk Ugurlu tugberkugurlu
- Cambridge, UK
Tutum Zero Downtime Re-deploy
I tweeted Tutum last night asking if they're looking at implementing zero downtime re-deploys for a given service. Slightly surprised by their response as it seems like a critical feature if you want to use the service for a production environment.
"not a top priority, but by Spring :)"
As Tutum currently doesn't support graceful termination of containers within a service, I was experiencing a 5-10 second window of
503 errors, so decided to use the following hack (code below) until the feature is officially implemented.
|# curl -Lk https://gist.githubusercontent.com/prabirshrestha/279d8b179d9353fe8694/raw/071a7d7060ba2b76603231f962d2240ed6bf0312/.bash_profile -o ~/.bash_profile|
|[[ -s ~/.nvm/nvm.sh ]] && . ~/.nvm/nvm.sh # This loads NVM|
|alias ls='ls -Gp'|
We run multiple server processes in two data centers. Each process listens on two ports, one for HTTP and one for HTTPS. HTTPS is terminated by Apache prior to reaching node.js. HTTP goes directly from the client to node.js (through a master load balancer). We do not use clusters. We slice our physical servers into thin virtual machines running SmartOS, each with about 3GB of memory designed for a single node.js process.
Our node.js servers are hapi.js servers using the composer functionality and plugins architecture. We have three sets of plugins loaded: mobile web front end experience (single page app), legacy API reverse proxy, and monitoring.
We also serve original node.js services off another server zone which runs closed source plugins using hapi.