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.

Workflow pour Lab/TP : 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