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.
Vagrant (http://www.vagrantup.com/) is a powerful development tool that lets you manage and support the virtualization of your development environment. Instead of running all your projects locally on your own computer, having to juggle the different requirements and dependencies of each project, Vagrant lets you run each project in its own dedicated virtual environment.
Vagrant provides a command-line interface and a common configuration language that allows you to easily define and control virtual machines that run on your own systems, but which tightly integrate, and also allows you to define how your own machine and the virtual machine interact. This can involve syncing folders such that the project code, which you edit using the IDE on your computer, is synced so that it runs on the Vagrant development environment.
Vagrant uses providers to integrate with the third-party virtualization software, which provides the virtualized machines for our development environment. The default provider is for Oracle VirtualBox; however, there are commercial providers to work with VMware Fusion and also plugins for Vagrant to work with Amazon Web Services. The entire configuration is stored in simple plain text files. The Vagrant configuration (Vagrantfile), and the configuration that defines how our Vagrant machines are configured (typically Shell scripts, Ansible playbooks, Chef cookbooks or Puppet manifests that Vagrant has built-in support for, as provisioners) are simply written in text files. This means that we can easily share the configurations and projects with colleagues, using version control systems such as Git.
When using Vagrant, the next time you need to go back to a previous project, you don't need to worry about any potential conflicts with changes made to your development environment (for example, if you have upgraded PHP, MySQL, or Apache on your local environment or within the Vagrant environment for another project), as the development environment for these projects are completely self-contained. If you bring a new member into the team, they can be up and running with your projects in minutes. Vagrant, along with its integration with provisioners, will take care of all the software and services needed to run the project on their machine. If you have one project that uses one web server such as Apache, and another one that uses Nginx, Vagrant lets you run these projects independently. If your project's production environment involves multiple servers (perhaps one for the Web and one for the database), Vagrant lets you emulate that with separate virtual servers on your machine.
Your development environment can mimic the production environment
Integrated provisioning tools such as Puppet, Chef, and Ansible allow you to store the configuration in a standard format, which can also be used to update production environments
Each project is separate in its own virtualized environment, so issues as a result of configuration and version differences for dependencies on different projects are a thing of the past
New team members can be onboarded to new projects as easy as
git clone && vagrant up
"It works on my machine" as a response to bugs is a thing of the past
The headache of linking code that you write on your own machine to your virtualized development environment is taken care of through synced folders
The environment can act as if it was your local machine and map the web server port (
80) of your development machine to your development environment if you wish, or you can access it as you would another machine on your network
You can let colleagues view your own development environment as well as easily share the development environment
You can share access to your own development environment over the Internet to demo your project or to get support from a colleague
Your local WAMP or MAMP installations will be gathering dust!
In this chapter, we will cover the following topics:
Discuss the requirements and prerequisites for Vagrant
Install Oracle VirtualBox
Verify that Vagrant was successfully installed
Once we have Vagrant and its prerequisites on our machine, we can then take a look at using it for our first project.
Vagrant can be installed on Linux, Windows, and Mac OS X, and although it uses Ruby, the package includes an embedded Ruby interpreter. The only other requirement is a virtualization provider such as Oracle VirtualBox or VMware Fusion. The Oracle VirtualBox provider is available for free and is the default provider for Vagrant. So, we will use and install VirtualBox in order to use Vagrant during the course of this book. Other providers are available, including one for VMware Fusion or Workstation, which is available as a commercial add-on (http://www.vagrantup.com/vmware).
Now that we know what software we need in order to get Vagrant running on our machine, let's start installing VirtualBox and Vagrant itself.
VirtualBox (https://www.virtualbox.org/) is an open source tool sponsored by Oracle that lets you create, manage, and use virtual machines on your own computer.
VirtualBox is a graphical program with a command-line interface that lets you visually create virtual machines, allocate resources, load external media such as operating system CDs, and view the screen of the virtual machine. Vagrant wraps on top of this and provides an intuitive command-line interface along with the integration of additional tools (including integrations with provisioners and also HashiCorp Atlas (formerly, Vagrant Cloud) that allow you to find and distribute base server images and share access to your Vagrant environments), so that we don't need to worry about how VirtualBox works or what to do with it; Vagrant takes care of this for us.
The first stage is to download the installer from the VirtualBox downloads page (https://www.virtualbox.org/wiki/Downloads), as shown in the following screenshot. We need to select the option that is appropriate for our computer (OS X, Windows, Linux, or Solaris):
At the time of writing this, Vagrant supports versions 4.0.x through 4.3.x of VirtualBox; earlier versions are not supported.
Once downloaded, let's open it and run the installer. On OS X, this involves clicking on the VirtualBox.pkg icon, as shown in the following screenshot. On Windows, simply opening the installer opens the installation wizard. On Linux, there are packages available that can be installed through your chosen package manager, see https://www.virtualbox.org/wiki/Linux_Downloads for more information.
Before the installer runs, it first checks whether the computer is capable of having VirtualBox installed. We need to click on Continue to begin the installation process, as shown in the following screenshot. While this process will vary from OS X to Windows to Linux, the process is very similar across all platforms. There are fully detailed installation instructions for all platforms on the VirtualBox website (https://www.virtualbox.org/manual/ch02.html).
Next, the installer informs us as to how much space it will use on our computer, and provides us with the option to customize the installation if we want to Change Install Location..., and install the software in another location (perhaps another disk drive if our disk gets full).
Now that we have the prerequisites installed on our computer, we can actually install Vagrant itself. This process is similar to that of installing VirtualBox. First, let's download the relevant installer from the Vagrant download page (http://www.vagrantup.com/downloads.html):
We now need to follow the installation steps that are provided; this is very similar to the earlier steps for VirtualBox, and for most of the software packages in general. You might be prompted to provide your computer's administrative user privileges for the software to be installed.
The preceding screenshot shows that we have successfully installed Vagrant, and we are able to run it.
vagrant command on its own lists a range of common subcommands, which we can run within Vagrant, as well as instructions on how to access the help information on Vagrant and any of its subcommands. We can access the help information on Vagrant and its subcommands by adding the
-h, to the end of the command when we run it.
In this chapter, we discussed the benefits of using virtualized development environments and specifically, Vagrant. We then installed Oracle VirtualBox, which is the virtualization provider Vagrant uses by default, and we installed Vagrant. After installing Vagrant, we ran the
vagrant command to check whether it was installed correctly.
Now that we have Vagrant and a provider installed, we can now move onto using Vagrant to set up and manage some of our development projects in a virtual development environment. In the next chapter, we will create our first project, learn about the configuration file, and manage our Vagrant controlled machines.