Votre infrastructure de test avec Vagrant

Qu’est ce que Vagrant ? Un outil pour simplifier le déploiement de VM. Dans mon cas Vagrant gère les VMs avec virtualBox.

Ce que je trouve génial pour faire son infrastructure de test c’est que l’on peut définir toute son infrastructure de test en 1 fichier (Vagrantfile) et pour simplifier la vie il y a deux règles de base, un dossier /vagrant qui est synchronisé avec le dossier où on va exécuter notre $ vagrant up.

Je vais juste vous montrer un Vagrantfile qui créé une infrastructure de test pour « jouer » avec Ansible. Dans cette infrastructure je veux plusieurs linux si possible la configuration ssh avec ma clef publique dans le ~vagrant/.ssh/authorized_keys.

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

# README
#
# Getting Started:
# 1. vagrant plugin install vagrant-hostmanager
# 2. vagrant up
# 3. vagrant ssh
#
# This should put you at the control host
#  with access, by name, to other vms
Vagrant.configure(2) do |config|
  config.hostmanager.enabled = true
  config.vm.box = "ubuntu/groovy64"

  config.vm.define "control", primary: true do |h|
    h.vm.hostname = 'control'
    h.vm.network "private_network", ip: "192.168.135.10"
    h.vm.provision :shell, :inline => <<'EOF'
if [ ! -f "/home/vagrant/.ssh/id_rsa" ]; then
  ssh-keygen -t rsa -N "" -f /home/vagrant/.ssh/id_rsa
fi
cp /home/vagrant/.ssh/id_rsa.pub /vagrant/control.pub

cat << 'SSHEOF' > /home/vagrant/.ssh/config
Host *
  StrictHostKeyChecking no
  UserKnownHostsFile=/dev/null
SSHEOF

chown -R vagrant:vagrant /home/vagrant/.ssh/
EOF
  end

  config.vm.define "lb01" do |h|
    h.vm.box = "centos/7"
    h.vm.hostname = 'lb01'
    h.vm.box_url = "centos/7"
    h.vm.network "private_network", ip: "192.168.135.101"
    h.vm.provision :shell, inline: 'cat /vagrant/control.pub >> /home/vagrant/.ssh/authorized_keys'
  end

  config.vm.define "app01" do |h|
    h.vm.hostname = 'app01'
    h.vm.network "private_network", ip: "192.168.135.111"
    h.vm.provision :shell, inline: 'cat /vagrant/control.pub >> /home/vagrant/.ssh/authorized_keys'
  end

  config.vm.define "app02" do |h|
    h.vm.hostname = 'app02'
    h.vm.network "private_network", ip: "192.168.135.112"
    h.vm.provision :shell, inline: 'cat /vagrant/control.pub >> /home/vagrant/.ssh/authorized_keys'
  end

  config.vm.define "db01" do |h|
    config.vm.box = "bento/amazonlinux-2"
    h.vm.hostname = 'db01'
    h.vm.network "private_network", ip: "192.168.135.121"
    h.vm.provision :shell, inline: 'cat /vagrant/control.pub >> /home/vagrant/.ssh/authorized_keys'
  end
end

Voila donc je viens de créer un textbed avec 4 VMs.

Explication de tout ça

Une box ?

Une image d’Os sous Vagrant est une box. Elles sont disponible sur ce site https://app.vagrantup.com/ comme pour le hub de docker il y a des images « officiel » et des images « communauté »:

Dans le Vagrantfile la variable qui definis la box à utiliser est config.vm.box.

Dans le Vagrantfile on commence par des variables globlales. Celles avant le premier config.vm.define. Par défaut l’os sera Ubuntu Groovy. Comme toute les variables elle peut etre rédéfinis dans la section sous config.vm.define.

config.vm.box = "ubuntu/groovy64"
  • control , app01 et app02 utilise la box globale

Pour les deux VMs suivante config.vm.box a été redéfinis au niveau de config.vm.

  • lb01 utilise la box « centos/7 »
  • db01utilise la box « bentoo/amazonlinux-2 »

Ok c’est bon on a choisi nos Os.

Hostname et réseau

Pour ce qui connaisse bien virtualBox une petite visite sur l’interface graphique de ce dernier. Pour le « DNS » c’est top pas besoin de configurer quoi que ce soit il suffit de définir le h.vm.hostname. Pour le réseau on a définis un reseau qu’on appel private_network et on met des ips fixe aux vm. Toutes nos VM sont sur le réseaux private_network and add a unique Ip. Par défaut le NAT nous permer d’acceder d’installer nos packages.

    h.vm.hostname = 'control'
h.vm.network "private_network", ip: "192.168.135.10"

Le réseau, et DNS ready.

Simple is beautiful

Comme je l’ai dit la configuration ci dessus est faites pour jouer avec ansible. J’ai donc besoin d’un post install pour gérer les clefs ssh. Il suffit de faire les clefs dans le compte de l’utilisateur vagrant et de copier sa clef publique dans le /home/vagrant/.ssh/authorized_keys

