Workshop 102 : 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.

nova backup, yet another snapshot/backup feature?

Etat des lieux

On connait nova image-create qui va tout simplement créer un snapshot de l’instance et le rendre disponible dans le catalogue de Glance comme nouvelle image indépendante. Au passage on a droit à un freeze de la machine pendant un temps plus ou moins long. Cette image peu servir pour restaurer l’instance ou en créer une autre sur la même base que la première.

On connait également cinder backup-create, qui permet de créer une copie indépendante d’un volume (le volume doit être « available » donc détaché), elle sera potentiellement placée sur un autre backend.  Cette copie est identifiée comme backup, elle n’est donc pas listée dans les volumes classique mais elle peut être restaurée à tout moment sur un nouveau volume ou sur le volume d’origine.

On a aussi la possibilité de cinder snapshot-create pour faire un snapshot d’un volume. Il sera potentiellement beaucoup plus rapide que le backup en fonction des backend utilisées puisque ce snapshot ne va pas être une copie intégrale du volume mais uniquement un marqueur pour retrouver un état figé des données. Ce snapshot peut être utilisé comme base pour créer de nouveau volume avec cinder create –snapshot-id.

Diantre, mais que fait nova backup alors ?

Pour faire au plus simple, nova backup permet d’assurer la rotation des snapshots d’une instance.

Exemple, je souhaite backuper mon instance tous les dimanches soir et conserver 3 backups dans l’historique. Je vais utiliser la commande :

$ nova backup devstack bkptest-20151129 weekly 3

Pour voir la rotation, allons au 3 dimanche directement.

$ nova backup devstack bkptest-20151213 weekly 3
$ glance image-list
+--------------------------------------+-----------------------------+-------------+------------------+--------------+--------+
| ID                                   | Name                        | Disk Format | Container Format | Size         | Status |
+--------------------------------------+-----------------------------+-------------+------------------+--------------+--------+
| 0e2fe0bd-aa12-43ba-b323-a9f50e41f8dd | bkptest-20151129            | raw         | bare             | 858993459200 | active |
| 0b380436-ad8c-48b7-b422-97b5e946a4f6 | bkptest-20151206            | raw         | bare             | 858993459200 | active |
| af853375-6d59-48d4-8ff8-07bd3fb43271 | bkptest-20151213            | raw         | bare             | 858993459200 | active |
+--------------------------------------+-----------------------------+-------------+------------------+--------------+--------+

La rotation se fera au 4e dimanche soir.

$ nova backup devstack bkptest-20151220 weekly 3
$ glance image-list
+--------------------------------------+-----------------------------+-------------+------------------+--------------+--------+ 
| ID                                   | Name                        | Disk Format | Container Format | Size         | Status |
+--------------------------------------+-----------------------------+-------------+------------------+--------------+--------+ 
| 0e2fe0bd-aa12-43ba-b323-a9f50e41f8dd | bkptest-20151129            | raw         | bare             | 858993459200 | active | 
| 0b380436-ad8c-48b7-b422-97b5e946a4f6 | bkptest-20151206            | raw         | bare             | 858993459200 | active | 
| af853375-6d59-48d4-8ff8-07bd3fb43271 | bkptest-20151213            | raw         | bare             | 858993459200 | active | 
| 98454d8d-1cd5-4ec6-9cae-07ac53a2226a | bkptest-20151220            | raw         | bare             |              | queued |
+--------------------------------------+-----------------------------+-------------+------------------+--------------+--------+

Une fois le backup terminée, le plus ancien est supprimé.

$ glance image-list
+--------------------------------------+-----------------------------+-------------+------------------+--------------+--------+
| ID                                   | Name                        | Disk Format | Container Format | Size         | Status |
+--------------------------------------+-----------------------------+-------------+------------------+--------------+--------+
| 0b380436-ad8c-48b7-b422-97b5e946a4f6 | bkptest-20151206            | raw         | bare             | 858993459200 | active |
| af853375-6d59-48d4-8ff8-07bd3fb43271 | bkptest-20151213            | raw         | bare             | 858993459200 | active |
| 98454d8d-1cd5-4ec6-9cae-07ac53a2226a | bkptest-20151220            | raw         | bare             | 858993459200 | active |
+--------------------------------------+-----------------------------+-------------+------------------+--------------+--------+

Remarques

Vous aurez noté que c’est à moi de lancer les sauvegarde, OpenStack n’a pas encore de scheduler qui permet de programmer cela. Un rapide appel sur l’API depuis une tâche cron permet de faire le travail.

