Hello there, today we are going to talk a bit about provisioning machines and VMs. The idea of this blog post is to show you some ways that can make it easier to develop, deploy and ramp-up new people on your team.
So what is machine provisioning?
All projects have their own dependencies -- having background services running, languages, jdks and web servers. Sometimes, the steps to get a program running on a new machine are not documented and depend on trial and error.
And then you just when you start installing your app, it misses the lib to compile the postgresql extension gem. And then you install it, but you forget to compile ruby with the latest patch installed. And it goes on and on, until you finally get your system running.
Martin Fowler calls such machines that are provisioned and built manually as Snowflake machines. They are not backed up, and if you have a disk failure, it will be a lot of work to get the project running again on another machine.
The provisioning process is a set of executable steps that can be applied to an initial system image to get everything configured. This set of steps brings advantages like being repeatable on a production environment and documents the required procedures that are executable.
As of today, there are a series of tools to provision your machine, each of them with its benefits and peculiarities. It is worth taking a look at Chef, Puppet, Ansible and Salt.
Some information about Puppet
Puppet is a tool that allows you to abstract specific concepts of the target machine and make the configuration process more operating system agnostic.
It allows you to install a package or run a background service on startup, independent of the program you will use on your system (brew, apt, yum, pacman or init, upstart, systemd)
With Puppet you can define the commands it will need to run, packages that need to be installed, step dependencies, file content and everything else you would need to get the machine up and running without problems.
An example of a Puppet file to configure a set of dotfiles can be found here.
The project uses its own declarative language and has a host identification scheme. You can define the steps that will be required to run on the target machine depending on different variables -- hostname, IP number, amount of memory, disk size and so on.
The identification schema can be extended externally, which allows clustered and distributed systems or master-slave services to be defined externally.
A set of computers can be configured differently on production, with the web servers on faster machines and file servers on machines with more storage.
Bringing the cloud to the developer's machine
The development environment can also benefit from the cloud. Using a combination of Vagrant and Puppet, the local development computer can look very similar to production, with the same OS and setup as in prod.
The difference between the deployed environment and development environment decreases, and it also allows you to use another system to place your development tools (Windows, Mac, Linux with the app running on a VM)
Imagine the happiness of someone new on the team being able to run a command to get everything needed to setup the application and be ready to code!
More about Vagrant
Vagrant is a project that helps the spawning of virtual machines. It started as an abstraction of the command line of VirtualBox, something similar to a Gemfile for VMs.
You can choose the base image to start with, networks, IP, shared folders and put it all in a file in a way that anyone can reuse to spawn the same configured machine.
Vagrant has different extensions, provisioning options and VM providers. You can run a VirtualBox, VMWare and it is extensible enough to be able to create instances on EC2.
To start using it, install the package and install VirtualBox (I haven't used it with a different provider yet). This documentation will help get your initial Vagrantfile setup.
Baseline: a sandbox for developers with batteries included
Baseline is a tool that with a command line will get you a VM with an initial environment set to start coding in the your requested language.
Let’s say that you want to learn more about Scala. Using a simple
baseline up scala you can get a VM with Java, Scala and the sbt installed and ready to go.
The contents of the folder that you run
baseline init will be shared, which means that you can contribute to any other repo with a simple
git pull and a
baseline up. No need to install any other thing on your host machine.
The complete list with all the environments supported is here and it includes ruby, nodejs, mongo and redis, among others.
I hope you like these ideas. Do add a comment with your feedback.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.