Node.js with Vagrant and Chef
April 24, 2014
Speed and Portability
Get a working uniform development environment
running in about 15 minutes while getting a coffee.
This often takes hours or days for a modern environment
getting specific libraries, tools, and versions for a specific
Open source and mature. Around since 2010.
Advantages to a VM Image
Vagrant is small: just text files in source control
A snapshot is typically around 0.5GB – 1GB. Hard to host and
A snapshot is binary: changing a version of a library is hard,
but in Vagrant it is just a configuration change.
Abstraction: Vagrant can run on top of different providers,
such as AWS, Docker or Azure in addition to a local virtual
Installing Vagrant & VirtualBox
Install Vagrant here:
Install VirtualBox here:
Cloud boxes are automatically downloaded and
installed with Vagrant 1.5+
Be sure to upgrade Vagrant if you have an older version.
Configuration Management via Chef
You can run Chef multiple times on the same system with
Not the case with shell scripts: running more than once will
usually lead to unpredictable results.
Chef supports Linux, Mac, Windows
Shell scripts are system dependent
Existing ecosystem of cookbooks: don’t reinvent the wheel.
Chef Solo: runs on local machine, does not require server
Docker, Packer, etc: More DevOps
DevOps tools appear daily.
Chef alternatives: Puppet, Ansible, Salt, etc.
Promising tool that contains and virtualizes processes.
Think of Vagrant but for a specific process.
Example: turn a server application into a portable image.
Automates creation of machine images.
A meta layer above a tool like Vagrant.
Mathoid using Vagrant
Once running you can access at localhost:10042
Built on Ubuntu Precise 12.04 64-bit base box. Found 14.04
not compatible yet with Mathoid.
First time you “vagrant up” it has to download the base
box (~300MB). Boxes are cached locally however.
Added Chef cookbooks as Git submodules. Requires just
an extra two commands the first time you clone the repo,
makes for a cleaner repository.
Mathoid + Vagrant continued
All configuration done in the Vagrantfile:
Non-provisioning changes to Vagrantfile, such as
networking configuration, will take effect on a “vagrant
reload” (halt + up).
Provisioning changes will not run unless you destroy and
re-up, or do a “vagrant provision”.
This Vagrantfile is a combination of shell, file, and chef
Vagrant: Things to Note
Pick your base box carefully.
Ideally has the configuration manager (e.g. Chef) installed that you will
use for provisioning.
Avoid anything else if possible. For example a base box with Node.js built
in will be trickier to upgrade to a new version than if you add Node.js as
a Chef cookbook.
You can always see installed boxes via “vagrant box list”
When creating a Vagrantfile test incrementally via “vagrant
Vagrant commands you should learn:
init, up, ssh, suspend, resume, halt, destroy
reload: halt + up
When switching networks on the host (e.g. changing WIFI
networks on your laptop) you may need to “vagrant reload”
for the guest VM networking.
If you want to access files from your host machine inside the
guest vm, be sure to use NFS:true in your synchronized folder
Gives ~10x performance accessing files. Noticeable if running a
webserver like Node.js in the VM on files on your host.
Requires nfs-common installed.
Requires password on “vagrant up”. Fix for that at:
When shell provisioning keep in mind:
Your script is running as root. No need for sudo.
Interactive prompts will hang and timeout. Make sure to add
flags like “-y” to command-line calls like “apt-get”.
You can enable a GUI from the Vagrantfile if you want to do
graphical work in the VM
Provisioning usually requires download files from many
sources: occasionally there will be intermitent problems
downloading from certain sources.
Check out Vagrant Shares. New in 1.5. Allows giving others
outside your local network access to your running machine.
Node.js: Lessons Learned
So you can’t do heavy operations in the JS layer.
Consider message queues or pub/sub like Redis.io
Thinking asynchronously takes getting used to. Learn libraries
like async at the start: https://github.com/caolan/async.
Flow control is very important.
Also greatly helps exception handling.
Control your versioning carefully for dependencies.
Follow semantic versioning: http://semver.org/.
If your versioning isn’t specific enough a deployment can break.
Often best to package dependencies during deployment.
Node.js: Lessons Continued
Amazing ecosystem: always check for an existing npm
module before writing something new.
I strongly recommend Grunt for building your project, and
Bower for client-side web package management.
Yeoman generators are a great way to bootstrap a project:
Daemonize your app with tools like forever:
Node.js: Lessons Continued
Use clustering module: will run a copy of your Node
process on each available core.
Think stateless: in general for web apps, and especially
here so you can scale out.
Follow CommonJS module for code organization:
Don’t expect to share a lot of code between the browser
and the server. However the lack of context switching (all
JS all the time) is the real benefit.
Please don’t hesitate to contact me