Autre chose est à noter, le mot weekly n’est qu’une information arbitraire, j’aurais pu choisir « my_most_important_backup ». C’est ce qui permet d’identifier le cycle de rotation.

Un essaim de conteneurs piloté par une machine

Présentation des protagonistes

Docker : Est-il vraiment encore nécessaire de présenter Docker…? Docker est un moteur de containers gérant un catalogue d’images et des instances basées sur un système de fichier par couche.

Docker-machine : C’est un outil de déploiement de serveur docker. En lui fournissant les paramètres pour se connecter à un cloud provider, il est capable de démarrer un serveur qui intègrera docker. Docker-machine fournit ensuite une interface de management et connexion aux différents nœuds.

Swarm : C’est un orchestrateur de docker. Il se connecte à plusieurs serveurs docker pour les gérer de manière uniforme et répartir les containers à travers eux.

swarmDonc pour résumer la situation, nous avons un outil de déploiement (docker-machine) qui va nous permettre de déployer des serveurs chez un cloud provider (OVH) ou un orchestrateur (swarm) sera installé pour les contrôler en un seul point et déployer des containers (docker) dessus.

Ça me parait être un super programme !

Installation de docker-machine

Pour l’exemple, nous partirons d’un environnement Debian 8 en user root comme celui fournis sur un server cloud OVH.

On commence par installer docker. Comme seule la partie client nous intéresse ici, on le désactivera directement.

# apt-get update
# apt-get install unzip curl docker.io
# service docker stop
# echo manual | sudo tee /etc/init/docker.override
# curl -L https://github.com/docker/machine/releases/download/v0.5.0/docker-machine_linux-amd64.zip >machine.zip
# unzip machine.zip
# rm machine.zip 
# mv docker-machine* /usr/local/bin

That’s it !

Maintenant on va avoir besoin de charger dans l’environnement les variables habituelles nécessaire à la communication avec les API d’OpenStack, le fameux fichier openrc.sh. Vous devez avoir l’habitude, sinon rendez-vous ici.

Déploiement de Swarm

On va avoir besoin d’un token Swarm. Pour cela, on va simplement créer un nœud docker-machine, exécuter swarm et récupérer le token.

$ docker-machine create -d openstack \
--openstack-flavor-name="vps-ssd-1" \
--openstack-image-name="Ubuntu 14.04" \
--openstack-net-name="Ext-Net" \
--openstack-ssh-user="admin" \
swarm-token-generator

Notre premier déploiement grâce à docker-machine est fait, voici comment l’utiliser.

$ eval "$(docker-machine env swarm-token-generator)"

On est prêt pour lancer notre premier docker et par la même occasion récupérer le token.

$ docker run swarm create
1257e0f0bbb49dbdcd04b4c9beb2dab3

Noter bien cette chaine de caractère.

Notre serveur swarm-token-generator ne nous servira plus, vous pouvez le supprimer.

$ docker-machine rm --force swarm-token-generator

C’est parti pour le déploiement de swarm à proprement parlé. Commençons par le master.

$ docker-machine create -d openstack \
--openstack-flavor-name="vps-ssd-1" \
--openstack-image-name="Ubuntu 14.04" \
--openstack-net-name="Ext-Net" \
--openstack-ssh-user="admin" \
--swarm --swarm-master --swarm-discovery \
token://VOTRE_TOKEN docker-machine-swarm-master

Maintenant il ne reste plus qu’à déployer autant de nœud que nécessaire.

$ docker-machine create -d openstack \
--openstack-flavor-name="vps-ssd-1" \
--openstack-image-name="Ubuntu 14.04" \
--openstack-net-name="Ext-Net" \
--openstack-ssh-user="admin" \
--swarm --swarm-discovery \
token://VOTRE_TOKEN docker-machine-swarm-node01

Pour consulter la liste des nœuds déployés par docker-machine, vous pouvez utiliser « docker-machine ls ».

Docker jusqu’à plus soif

Avec notre cluster swarm, il est maintenant possible de gérer tous nos nœuds avec un seul point d’entré qui sera le swarm master. La répartition des containers sera faite par le master.

On va charger l’environnement et récupérer l’image docker ubuntu.

$ eval "$(docker-machine env --swarm docker-machine-swarm-master)"
$ docker pull ubuntu
docker-machine-swarm-node02: Pulling ubuntu:latest... : downloaded 
docker-machine-swarm-master: Pulling ubuntu:latest... : downloaded 
docker-machine-swarm-node01: Pulling ubuntu:latest... : downloade

