2. Why Vagrant?
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
operating system.
Open source and mature. Around since 2010.
3. 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
transfer.
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
machine.
https://github.com/mitchellh/vagrant-aws
https://github.com/10thmagnitude/vagrant-azure
4. Installing Vagrant & VirtualBox
Install Vagrant here:
http://www.vagrantup.com/downloads.html
Install VirtualBox here:
https://www.virtualbox.org/wiki/Downloads
Cloud boxes are automatically downloaded and
installed with Vagrant 1.5+
Be sure to upgrade Vagrant if you have an older version.
5. Configuration Management via Chef
Idempotent
You can run Chef multiple times on the same system with
identical results.
Not the case with shell scripts: running more than once will
usually lead to unpredictable results.
Cross-platform
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
infrastructure.
6. Docker, Packer, etc: More DevOps
DevOps tools appear daily.
Chef alternatives: Puppet, Ansible, Salt, etc.
Docker.io
Promising tool that contains and virtualizes processes.
Think of Vagrant but for a specific process.
Example: turn a server application into a portable image.
Packer.io
Automates creation of machine images.
A meta layer above a tool like Vagrant.
7. Mathoid using Vagrant
https://github.com/cbumgard/mathoid-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.
8. Mathoid + Vagrant continued
All configuration done in the Vagrantfile:
https://github.com/cbumgard/mathoid-
vagrant/blob/master/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
provisioning.
9. 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
provision”
Vagrant commands you should learn:
init, up, ssh, suspend, resume, halt, destroy
reload: halt + up
10. Vagrant: continued
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
setup.
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:
https://gist.github.com/GUI/2864683
11. Vagrant: continued
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.
12. Node.js: Lessons Learned
Node.js runs all Javascript code on a single thread.
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.
13. 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.
http://gruntjs.com/
http://bower.io/
Yeoman generators are a great way to bootstrap a project:
http://yeoman.io/
Daemonize your app with tools like forever:
https://github.com/nodejitsu/forever
14. 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:
http://www.commonjs.org/specs/modules/1.0/
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.
15. Thanks!
Chris Bumgardner
https://github.com/cbumgard
https://www.linkedin.com/in/chrisbumgardner
Please don’t hesitate to contact me