A Vagrant Primer


https://www.vagrantup.com

What?

Vagrant ist ein Tool mit dem es einfacher wird die Entwicklung in einer virtuellen Maschine durchzuführen. D.h. man führt das Projekt an dem man gerade arbeitet nicht auf dem lokalen System aus (zB MacOS, Windows) sondern in einer VM.

In der VM läuft dann zB ein Ubuntu oder was immer man auf dem Server verwendet auf dem das Projekt später deployed wird.

Vagrant macht das Setup der VM sehr einfach und bringt Möglichkeiten mit das aufsetzen und updaten der VM zu automatisieren. So sind immer alle auf dem gleichen Stand und man muss lokal nichts weiteres installieren.

Getting started

How?

vagrant init ubuntu/trusty32
vagrant up

Und schon läufts.

vagrant init

Legt ein Vagrantfile ins aktuelle Verzeichnis, dass beinhält den Namen der Box (ein vorgeschnürtes VM Image). Man kann da auch konfigurieren zB wie viel RAM die VM haben soll etc.

vagrant up

vagrant up liest die Config und sieht nach ob die VM schon initialisiert wurde. Falls nein wird eine neue VM in VirtualBox angelegt und die Box die man bei init angegeben heruntergeladen und installiert.

Dann startet die VM das erste mal und falls man ein Script im Vagrantfile angegeben hat wird auch das ausgeführt.

Damit kann man die VM automatisch provisionieren. d.h. entsprechende Software vorinstallieren etc aber dazu später mehr

Und schon hat man ein laufendes Ubuntu System in einer virtuellen Maschine. Das ganze läuft ohne GUI ab, d.h. es startet kein VirtualBox Fenster in dem man die Maschine booten sieht etc.

Vagrantfile

# -*- mode: ruby -*-
# vi: set ft=ruby :

# All Vagrant configuration is done below. The "2" in Vagrant.configure
# configures the configuration version (we support older styles for
# backwards compatibility). Please don't change it unless you know what
# you're doing.
Vagrant.configure(2) do |config|
  # The most common configuration options are documented and commented below.
  # For a complete reference, please see the online documentation at
  # https://docs.vagrantup.com.

  # Every Vagrant development environment requires a box. You can search for
  # boxes at https://atlas.hashicorp.com/search.
  config.vm.box = "ubuntu/trusty32"

  # Disable automatic box update checking. If you disable this, then
  # boxes will only be checked for updates when the user runs
  # `vagrant box outdated`. This is not recommended.
  # config.vm.box_check_update = false

  # Create a forwarded port mapping which allows access to a specific port
  # within the machine from a port on the host machine. In the example below,
  # accessing "localhost:8080" will access port 80 on the guest machine.
  # config.vm.network "forwarded_port", guest: 80, host: 8080
  config.vm.network "forwarded_port", guest: 8000, host: 8000

  # Create a private network, which allows host-only access to the machine
  # using a specific IP.
  # config.vm.network "private_network", ip: "192.168.33.10"

  # Create a public network, which generally matched to bridged network.
  # Bridged networks make the machine appear as another physical device on
  # your network.
  # config.vm.network "public_network"

  # Share an additional folder to the guest VM. The first argument is
  # the path on the host to the actual folder. The second argument is
  # the path on the guest to mount the folder. And the optional third
  # argument is a set of non-required options.
  # config.vm.synced_folder "../data", "/vagrant_data"

  # Provider-specific configuration so you can fine-tune various
  # backing providers for Vagrant. These expose provider-specific options.
  # Example for VirtualBox:
  #
  # config.vm.provider "virtualbox" do |vb|
  #   # Display the VirtualBox GUI when booting the machine
  #   vb.gui = true
  #
  #   # Customize the amount of memory on the VM:
  #   vb.memory = "1024"
  # end
  #
  # View the documentation for the provider you are using for more
  # information on available options.

  # Define a Vagrant Push strategy for pushing to Atlas. Other push strategies
  # such as FTP and Heroku are also available. See the documentation at
  # https://docs.vagrantup.com/v2/push/atlas.html for more information.
  # config.push.define "atlas" do |push|
  #   push.app = "YOUR_ATLAS_USERNAME/YOUR_APPLICATION_NAME"
  # end

  # Enable provisioning with a shell script. Additional provisioners such as
  # Puppet, Chef, Ansible, Salt, and Docker are also available. Please see the
  # documentation for more information about their specific syntax and use.
  # config.vm.provision "shell", inline: <<-SHELL
  #   sudo apt-get update
  #   sudo apt-get install -y apache2
  # SHELL
  config.vm.provision "shell", path: "vagrant_provision.sh"