Pour constater la bonne initialisation du cluster :

$ docker info
Containers: 4
Images: 6
Storage Driver:
  Role: primary
  Strategy: spread
  Filters: health, port, dependency, affinity, constraint
  Nodes: 3
 docker-machine-swarm-master: 158.69.94.60:2376
  └ Containers: 2
  └ Reserved CPUs: 0 / 1
  └ Reserved Memory: 0 B / 2.004 GiB
  └ Labels: executiondriver=native-0.2, kernelversion=3.13.0-44-generic, operatingsystem=Ubuntu 14.04.1 LTS, provider=openstack, storagedriver=aufs
 docker-machine-swarm-node01: 158.69.94.66:2376
  └ Containers: 1
  └ Reserved CPUs: 0 / 1
  └ Reserved Memory: 0 B / 2.004 GiB
  └ Labels: executiondriver=native-0.2, kernelversion=3.13.0-44-generic, operatingsystem=Ubuntu 14.04.1 LTS, provider=openstack, storagedriver=aufs
 docker-machine-swarm-node02: 158.69.94.68:2376
  └ Containers: 1
  └ Reserved CPUs: 0 / 1
  └ Reserved Memory: 0 B / 2.004 GiB
  └ Labels: executiondriver=native-0.2, kernelversion=3.13.0-44-generic, operatingsystem=Ubuntu 14.04.1 LTS, provider=openstack, storagedriver=aufs
Execution Driver:
Kernel Version:
Operating System:
CPUs: 3
Total Memory: 6.011 GiB
Name: 94d31dd697b1
ID:
Http Proxy:
Https Proxy:
No Proxy:

Il est temps de lancer des containers par dizaines.

$ for i in $(seq 1 200); do docker run -i -t -d ubuntu /bin/bash; done

Une fois terminé, je vous laisse faire un « docker ps » et apprécier.

Workshop 101 : Prise en main

