kokou Agbedanou

L’orchestration

1. La brique Heat

a. Objectif

Heat permet de déployer des composants divers comme des serveurs, du réseau, du stockage ou du
middleware à partir d’un fichier de description. L’objectif est donc d’automatiser le déploiement de
workloads avancés.

Heat est apparue officiellement avec la version Havana (octobre 2013). C’est une technologie qui est
importée du service CloudFormation (CFN) d’Amazon (AWS).

Le principe réside dans la description de l’architecture cible au sein d’un fichier template (par exemple, une
architecture à base de deux serveurs front-end web, deux serveurs d’applications de back-end et deux
serveurs de bases de données).

Ce template est instancié en stack et c’est le composant Heat qui va se charger d’effectuer les demandes
de ressources aux différents services d’OpenStack (Nova, Neutron...).

Heat permet une interaction avec les outils de gestion de configuration tels que Puppet, Ansible, Salt, Chef
ou directement avec du scripting shell Bash.

Les outils de DevOps sont présentés dans le chapitre Du IaaS au PaaS.

b. Fichier template

Initialement basé sur CFN, HOT (Heat Orchestration Template) est le nouveau format de description d’un
template Heat, basé sur le langage YAML.

Exemple de fichier template

heat_template_version: 2013-05-23

description: Simple template to deploy a single compute instance

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -1-
 kokou Agbedanou

resources:
my_instance:
type: OS::Nova::Server
properties:
key_name: my_key
image: F18-x86_64-cfntools
flavor: m1.small

Ce fichier permet de décrire une stack permettant de déployer une instance de compute basée sur l’image
F18-x86_64-cfntools et de flavor m1.small.

Exemple avec des paramètres d’entrée

Dans cet exemple, il s’agit de déployer une instance de compute à partir de paramètres en entrée :
key_name, image_id et instance_type.

heat_template_version: 2013-05-23

description: Simple template to deploy a single compute instance

parameters:
key_name:
type: string
label: Key Name
description: Name of key-pair to be used for compute instance
image_id:
type: string
label: Image ID
description: Image to be used for compute instance
instance_type:
type: string
label: Instance Type
description: Type of instance (flavor) to be used
constraints:
- allowed_values: [ m1.medium, m1.large, m1.xlarge ]
description: Value must be one of m1.medium, m1.large or

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -2-
 kokou Agbedanou

m1.xlarge.

Resources:
my_instance:
type: OS::Nova::Server
properties:
key_name: { get_param: key_name }
image: { get_param: image_id }
flavor: { get_param: instance_type }
database_password:
type: string
label: Database Password
description: Password to be used for database
hidden: true

Fonction de sortie de Heat

En fin d’exécution du template, Heat est capable de fournir des informations d’output :

outputs:
instance_ip:
description: The IP address of the deployed instance
value: { get_attr: [my_instance, first_address] }

Source : http://docs.openstack.org/developer/heat/template_guide/hot_guide.html

c. Cas d’utilisation

ˇ
Autoscaling de ressources

L’autoscaling est une composante matérialisant l’élasticité des ressources managées par
OpenStack. Elle permet d’étendre la capacité des ressources des machines.

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -3-
 kokou Agbedanou

ˇ
Provisionning de clusters de calcul

Bien sûr, OpenStack est avant tout un IaaS capable de produire des VM à la chaîne et en
parallèle. La plate-forme n’a aucun intérêt pour produire trois VM pour une application legacy
qui n’évolue jamais et dont la charge est connue.

ˇ
Automatisation de la création d’environnement de test

OpenStack expose des services internes au travers d’une API : il est donc possible d’utiliser un
programme externe pour automatiser les tâches de provisionning. Ainsi, un programme Java
peut donc dialoguer avec l’API OpenStack pour créer automatiquement une VM de test à partir
d’un template.

Élasticité du service sous OpenStack avec Heat et Telemetry

2. Migration de versions OpenStack

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -4-
 kokou Agbedanou

Comme il existe une nouvelle version tous les six mois, avec son lot de changements, il se pose la
problématique de l’upgrade de version.

Il est évident que migrer de Juno à Kilo ne peut se faire directement en production, sans avoir à effectuer
les backups indispensables des différents services.

Plusieurs méthodes sont possibles :

ˇ
Utiliser des versions commerciales d’OpenStack et les outils de migration supportés ; c’est la
méthode à retenir de toute façon en cas d’utilisation d’OpenStack en production.
ˇ
Construire une nouvelle architecture avec la nouvelle version d’OpenStack et copier le contenu
des bases de données MySQL et les contenus adaptés des fichiers de configuration
customisés de l’ancienne version vers la nouvelle.
ˇ
Utiliser la procédure d’upgrade sur la version en cours.

Par exemple, sous Fedora, il est possible d’utiliser la commande yum upgrade yum install
.
http://rdo.fedorapeople.org/openstack-kilo/rdo-release-kilo.rpm

Puis, ensuite, il faut stopper tous les services et upgrader (dans l’ordre) les services avec les commandes
adéquates ; pour le service Keystone, il faut lancer les commandes suivantes : keystone-manage
db_sync et yum install python-openstackclient
.

 Cela demande beaucoup de manipulations, rendant le retour arrière impossible,

sauf à restaurer l’ensemble de la stack.

3. Déploiement d’OpenStack

Tous les composants d’OpenStack peuvent être installés et déployés de façon manuelle (voir le chapitre
Installation OpenStack : services de base et Installation OpenStack :

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -5-
 kokou Agbedanou

services avancés). Il est également possible d’utiliser des logiciels spécifiques facilitant son déploiement
comme par exemple :

ˇ
Fuel de Mirantis (https://wiki.openstack.org/wiki/Fuel).
ˇ
RDO Manager (http://www.rdoproject.org/RDO-Manager).

RDO (Red Hat Distribution of OpenStack) est la version communautaire de la distribution OpenStack de
Red Hat.

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -6-