If you have written software on a desktop computer and attempted to deploy your code to another computer (a server), you have already encountered the challenges presented when deploying software. Developers and administrators frequently struggle with errors and defects, when development environments are different from the eventual production machines. There can be a number of differences introduced when the environments are different at the operating system level. Development with desktop operating systems (such as Windows or OS X) can introduce many issues when deploying to production environments that run a Unix (or Linux) environment.
The introduction of desktop hypervisor software allowed developers to develop and test software using virtual machines. A virtual machine is essentially a system within a system, wherein developers working on a desktop operating system can develop and deploy with a copy of the operating system and environment that closely mimics the eventual production environment. When desktop hypervisors became available, development teams found that they could share development environments by sharing the files used by the hypervisors to store the state of virtual machines. In many cases, sharing a virtual machine involved passing around copies of files on a portable hard drive or a shared network folder.
A few years ago, I encountered this specific example when working on a project that involved adding new features to software that ran on an environment, which we could not support with our modern desktop hardware. As many projects reveal, technical debt was introduced to the application by using some very specific features of the Java Development Kit (version 1.5), an environment that was impossible to work on with a 64-bit OS X machine. This machine had dual problems of being a 64-bit machine and it also lacked native support for Java 1.5 XML libraries. The solution to this problem was the creation of a single virtual machine that was shared between developers, passing around a copy of the machine created by a team lead and using it locally to compile and test our modifications.
As time passed by, changes to the environment became an issue, as we began struggling with the differences between not only the development and production environments, but also between our individual development environments as changes were made, making sure that each developer was working on the latest version of the virtual machine on that portable hard drive, which soon had a few different versions itself.
Eventually, the problem of maintaining development environments was large enough to begin looking for new solutions. Configuration management approaches helped us to start defining our environment in code, but we still had issues with sharing and maintaining our base environment. We found immediate use of an open source project called Vagrant, which was gaining some traction.
Vagrant (http://vagrantup.com) is a tool that allows you to define a virtual environment with code. A single file allows you to define a basic environment for a virtual machine as well as a series of provisioning actions that prepare the environment for use. Vagrant works by running code (Vagrantfiles) on top of packaged operating system images called boxes. The Vagrant code and box files can be versioned and distributed using automated tooling. This allows you to share virtual machines, which is not much different than the process of software development that uses source control.
Using Vagrant boxes and provisioning controlled by Vagrantfiles not only simplified the process of distributing virtual machines (and updates to virtual machines), but it also made the virtual machines we were working with inexpensive in terms of effort to rebuild. The amazing thing that we found was that Vagrant not only made it simple to distribute virtual machines, but also gave developers more freedom to experiment and make deeper modifications to the code without losing time due to changes in the development environment that could not be rolled back. This flexibility and a simplified on-boarding process for new developers made it much simpler for the team to spend more time doing software development (and tackling that technical debt!), rather than attempting to fix and find problems due to environments.
I've found Vagrant to be an invaluable tool in my work. I hope that this book can be a valuable resource for you in getting started with Vagrant, or perhaps, using Vagrant in new and different ways.
Chapter 1, Setting Up Your Environment, covers a few basics about hypervisor technology, the installation of Vagrant and VirtualBox, and some simple recipes to get started with Vagrant machines.
Chapter 2, Single Machine Environments, contains recipes to get started with writing single machine Vagrantfiles, including booting machines, forwarding ports, and customizing the virtual machine environment.
Chapter 3, Provisioning a Vagrant Environment, introduces the concept of provisioning Vagrant machines, installing software, and customizing the environment to develop and deploy software. This chapter focuses on using shell (bash) scripting to modify the Vagrant environment.
Chapter 4, Provisioning With Configuration Management Tools, contains simple recipes to provision Vagrant machines with four common configuration management tools: Puppet, Chef, Ansible, and Salt. These tools allow easier configuration of machines that have more complex environments. They also allow Vagrant machines to share the same provisioning instructions as other environments.
Chapter 5, Networked Vagrant Environments, contains recipes focused on networking Vagrant machines with external hosts and with each other. We cover a few topics from the basics of assigning host entries to networking a cluster of Vagrant machines with Consul.
Chapter 6, Vagrant in the Cloud, contains recipes to use Vagrant with cloud providers (specifically, Amazon Web Services and DigitalOcean). It also contains the use of Hashicorp's Atlas tool to share Vagrant environments with remote users.
Chapter 7, Packaging Vagrant Boxes, introduces methods to package Vagrant boxes for others to use. Recipes include the packaging of boxes using manual and automated tools and tips to share your box with others on Atlas.
Appendix A, Vagrant Plugins, gives a short introduction on how to extend the capabilities of Vagrant by developing plugins.
Appendix B, A Puppet Development Environment, expands on the introduction in Chapter 4, Provisioning With Configuration Management Tools, to set up a more robust configuration environment to develop Puppet scripts. While the focus is on using Puppet to provision, similar environments can be created to support the configuration management environment of your choice.
Appendix C, Using Docker With Vagrant, is an introduction to use Vagrant to create, deploy, and test Docker (http://docker.io) containers. This appendix introduces techniques to launch Docker containers with Vagrant as well as build and test a complete Docker environment.
To use the recipes in this book, you will need:
A development machine capable of running virtual machines with hypervisor software, such as VirtualBox (http://virtualbox.org) or VMware desktop products (http://vmware.com). You would want to get started with the freely available VirtualBox product and later on purchase the plugin to support VMware desktop products. Keep in mind that you will need a machine that is capable of running both your host operating system and also the guest operating systems that you will be creating with Vagrant. You will also want to ensure that you have enough storage (disk space) for virtual machine files. The disks created by Vagrant machines will typically be approximately the size required to operate the guest operating systems (approximately, 5-20 GB of disk space).
If you plan on running 64-bit guests, you will also want to ensure that your processor is capable of Intel hardware virtualization (VT-x). In most cases, processors that support 64-bit operating systems already have this support built-in (with some exceptions, such as older Intel Celeron processors). See https://www.virtualbox.org/manual/ch10.html for more background on the requirements for hardware virtualization.
Using cloud recipes (particularly, recipes involving Amazon Web Services and DigitalOcean) will require accounts with cloud providers. Running the examples might incur charges to your account, so make sure that you understand the financial impacts of running the examples and how to ensure that all created instances have been stopped or terminated to avoid extra charges for the use of computational resources. The recipes in this book are not expensive to run, but they are also not free. Machines that are left running for a period of time could also end up costing more than you had planned on, so make sure that any instance created with Vagrant is eventually destroyed.
This book is for developers and administrators of nearly all skill levels. Throughout the book, I make a general assumption that you are creating Vagrant machines to support the development of other software. Vagrant itself does not become interesting or useful until you use it to support the deployment and development of other software. Vagrant makes it simple to create local environments that mimic production environments and takes advantage of the same provisioning techniques used on production servers. If you have a mature and robust deployment pipeline, Vagrant allows you to reproduce this process on development machines. If you do not have a robust development pipeline, Vagrant can help you begin developing the scripts and processes, making your development and deployment environments more consistent. Consistent environments will help you to reduce the problems associated with the deployment process, which allows you to focus on producing better software.
In this book, you will find several headings that appear frequently (Getting ready, How to do it, How it works, There's more, and See also).
To give clear instructions on how to complete a recipe, we use these sections as follows:
This section tells you what to expect in the recipe, and describes how to set up any software or any preliminary settings required for the recipe.
This section usually consists of a detailed explanation of what happened in the previous section.
This section consists of additional information about the recipe in order to make the reader more knowledgeable about the recipe.
In this book, you will find a number of text styles that distinguish between different kinds of information. Here are some examples of these styles and an explanation of their meaning.
Code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles are shown as follows: "The Vagrant installer will extract, copy files, and add the vagrant command to the executable path."
A block of code is set as follows:
-rw------- 0 cothomps staff 1960775680 Jul 24 20:42 ./box-disk1.vmdk -rw------- 0 cothomps staff 12368 Jul 24 20:38 ./box.ovf -rw-r--r-- 0 cothomps staff 505 Jul 24 20:42 ./Vagrantfile
When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:
# -*- mode: ruby -*- # vi: set ft=ruby : VAGRANTFILE_API_VERSION = "2" Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| config.vm.box = "chad-thompson/ubuntu-trusty64-gui" config.vm.provider "virtualbox" do |vbox| vbox.gui = true end end
Any command-line input or output is written as follows:
vagrant box add http://servername/boxes/environment.box
New terms and important words are shown in bold. Words that you see on the screen, for example, in menus or dialog boxes, appear in the text like this: "A new installation of VirtualBox will display a welcome message in a window titled Oracle VM VirtualBox Manager."
Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or disliked. Reader feedback is important for us as it helps us develop titles that you will really get the most out of.
To send us general feedback, simply e-mail <[email protected]>, and mention the book's title in the subject of your message.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide at www.packtpub.com/authors.
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
You can download the example code files from your account at http://www.packtpub.com for all the Packt Publishing books you have purchased. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you could report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website or added to any list of existing errata under the Errata section of that title.
To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.
Piracy of copyrighted material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at <[email protected]> with a link to the suspected pirated material.
We appreciate your help in protecting our authors and our ability to bring you valuable content.
If you have a problem with any aspect of this book, you can contact us at <[email protected]>, and we will do our best to address the problem.