end

vagrant_provision.sh

#!/bin/bash

MYSQL_ROOT_PASSWORD=root

debconf-set-selections <<< "mysql-server mysql-server/root_password password $MYSQL_ROOT_PASSWORD"
debconf-set-selections <<< "mysql-server mysql-server/root_password_again password $MYSQL_ROOT_PASSWORD"

apt-get update -q -y
#apt-get upgrade -q -y

apt-get install -q -y python-pip python-virtualenv
apt-get install -q -y mysql-server libmysqlclient-dev python-mysqldb

cat > /home/vagrant/.bash_profile << EOF
source /home/vagrant/venv/bin/activate
cd /vagrant
EOF

mysql -u root -proot <<< "CREATE DATABASE vagrant_demo;"

sudo -u vagrant virtualenv /home/vagrant/venv --system-site-packages
sudo -u vagrant /home/vagrant/venv/bin/pip install -r /vagrant/requirements.txt
sudo -u vagrant /home/vagrant/venv/bin/python /vagrant/djangodemo/manage.py migrate --noinput

How?

Wenn man keine grafische Oberfläche hat, wie startet man dann den Texteditor?

Das besondere ist, dass das Projekt in der VM laufen soll, man aber lokal die Dateien mit gewohnten Tools bearbeitet.

Dazu wird das Projektverzeichnis in der VM unter /vagrant eingebunden.

D.h. man entwickelt immer noch Lokal in der geliebten modernen IDE sofern es nicht VIM in der Konsole sein soll.

Dann loggt man sich ein und startet z.B. den Entwicklungsserver. Über Portforwarding verwendet man dann den lokalen Browser zum ansehen und debuggen.

Warum?

Warum macht man das? Ich hab doch lokal schon meinen Webserver aufgesetzt, meine Datenbank mit Daten befüllt, Node und Sass installiert ...

Use cases

Deployment testen

Es lassen sich Deployment Scripte testen die ein frisches System brauchen.

Wir haben z.B. bei einem Kunden ein spezielles Deployment gebraucht weil wir unser Datenbankmigrationsframework geändert haben. Wir wollten das deployment testen. Das ging am besten in einer virtuellen Maschine.

Da konnten wir auch ungewöhnliche Pfade einfach nachbilden. zB /kunden/websites/kunde123/.

Wegwerfsystem

Die Software für meine Diplomarbeit war ein Python Package. Da ich viel mit Python mache konnte ich nicht sicher sein, sind auf einem Standard Ubuntu alle Tools installiert um das Package zu installieren?

Lösung: Mit Vagrant eine Box gestartet, versucht zu installieren -> Test erfolgreich.

Neue DB testen

z.B. neue DB ausprobieren wie Redis. Einfach in Wegwerf VM aufsetzen.

Cluster

Es lassen sich mehrere VMs gleichzeitig starten um z.B. Datenbankcluster zu simulieren oder wieder das Produktivsystem nach zu bilden.

zB hab ich eine Demo gesehen die das Deployment mit Salt Stack auf mehreren Rechnern testet.

Probleme

Langsamer

z.B. gulp das auf node_modules/ aus share zugreift hat deutlich längere Startzeiten.

Kann man evtl mit anderem Freigabe Provider umgehen (zB NFS). Aber hab ich nicht zum laufen bekommen.

Tooling

Evtl wenn UI Tools eingesetzt werden, zB zur Datenbankadministration muss man evtl mehr einrichten (Zugriff auf DB von außen einrichten).

Probleme

Payoff

Man muss es einrichten, man muss provisioning Pflegen

Parität

zB könnte es sein, dass Produktivserver nicht unter unserer Kontrolle ist. Bei Team23 verwenden wir viele Managed Server, die können wir natürlich nicht 100% nachbilden.

Werkzeug

Ist gut es im Hinterkopf zu haben, irgendwann kommt der eigene perfekte Usecase.

Cheers!

… Erfahrungsaustausch!


Gregor Müllegger
http://gremu.net/
@gregmuellegger
SpaceForward
Right, Down, Page DownNext slide
Left, Up, Page UpPrevious slide
POpen presenter console
HToggle this help