Workshop 201 : CLI, manipulation d’image et réseaux privés

Dans ce workshop, on va explorer quelques fonctionnalité d’OpenStack grâce à la ligne de commande. On va voir comment créer des images systèmes de différente manière, modifier les règles de firewalling, créer des réseaux privés et des ports réseaux.

Se loguer en SSH sur la machine rebond

L’adresse IP de la machine rebond sera communiquée au moment du workshop.

L’utilisateur est : bounce

Le mot de passe sera communiqué au moment du workshop.

Ce qui donne :

ssh bounce@XXX.XXX.XXX.XXX

Une fois loggé, se connecter en root sur localhost en utilisant le port 22$ID, ce qui donne :

ssh -p 22$ID root@localhost

Le mot de passe sera communiqué au moment du workshop.

Installation de la CLI OpenStack

On va commencer par installer la CLI d’OpenStack qui nous servira pour l’essentiel de nos actions. Cet outil remplace les anciens CLI nova, neutron, glance…

apt-get install python-openstackclient

L’outil fournit le nécessaire pour faire fonctionner l’auto-complétion, ça sera bien utile, surtout au début.

Voici comment l’activer.

openstack complete | tee /etc/bash_completion.d/osc.bash_completion
. /etc/bash.bashrc

A tout moment, vous pouvez vous référer à la documentation en ligne d’OpenStack Client.

Consultez les variables d’environnements nécessaires au fonctionnement de la CLI et chargez-les.

cat credentials
. credentials

Comme vous pouvez le voir, vous avez un tenant (un projet), un utilisateur et un mot de passe. Vous avez également une URL d’authentification qui constitue le point central d’OpenStack. Enfin, vous avez également une région, GRA3 ici pour une région située dans le datacenter de Gravelines (FR).

OpenStack permet à un utilisateur de déployer des instances et services dans plusieurs régions depuis un seul compte. Si vous vouliez changer de région, il suffirait de remplacer cette variable par BHS3 par exemple pour adresser Beauharnois (CA). Dans ce workshop nous resterons à GRA3.

Création de la première instance

Avant de créer la première instance, il faut ajouter une clé ssh qui servira à se connecter sur les instances.

openstack keypair create --public-key /root/.ssh/id_rsa.pub mykey

On liste les images systèmes disponibles.

openstack image list

C’est parti, on va démarrer la première instance.

openstack server create --flavor s1-2 --image 'Debian 9' --key-name mykey myinst01

Vérifier que vous avez bien accès en ssh à l’instance en commençant par récupérer l’adresse IP publique.

openstack server show myinst01
ssh debian@XXX.XXX.XXX.XXX

Remarque :

  • La plupart du temps, le nom d’utilisateur à utiliser correspond au nom de la distribution.
  • En cas de doute, pour les image OVH, le nom est consultable dans les propriétés de l’image avec openstack image show « Debian 9 ».

On va simplement modifier le MOTD pour simuler une modification de configuration de l’image plus importante.

debian@myinst01:~$ echo "Welcome workshop 102" | sudo tee /etc/motd

Déloguez vous de l’instance (« Ctrl-D »)

Création d’image système

OVH fournit un certain nombre d’images système prêt à l’usage, mais on va générer de nouvelles images pour apprendre comment faire. Il existe plusieurs méthodes différentes pour créer de nouvelles images :

  • certains éditeurs fournissent des images toutes prêtes, il suffit de les uploader pour les utiliser
  • vous pouvez démarrer depuis une image fournie par OVH et générer un snapshot après vos modifications (méthode la plus courante)
  • vous pouvez utiliser des outils de génération d’image automatisés, très utiles pour l’industrialisation

On va exécuter les deux dernières.

Méthode snapshot

Pour lancer la création d’un snapshot :

openstack server image create --name mysnap01 myinst01

Vous pouvez remarquer que le snapshot intègre des propriétés relatives à l’instance snapshotée. Certaines sont informatives et n’influent pas sur l’utilisation du snapshot, d’autre impactent les instances démarrées à partir de ce snapshot.

Après quelques instants, vérifiez que l’image est bien en état « active ».

openstack image show mysnap01

Maintenant nous allons démarrer une instance à partir du snapshot.

openstack server create --flavor s1-2 --image mysnap01 --key-name mykey myinst02

Une nouvelle fois on va s’authentifier sur cette instance en récupérant l’adresse IP.

openstack server list
ssh debian@XXX.XXX.XXX.XXX

Vous devriez voir votre nouveau MOTD.

Déloguez vous (‘Ctrl-D’).

Méthode industrialisation par outil

Dans cette méthode, nous allons utiliser un outil permettant de générer des images système. Il en existe plusieurs, nous utiliserons un des plus connus, Packer.

Commençons par l’installer.

wget https://releases.hashicorp.com/packer/1.0.2/packer_1.0.2_linux_amd64.zip

unzip -d /usr/local/bin/ packer_1.0.2_linux_amd64.zip

chmod +x /usr/local/bin/packer

Ensuite copiez les lignes suivantes dans un fichier nommé example.json (si l’indentation n’est pas bonne, ce n’est pas grave).

{
  "builders": [{
    "type": "openstack",
    "ssh_username": "debian",
    "image_name": "myimg01",
    "source_image_name": "Debian 9",
    "flavor": "s1-2"
  }],
  "provisioners": [{
    "type": "shell",
    "inline": [
      "sleep 30",
      "sudo apt-get update",
      "sudo apt-get install -y nmap"
    ]
  }]
}

