Vagrant in the clouds

Dec 21, 2015
VagrantDigitalOcean

[2016-10-27: it seems a Debian package of the plugin is coming up: ]

HashiCorp’s Vagrant is a really great, drop-dead easy to use tool for providing different virtual environments for development or testing¹. Out of the box it uses VirtualBox for maintaining local virtual machines, but several other providers (virtualization and container solutions, cloud services) could be employed by special plugins.

Among the there is also one for using Vagrant together with the cloud provider DigitalOcean, . To work with cloud based instances instead on local hypervisors might be interesting if you want to have your development system easily accessible to the public while using it, if local hardware resources needed to the expanded, or comes in handy when in more complex setups a multitude of machines is needed for development². DigitalOcean provides infrastructure in an easy and inexpensive way, and with that plugin the two really make a great team together.

It doesn’t matter if a needed Vagrant plugin is available on your system as package (like on current Debian Testing currently solely the plugin for employing Linux containers³ is available as a package), because they could be easily installed through Vagrant itself. Just do vagrant install plugin vagrant-digitalocean and it automatically gets downloaded.. The process might acquire some more needed Ruby packages (Vagrant is written in Ruby) and stores everything in ~/.vagrant.d/.

DigitalOcean of course needs registration and to choose a payment method like the convenient pre payment via Paypal transfers. For working together with the API like the Vagrant plugins do, DigitalOcean uses access tokens instead of user credentials (user/password based authentication). A new token could be generated with “API–>Your Tokens” on the web interface. Please regard that the token is only displayed once directly after generation, so it’s needed to get copied out immediately. The next thing which is needed is a SSH key pair, and preferably a new one. For that, change into ~/.ssh and initiate ssh-keygen -t rsa -b 4096 -C "" -f . A passphrase has to be chosen and quickly a new keypair ( & .pub) becomes available. The token, the passphrase and the private key (the file without .pub) should no be shared whatsoever. That’s everything which is needed to generate droplets (like the virtual machines are called) for the use with Vagrant.

After vagrant init has been initiated in the working directory of your development project, the newly generated Vagrantfile must be configured for the targeted provider and the wanted machine configuration:

Vagrant.configure(2) do |config|
  config.vm.hostname = 'vagrantdroplet'
  config.vm.provider :digital_ocean do |provider, override|
    override.ssh.private_key_path = '~/.ssh/'
    override.vm.box = 'digital_ocean'
    override.vm.box_url = 'https://github.com/smdahlen/vagrant-digitalocean/raw/master/box/digital_ocean.box'
    provider.token = '7a67956b4231b193d95e23bf575151372865eabc769b9abfa385a36e6bd'
    provider.size = '512mb'
        provider.region = 'fra1'
        provider.image = 'debian-8-x64'
end

The slug for provider.size chooses the droplet, and the one with 512MB is the smallest and cheapest one. It provides 512MB RAM, a 20 GB SSD harddisk and 1TB transfer volume. I’ve checked the CPU one time for being a single Intel® Xeon® CPU E5-2650L v3 @ 1.80GHZ, and the fees are as fair as $0.007/hour. All available virtual machines (memory/CPU combinations) can be displayed by doing vagrant digitalocean-list sizes (it’s convenient to export the token into a shell variable like $TOKEN or so):

$ vagrant digitalocean-list sizes $TOKEN
Memory          CPUs            Slug
512MB           1               512mb
1024MB          1               1gb
2048MB          2               2gb
4096MB          2               4gb
8192MB          4               8gb
16384MB         8               16gb
32768MB         12              32gb
49152MB         16              48gb
65536MB         20              64gb

The provider.region is the geographic area in which the server is going to be created (e.g. fra1 is Frankfurt, the available ones could be put out by doing vagrant digitalocean-list regions), and provider.image is the operating system image which is going to be installed into the droplet. Several images are provided by DigitalOcean (the box which is given as vm.box in the Vagrantfile is only a dummy for technical purposes), you could research their slugs with vagrant digitalocean-list images. The slug debian-8-x64 currently installs a Debian “Jessie” 8.2 base system⁴.

If everything is properly configured the virtual environment is ready to get launched with vagrant up --provider=digital_ocean. After a little while, the newly created droplet has been created and is ready to go:

The public SSH key already got installed into the virtual machine and thus everything is ready to log into the virtual machine vagrant ssh⁵:

$ vagrant ssh
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 8.2 (jessie)
Release:        8.2
Codename:       jessie

Done.

Currently there is with the Debian image: sudo is not available on the image (which uses the root account as default), but this is expected for syncing the project folder into /vagrant during vagrant up. A little workaround is to ssh in and install sudo manually ($ apt-get install sudo), after that is done re-syncing the folder with $ vagrant provision works.

Using maintenance operations on the running droplet, vagrant halt to put it into sleep doesn’t work complaining about using the wrong API (0.7.8). However, powering off in DigitalOcean’s web frontend works (regard that sleeping droplets keep on getting billed). Also, vagrant reload for rebooting the machine doesn’t work here, either (“Guest-specific operations were attempted on a machine that is not ready for guest communication.”). But, shutdown -r now or reboot works (see “Droplet–>History” on the web frontend for a recheck). The command vagrant destroy works without any problems.