If you work in IT it’s pretty normal in these days to have a computer with at least 4GB of RAM and if you have bought it in the last year probably it has 8GB, this is fantastic to run modern applications that usually require much more RAM than in the past, but this make the use of Virtual Machine on personal computer much more easy and doable.
This open some interesting options in the development cycle of any application or service as now it’s possible to have a development/test machine on every personal computer, as system administrator I’d like that these VM should be as much similar as possible to the production environment, so what’s a good way to manage and distribute Virtual Machines to the developers ?
For what I’ve found around the best answer at the moment it’s: Vagrant.
In this first part I’ll cover the theorical aspect of Vagrant and in the next one I’ll show you some basic command to setup a running environment with it.
Vagrant is free and open-source software for creating and configuring virtual development environments it provides easy to configure, reproducible, and portable work environments built on top of industry-standard technology and controlled by a single consistent workflow to help maximize the productivity and flexibility of you and your team.
To achieve its magic, Vagrant stands on the shoulders of giants. Machines are provisioned on top of VirtualBox, VMware, AWS, or any other provider. Then, industry-standard provisioning tools such as shell scripts, Chef, or Puppet, can be used to automatically install and configure software on the machine.
There are 2 ways to install Vagrant on your computer:
– As Package
– As Ruby gem
As I’m not so skilled in ruby i prefer the package approach, and if you use a modern distribution probably you’ll find it in your repository, as Vagrant has a fast deploy cycle you can also decide to download the .deb or .rpm directly from the website to have the latest version available (1.3.5 at the moment of writing this article).
I’ve used the package available on my repository (1.0.3), a bit old but good enough for this introduction.
Basic concepts of Vagrant
These are some elements that you must know to work with Vagrant:
Il Vagrantfile è un file Ruby utilizzato per configurare Vagrant in base al progetto. La funzione principale del Vagrantfile è quello di descrivere le macchine virtuali necessarie per un progetto e come configurare e fornire queste macchine. Sebbene il contenuto di un Vagrantfile sia in Ruby, la conoscenza di Ruby non è necessaria per apportare modifiche al file perché è principalmente una semplice assegnazione variabili.
I Vagrantfiles sono destinati ad essere caricati direttamente nel vostro sistema di controllo di versione e si comportano in modo identico su qualsiasi sistema che gestisca Vagrant. L’idea è che quando uno sviluppatore estrae del codice dal sistema di controllo di versione che ha un Vagrantfile, lo sviluppatore può semplicemente dare un
Vagrant up per ottenere un ambiente virtuale completo per sviluppare tale prodotto .
Launching a blank virtual machine is not very useful, so Vagrant supports provisioning virtual machines through the use of provisioners. There are a handful of provisioners for the most common choices supported out of the box with Vagrant, but it is also possible to add your own very easily as long as you know a little Ruby.
Provisioners allow you to easily setup your virtual machine with everything it needs to run your software. So at the end of their operations you will have a virtual machine with all the software stack that interests you to have in that specific environment.
The available provisioners that come standard with Vagrant are:
- Chef Solo
- Chef Server
- Puppet Standalone
- Puppet Server
A “box” is the base image used to create a virtual environment with Vagrant. It is meant to be a portable file which can be used by others on any platform that Vagrant runs in order to bring up a running virtual environment. The
vagrant box utility provides all the power for managing boxes, and
vagrant package is used to create boxes.
Boxes provide only the base image for Vagrant. The moment you run
vagrant up, the box is copied so that it can be modified for that virtual machine. Therefore, it is safe to remove or update the box after a virtual machine has been created.
While Vagrant ships out of the box with support for VirtualBox, Vagrant has the ability to manage other types of machines as well. This is done by using otherproviders with Vagrant.
Alternate providers can offer different features that make more sense in your use case. For example, if you’re using Vagrant for any real work, VMware providers are recommended since they’re well supported and generally more stable and performant than VirtualBox.
Before you can use another provider, you must install it. Vagrant only ships with VirtualBox support. Installation of other providers is done via the Vagrant plugin system.
Sometimes, you want to change the way Vagrant does something or add additional functionality to Vagrant. This can be done via Vagrant plugins.
Plugins are powerful, first-class citizens that extend Vagrant using a well-documented, stable API that can withstand major version upgrades.
In fact, most of the core of Vagrant is implemented using plugins.
This is the last concept that I want to show you and it’s very useful when working on boxes.
Synced folders enable Vagrant to sync a folder on the host machine to the guest machine, allowing you to continue working on your project’s files on your host machine, but use the resources in the guest machine to compile or run your project.
By default, Vagrant will share your project directory (the directory with the Vagrantfile) to /vagrant.
Probably like me while reading all these feature and characteristics you are thinking at how to start to make some box for your colleagues and customize them, to move the personal computer most of the development machines that you have to manage, don’t worry in the next article we’ll go for some practice work.
- In this SteamOS era where do the Linux gaming stand?
- Introduction to gnome maps
- How to manage processes with cgroup on Systemd