Chaque utilisateur a reçu un numéro. Ce numéro sera utilisé à différente reprise par la variable $ID. Chaque fois que vous voyer $ID, pensez à le remplacer par le numéro qui vous a été fournit.

  1. Se loguer en SSH sur la machine rebond
    1. L’adresse IP de la machine rebond sera communiquée au moment du lab
    2. L’utilisateur est : bounce
    3. Le mot de passe sera communiqué au moment du lab
    4. Ce qui donne :
      ssh bounce@XXX.XXX.XXX.XXX
    5. Une fois loggé, se connecter en root sur localhost en utilisant le port 22$ID, ce qui donne :
      ssh -p 22$ID root@localhost
    6. Le mot de passe sera communiqué au moment du lab
  2. Générer une clé SSH
    1. Nous aurons besoin d’une clé ssh par la suite, pour la générer, utiliser :
      ssh-keygen
    2. Valider chaque choix par la valeur par défaut en utilisant Enter.
  3. Se loguer sur Horizon
    1. Consulter le fichier credentials dans le home de l’utilisateur :
      cat credentials
    2. S’identifier avec ces informations sur la page : https://horizon.cloud.ovh.net/
  4. Upload de la clé ssh
    1. Avant de lancer une instance, nous allons ajouter notre clé ssh, aller dans l’onglet « Access & Security » puis « Key Pairs »
    2. « Import Key Pair » et lui donner le nom « $ID-mykey »
    3. Afficher le contenu de la clé depuis le terminal et le copier/coller :
      cat .ssh/id_rsa.pub
    4. Valider
  5. Démarrer une instance
    1. Aller dans l’onglet « Instances »
    2. Cliquer sur « Launch Instances »
    3. Nommer votre instance « $ID-inst01 »
    4. Utiliser la flavor vps-ssd-1
    5. Selectionner « Boot from Image »
    6. Selectionner l’image « Debian 8 »
    7. Dans l’onglet « Acces & Security », verifier que « $ID-mykey » soit selectionné
    8. Lancer la création de l’instance avec le bouton « Launch »
    9. Patienter jusqu’à ce que l’instance soit « Active »
  6. Ajouter un volume
    1. Dans l’onglet « Volume », cliquer sur « Create Volume »
    2. Donner le nom « $ID-vol01 »
    3. Sélectionner le « Type » « classic »
    4. Changer la « size » à 5 GB
    5. Créer le volume en validern par « Create Volume »
    6. Deployer le menu à la fin de la ligne du volume avec la petite flèche et cliquer sur « Edit Attachement »
    7. Dans le menu déroulant « Attach to instance », sélectionner l’instance « $ID-inst01 » et Valider par « Attach Volume »
  7. Se connecter à l’instance
    1. Récupérer l’adresse publique de l’instance dans l’onglet « Instances »
    2. Se connecter directement avec :
      ssh admin@$IP_PUBLIC
    3. Vérifier la présence du volume avec la commande :
      sudo fdisk -l /dev/sdb
    4. Se déconnecter avec :
      exit
  8. Récupérer openrc.sh
    1. Aller à l’onglet « Acces & Security » puis « API Access »
    2. Cliquer sur « Download OpenStack RC File »
    3. Ovrir le fichier avec un éditeur de texte puis copier/coller
    4. Dans la console ssh, créer un nouveau fichier :
      vi openrc.sh
    5. Dans vi, passer en mode insertion avec la touche « i »
    6. Coller
    7. Sauvegarder avec la séquance « Esc : x  Enter »
    8. Charger l’environnement avec la commande :
      source openrc.sh
    9. Renseigner le mot de passe issu du fichier credentials et valider
  9. Installer les clients
    1. Installer le client en ligne de commande pour Nova (compute) :
      apt-get install -y python-novaclient
  10. Détruire l’instance précédente
    1. Nous allons commencer par lister l’instance créée dans Horizon :
      nova list

      Ce listing devrait afficher toute les instances du Lab

    2. Repérer votre instance et supprimer la :
      nova delete $ID-inst01
  11. Démarrer une instance en ligne de commande
    1. Lister les images et récupérer l’ID de l’image « Debian 8 »:
      nova image-list
    2. Lister les flavors et récupérer l’ID de la flavor « vps-ssd-1 »:
      nova flavor-list
    3. Lister les clé ssh et vérifier bien que la clé « $ID-mykey » est bien présente:
      nova keypair-list
    4. Démarrer l’instance avec la commande:
      nova boot --image $id_image --flavor $id_flavor --key-name $ID-mykey $ID-inst02
    5. Observer son changement de « status » jusqu’à voir « ACTIVE » avec la commande:
      nova show $ID-inst02
  12. Détruire l’instance de la même manière que précédemment
  13. Consulter les scripts applicatifs pour prendre connaissance de la syntaxe du script de post-boot
    Ce format de configuration peut être utiliser pour initialiser tout type de logiciel.

    1. Au choix, vous pouvez utiliser wordpress ou etherpad:
      cat wordpress.yaml
      cat etherpad.yaml
  14. Relancer l’instance avec le script en paramètre pour automatiser le déploiement, utiliser la commande de votre choix parmi:
    1. nova boot --image $id_image --flavor $id_flavor --key-name $ID-mykey --user-data wordpress.yaml $ID-inst03
    2. nova boot --image $id_image --flavor $id_flavor --key-name $ID-mykey --user-data etherpad.yaml $ID-inst03
    3. Suivre l’état de l’instance jusqu’au status « ACTIVE » avec la commande :
      nova show $ID-inst03
    4. Attendre une minute ou deux puis ouvrir un navigateur en utilisant l’adresse IP de l’instance et constater le résultat

Synchronisation de containers

C’est tellement simple que je ne résiste pas à faire un petit article.

Pour l’occasion, je souhaite synchroniser deux containers dans des régions différentes.

export OS_REGION_NAME=GRA1; swift post --sync-key mySecretSyncKey --sync-to "https://storage.sbg1.cloud.ovh.net/v1/AUTH_MYACCOUNT/myContainer" myContainer
export OS_REGION_NAME=SBG1; swift post --sync-key mySecretSyncKey --sync-to "https://storage.gra1.cloud.ovh.net/v1/AUTH_MYACCOUNT/myContainer" myContainer

De cette manière, les updates faites d’un côté ou de l’autre seront poussées de l’autre côté, c’est donc valable dans les deux sens.

Et il est même possible de chainer plusieurs containeurs.

L’OpenStack Summit en 7 citations

J’ai eu la chance de participer à l’OpenStack Summit les 3-4-5 novembre 2014, un moment que j’attendais depuis longtemps. Cet événement est allé au-delà de mes attentes et concrétise vraiment l’impression de participer à une communauté embarquée dans un train lancé à pleine vitesse. J’ai mis de côté quelques citations qui m’ont marquées.

Continuer la lecture de L’OpenStack Summit en 7 citations