Tout est prêt, lancez la génération de l’image. Ça peut prendre quelques minutes (de 3 à 5 min).

packer build example.json

Pendant que l’image se construit, vous pouvez parcourir la documentation de Packer.

Remarques :

  • Packer utilise son « builder » pour créer l’image, tout se passe dans une instance cloud qui est ensuite snapshotée comme on l’a fait manuellement à l’étape précédente. A l’inverse, certains outils génèrent l’image localement, il faut ensuite l’uploader.
  • OpenStack supporte plusieurs format d’image : iso, qcow2, raw, vmdk, vdi, vhd, aki/ami/ari. Vous pouvez convertir un format vers un autre avec l’outil qemu-img par exemple.

Manipulation de réseaux

OpenStack intègre un composant qui s’appelle Neutron qui a le rôle de SDN.

Utilisation des security groups

Il est possible de gérer le firewall en manipulant des « security groups » qui contiennent des « rules ».

openstack security group list
openstack security group rule list
openstack security group show default

Repérez l’id de la règle ingress (trafic entrant) en IPv4 puis supprimez-la.

openstack security group rule delete XXX

Attendez quelques secondes puis rappelez votre dernière commande ssh pour vous essayer de vous connecter sur myinst02.

On a coupé le trafic entrant. On va ajouter une règle plus restrictive que la précédente mais qu’on puisse quand même se connecter en ssh.

Il faut connaitre notre IP public.

curl ipinfo.io/ip

Maintenant on va ajouter la règle en remplaçant le XXX.

openstack security group rule create --ingress --dst-port 22 --remote-ip XXX --protocol tcp --ethertype IPv4 default

Si vous rappelez votre commande ssh, elle devrait passer maintenant.

Si vous êtes connecté à l’instance, déloguez vous (‘Ctrl-D’).

Création d’un réseau privé

Une autre partie du SDN d’OpenStack permet de créer des réseaux privés à la demande. Ces réseaux privés sont portés par la technologie vRack d’OVH qui permet de relier plusieurs produits sur un réseau isolé quel que soit leur emplacement. Les produits pourraient être à Strasbourg (FR) et Beauharnois (CA) et communiquer sans passer par internet. Dans l’exercice suivant, on va créer un réseau à Gravelines (FR).

OpenStack fonctionne avec des network (L2 OSI) et des subnet (L3 OSI). Un network peut éventuellement porter plusieurs subnets (IPv4 et v6 par exemple).

On commence par créer un network.

openstack network create mypriv01

Ensuite on crée le subnet selon certaines caractéristiques :

  • on le veut adressable sur 10.0.0.0/8
  • toute la plage d’adresse ne doit pas être allouée que sur Gravelines pour permettre la création éventuelle d’autres réseaux 10.0.0.0/8 dans les autres régions
  • on veut que le DHCP soit activé
  • on ne souhaite pas déclarer de gateway
openstack subnet create --network mypriv01 --subnet-range 10.0.0.0/8 --allocation-pool start=10.0.0.2,end=10.0.2.254 --gateway none  mysub01
openstack network list

Nous allons démarrer 3 instances. Remplacez XXX par l’id du réseau public et YYY par l’id du réseau privé. Les interfaces réseaux seront présenter à l’instance dans l’ordre de la ligne de commande.

openstack server create --flavor s1-2 --image myimg01 --key-name mykey --nic net-id=XXX --nic net-id=YYY --max 3 myinst03

Attendez quelques instants que les instances démarrent et connectez-vous en ssh sur l’une de ces 3 instances comme on l’a déjà fait plus haut.

Nous allons voir si les deux autres machines répondent :

debian@myinst03-XXX:~$ sudo nmap -sP 10.0.0.*

A qui appartient la première IP (.2 normalement) selon vous ?

Déloguez vous (‘Ctrl-D’).

Comme on le disait plus haut, la communication inter-region est possible, elle nécessite d’utiliser l’interface client OVH ou l’API OVH afin de manipuler les numéros de VLAN. On ne va pas l’aborder ici mais gardez en tête qu’un réseau privé entre tous les datacenters d’OVH est possible.

Ajout d’un port à chaud

Notre toute première instance est toujours présente, on va lui ajouter une patte sur le réseau privé. On va également choisir l’IP qu’on va attribuer à ce port.

openstack port create --network mypriv01 --fixed-ip subnet=mysub01,ip-address=10.2.2.2 myport01

Dans la commande suivante, remplacez XXX par l’id du port.

nova interface-attach --port-id XXX myinst01

Remarque :

  • L’attachement à chaud n’est pas encore implémenté dans le client OpenStack qui est récent et qui remplace habituellement la commande nova qu’on utilise ici.

Connectez-vous à nouveau sur myinst01 en ssh.

debian@myinst01:~$ ip a s

La seconde interface ne devrait pas avoir d’IP. Nous allons simplement en demander une à la main.

debian@myinst01:~$ sudo dhclient ens6
debian@myinst01:~$ ping 10.0.0.2

Conclusion

Avec la ligne de commande, vous venez de manipuler des images système, des instances et des réseaux. Sans couvrir toutes les fonctionnalités, vous avez eu un bon aperçu de ce qu’on peut faire avec OpenStack et sa CLI.

D’autres éléments existent dans OpenStack comme les volumes ou les containers d’objets qui seront abordés dans d’autres sessions. Nous aurons aussi l’occasion de voir l’orchestration et d’autres fonctions plus avancées.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *