Chapter 1. Getting Started with Vagrant

Developing modern web-based applications can be complicated!

The technology behind our projects is becoming more advanced and diverse. Where once projects ran with simply a web server, a database, and a set programming language, now we use tools built in a variety of different languages. We use components and dependencies that need to be installed, and their managed versions, and often projects need to run across multiple machines.

Different projects have their own requirements and dependencies, which are often incompatible with one another. A legacy project might require a specific version of PHP or specific versions of extensions for Apache, whereas another project might require a newer version of PHP and running on Nginx. Project switching in this scenario is not easy.

Often, we need to work with teams of people, some of which might be using their own equipment, working remotely, and contractors. This requires you to ensure that everyone runs the same development environment, regardless of their own system and its configuration, the infrastructure changes for projects are tracked and made available to the team, and the project setup is fast for new team members.

Combining these three factors and setting up traditional development environments is becoming more difficult, less relevant, and less helpful for developers.

As projects get more complicated, it's also easy for auxiliary configurations to be forgotten about. Background workers, message queues, cron jobs, and multiserver configurations need to be managed, distributed to the entire team, and then when the time comes, applied to the project when it gets deployed into a production environment.

Virtualized development environments can help with this. Instead of having to battle configurations when working on other projects, each project can simply have its own virtualized environment. It can have its own dedicated web server, database server, and the versions of the programming language and other dependencies it needs. Because it is virtualized, it doesn't impact on other projects; just shut it down and boot up the environment for the other project.

With a virtualized environment, the development environments can also mimic the production environment. You don't need to worry about whether something will work when it gets deployed, if it is being developed on a machine with the exact same software configuration. Even if you deploy on a Linux machine but develop on Windows, your virtualized environment can be Linux, running the same distribution as your production environment.

While a virtualized environment makes different projects and their dependencies easier to manage and separate, they are not the easiest of things to configure and manage. They still need to be configured to work with the project in question, which often involves some level of system administration skills, and we need to connect to these environments and work with them. They also, by design, are not very portable. You need to export a large image of the virtualized environment and share that with your colleagues, and keeping that image up to date as projects evolve can be cumbersome. Thankfully, there is a tool that can manage these virtualized environments for us, and provide a simple interface to configure them; an interface that involves storing configurations in simple plain text files, which are easy to share with colleagues, keeping everyone up to date as the project changes. This tool is Vagrant.