Let us start by cloning the code from thebooks-ms²⁸GitHub repository.
1 git clone https://github.com/vfarcic/books-ms.git 2
3 cd books-ms
With the code downloaded we can proceed and create the development environment.
Vagrant
Creating a Vagrant virtual machine is easy.
²⁸https://github.com/vfarcic/books-ms
1 vagrant plugin install vagrant-cachier 2
3 vagrant up dev
The first command is not mandatory, but it will help speeding up the creation of new VMs. It caches all packages that are being used so that the next time we need them, they are obtained from the local HD instead being downloaded. The second command does the “real” work. It brings up the VM called dev. The first attempt might take some time since everything, starting with the base box, needs to be downloaded. Bringing up this VM will be much faster each consecutive time. Bringing up any other Vagrant VM based on the same box (in this case ubuntu/trusty64) will be fast.
Please note that some of the commands we’ll be executing throughout the book might require a substantial time to finish. As a general rule, feel free to continue reading while commands are running (at least until you are asked to run a new command). Let us use the time needed to bring up the VM to go through theVagrantfile²⁹located in the root of the code we just cloned. It contains all the information Vagrant needs to create the development environment VM. The contents are as follows.
For those unfamiliar with Ruby, the syntax might look a bit cryptic but after a very short practice, you’ll notice that it is very easy and straightforward to define one or more VMs with Vagrant. In our case, we started by specifying the box to be ubuntu/trusty64.
Vagrant boxes are the package format for Vagrant environments. Anyone can use a box, on any platform supported by Vagrant, to bring up an identical working environment.
²⁹https://github.com/vfarcic/books-ms/blob/master/Vagrantfile
In other words, the box is (a kind of) a VM on top of which we can add things we require. You can browse available boxes fromAtlas³⁰orcreate your own³¹.
After the box, comes the specification that local directory should be synced with VM. In our case, we set that the current directory (.) should be synced with the /vagrant directory inside the VM.
This way, all the files from the current directory will be freely available within the virtual machine.
Moving on, we specified that the VM should have 2 GB of RAM and defined one VM called dev.
Further on, throughout the book, we’ll see how we can specify multiple virtual machines within the same Vagrantfile.
Inside the definition of the dev VM, we set the IP that Vagrant will expose and that it should run the Ansible playbook dev.yml. We won’t go into more details regarding Ansible since that is reserved for one of the next chapters. Suffice to say that Ansible will make sure that Docker and Docker Compose are up and running.
We’ll use Vagrant on many occasions throughout this book so you’ll have plenty of opportunities to learn more about it. However, this book does not provide detailed guidelines and documentation.
For more information and the complete documentation, please visit theVagrant’s official site³².
Hopefully, you have a fast internet connection and by this time, execution ofvagrant upprobably finished. If not, grab a coffee and have a short break.
Let us enter the VM we just created and take a look what’s inside.
1 vagrant ssh dev
The first command allows us to enter inside the dev VM. You will be greeted with Ubuntu’s welcome message. The next three are just demonstrations that Ansible, Docker and Docker Compose are installed. Finally, we’re entering the /vagrant directory and listing its content. You’ll notice that it is the same as the host directory where we cloned the GitHub repository. Both of them are synchronized.
Now that we have the VM with all the software up and running, let us take a look at our second star of this chapter.
³⁰https://atlas.hashicorp.com/boxes/search
³¹http://docs.vagrantup.com/v2/boxes/base.html
³²https://www.vagrantup.com/
Docker
We already had a short discussion about Docker and containers in general. Never the less, we might want to explore the subject a bit more. There were very few technologies that experienced such a fast adoption. What makes Docker so popular?
VM hypervisors are all based on emulating virtual hardware. A huge percentage of resources VMs use is spent on that emulation. The exact percentage depends on specific configurations of each VM, but it is not uncommon to spend 50% or more of hardware resources on hardware virtualization.
What that means in practical terms is that they are very demanding on resources.
Docker, on the other hand, uses shared OS. That feature alone makes it much more efficient. With well-defined containers, we can easily have 5 times more applications running than when they are deployed to separate virtual machines. By using the host kernel, containers manage to maintain almost the same separation between processes without the hardware virtualization. Even if Docker does not bring anything else to the table, that would be enough for many to start using it.
Curious thing is that many think that containers are something new that came into being with Docker. The reality is that they’ve been in use at least from the year 2000.Oracle Solaris Zones³³, LXC³⁴ and OpenVZ³⁵ are few of the examples. Google is one of the companies that started using containers long time before Docker emerged. The question you might ask is what makes Docker so special if containers existed long before its first release. Docker made it easy for us to use containers and is built on top of LXC. It made useful technology simple to use and built a very powerful ecosystem around it.
Docker company quickly become the partner with almost all software industry leaders (Canonical, RedHat, Google, Microsoft, and so on) and managed to standardize containers. This partnership also brought containers to almost all operating systems. At the time of this writing, Windows Server 2016 technical preview was released featuring Docker engine running natively.
Developers and DevOps love it since it provides them with a very easy and reliable way to pack, ship and run self-sufficient applications that can be deployed virtually anywhere. Another important Docker tool is theHub³⁶that contains official, unofficial and private containers. Whatever you need, be it an application, server, database or anything in between, chances are you will be able to find it in the Docker Hub and have it up and running with a single command in a matter of minutes.
There’s much more to Docker (and containers in general) than what we discussed and you’ll see throughout this book many different usages and test cases. For now, let’s see how we can utilize Docker to help us with the development environment.
³³http://www.oracle.com/technetwork/server-storage/solaris11/technologies/virtualization-306056.html
³⁴https://linuxcontainers.org/
³⁵http://openvz.org/Main_Page
³⁶https://hub.docker.com/