/home/vagrant/.ssh/authorized_keys

Pour faire simple que de mieux que d’executer un post install script en shell. Vagrant a donc une variable qui permet de faire ca.

    h.vm.provision :shell, :inline => <<'EOF'
if [ ! -f "/home/vagrant/.ssh/id_rsa" ]; then
ssh-keygen -t rsa -N "" -f /home/vagrant/.ssh/id_rsa
fi
cp /home/vagrant/.ssh/id_rsa.pub /vagrant/control.pub

cat << 'SSHEOF' > /home/vagrant/.ssh/config
Host *
StrictHostKeyChecking no
UserKnownHostsFile=/dev/null
SSHEOF

chown -R vagrant:vagrant /home/vagrant/.ssh/
EOF

Notre post-install permet de faire nos clefs ssh et met a jour le fichier authorized_key Ce qui permet de ne pas taper de mot de passe. L’utilisateur Vagrant est déja dans le su et n’a pas besoin de taper de mot de passe quand il fait exécuter une tache comme root.

Multi VM

Le Vegrantfile peut gérer plusieurs VM comme le notre. On peut redéfinir dans chaque section de config.vm.define toute les variables globale.

Let’s start the « cloud »

Pour commencer, faire ou choisir le dossier à partir duquel on veut travailler, c’est ce dossier qui sera partagé avec vos VMs dant le /vagrant de ces dernières. On copy dans ce dossier notre Vagrantfile, pour créer les VMs il sufffit de suivre les 3 premières commandes listé dans le Vagrantfile (dans CE Vagrantfile).

$ vagrant plugin install vagrant-hostmanager
$ vagrant up
$ vagrant ssh

le vagrant-hostmanager est requis pour géré le /etc/hosts (pratique pour ne pas avoir a faire de configuration DNS). Le up fait toute les étapes requis pour installé et configurer notre cloud.

La commande « vragrant ssh » permet de se connecter à la première VM listé dans le Vagrantfile, et on peut aussi utiliser : « vagrant ssh <hostname> » pour se connecter directement à la VM <hostname>. Gràce a vagrant ssh notre cloud peut etre sur un réseau virtual sans avoir besoin de faire une configuration avec une deuxième interface réseau.

Pour résumé vous pouvez faire votre testbed en quelques minutes sans savoir quoi que ce soit de ruby et juste mettre un post-install en bash. Voila de mon coté mon testbed est nickel facile a utiliser et sans trop de customisation compliqué à part un compte vagrant ajouter a sudo et un dossier de partage. Tout le reste c’est à peut près standard.

https://www.vagrantup.com/

Augmenter la taille d’un volume OpenStack (la vidéo)

Voila la vidéo de l’augmentation de la taille d’un de mes volumes OpenStack.

Vi

Vous pouvez télécharger ce pdf l’imprimer et vous avez la documentation complete de Vi.

Augmenté la taille de stockage d’une VM sur OpenStack chez Infomaniak

Chez Infomaniak, le VMs est géré via Openstack. Vous avez deux volumes un pour le système (20 Go) et une pour vos données (100 Go) par défaut. On a une /dev/vda1 pour le système et un /dev/vdb pour les données.

On est libre de faire comme on veut sur son /dev/vdb. Dans la première configuration que j’ai faite j’ai créé une partition sur le /dev/vdb que j’ai formaté en ext4.

On peut et je le recommande formaté tout le volume au lieu de faire une partition, on est dans un système qui s’occupe des données ce sont des diques virtuel.

Quand on mets un système en production c’est pour utilise les resources de ce dernier, il est donc logque de n’installer que ce dont on a besoin. Dans mon cas J’ai eu besoin de 50Go en plus au bout de 1 an.

Comment utiliser tout mon volume et donc rajouter 50Go sur mon volume de données.

Dand le cas d’un volume qui contient une partition (/dev/vdb1)

Pour commencer on va umount la partition. On arrète les processus qui utilise ce volume et on le unmount.

# umount /dev/vdb1

on va augmenter la taille de la partition avec parted qui a la command resizepart (fdisk ne l’a pas).

# umount /dev/db1
# parted /dev/vdb
GNU Parted 3.2
Using /dev/vdb
Welcome to GNU Parted! Type ‘help’ to view a list of commands.
(parted) resizepart 1 100%
(parted) quit
# fsck.ext4 -f /dev/vdb1
# resize2fs /dev/vdb1
et voila on a tout récupéré.

Dans le cas ou tout le volume est utilisé sans partition

Nous n’avons pas besoin de faire de faire un resizepart, vu qu’il n’y a pas de partition.

# umount /devdb
# fsck.ext4 -f /dev/vdb
# resize2fs /dev/vdb

Nous avons donc deux scénarios possible quand on décide d’augmenter la taille d’un volume et le rendre utilisable par votre système.

Mon expérience me dis que dans le cas Openstack pour pouvoir augmentater la taille du volume il est préférabe de ne pas faire de partition.

Aller à la barre d’outils