Dans ce qui va suivre nous allons procéder aux étapes permettant l’intégration de Heat, l’orchestrateur de conteneurs d’OpenStack. En effet, il n’est pas forcement évident qu’il soit installé avec l’ensemble des autres modules puisque dans la distribution “DevStack” Heat n’est pas compris dans l’installation. Il reste toutefois possible de l’intégrer de deux méthodes différentes (du moins c’est ce qui est porté à notre connaissance pour l’instant).
Méthode 1 : Intégration avant l’installation
L’idée ici est de préciser dans le fichier de configuration local.conf de “enable” le module Heat (ou en d’autres termes, de prendre en compte son installation).
Pour les versions strictement antérieurs à 2016-10-14 (qui est la première version à laquelle on a donné un nom, qui est “Newton”) il faut lister les services constituants du module comme ceci :
enable_service h-eng h-api h-api-cfn h-api-cw
À partir de la version Newton et toutes celles qui ont suivis, où Heat est considéré comme un plugin, il faut écrire la ligne suivante (toujours dans le fichier local.conf) :
enable_plugin heat https://git.openstack.org/openstack/heat
Pour les petits coquins qui voudraient préciser au programme d’installation la branche la plus stable il faudrait écrire :
enable_plugin heat https://git.openstack.org/openstack/heat stable/newton
Dans cet exemple c’est la version Newton qui est à installer.
Méthode 2 : Intégration après l’installation
Pour ceux qui ont dû installer un OpenStack (ou DevStack) dénué de son Heat (votre serviteur) puis se sont rendu compte qu’il fallait l’intégrer à l’installation existante ne vous inquiétez pas, il est possible de l’intégrer à votre installation existante. Cela-dit, il faudrait faire un peu plus de choses que pour la méthode précédente.
En effet, il faudrait suivre les étapes suivantes :
- Créer une base de données pour Heat et donner les privilèges à l’utilisateur (système)
$ heat - Définir des variables d’environnement
- Créer un utilisateur
heat(openstack) et lui donner le rôle d’administrateur - Créer les services
- Créer les points d’entrés des APIs (un pour chaque service)
- Mettre en place le domaine
- Installer les packages
- Configurer Heat
- Redémarrer les services
1. Création de la base
Heat utilise MySql comme SGBD, il faut donc se connecter en tant que root à l’aide de la commande suivante :
$ mysql -u root -p
Puis créer la base sous le nom “heat” comme suit :
mysql> CREATE DATABASE heat;
Ensuite, donner les privilèges sur toutes les tables sous le schéma heat ;
A) Pour les connexions en localhost :
mysql> GRANT ALL PRIVILEGES ON heat.* TO 'heat'@'localhost' IDENTIFIED BY <heat_db_user_password>;
B) Pour les connexions à partir de n’importe quelle provenance :
mysql> GRANT ALL PRIVILEGES ON heat.* TO 'heat'@'%' IDENTIFIED BY <heat_db_user_password>;
Enfin, revenir en ligne de commandes avec un simple quit.
2. Définition des variables d’environnement
OpenStack a besoin de connaitre un certain nombre de choses pour procéder à l’installation, ou du moins à certaines étapes (comme la suivante qui consiste à créer un utilisateur).
Ces choses là sont les informations sur l’environnement ; Utilisateur (système), Mot de passe (de l’utilisateur système), URL d’authentification (une adresse spécifique faisant appel à l’API de Keystone pour l’authentification), le nom de domaine de l’utilisateur ainsi que celui du projet.
Une solution est de créer un fichier, qu’on nommera admin-openrc.sh, dans lequel on définit toutes ces variables d’environnement comme suit :
export OS_USERNAME=heat export OS_PASSWORD=<password> export OS_TENANT_NAME=heat export OS_AUTH_URL=<ip_address>/identity export OS_PROJECT_DOMAIN_NAME=default export OS_USER_DOMAIN_NAME=heat
N’oubliez pas de remplacer <password> et <ip_address> par vos valeurs. L’adresse IP à utiliser est l’adresse IP ou le nom du hôte pour le nœud sur lequel vous avez décidé d’installer Heat
Après avoir créé ce fichier, il faudrait l’exécuter avec un coup de :
$ . admin-openrc.sh
Ou alors :
$ source admin-openrc.sh
3. Création d’un utilisateur OpenStack pour Heat
Ici nous allons utiliser la commande openstack pour créer un utilisateur dans OpenStack. Cet utilisateur est destiné à l’administration du module que nous nous apprêtons à installer. Nous l’appellerons heat (une question d’originalité) par la commande suivante :
$ openstack user create --domain default --password-prompt heat
Explication des arguments et options de la commande :
user: Cet argument permet de dire qu’on veut faire une opération sur les utilisateurs dans OpenStack.create: Est un deuxième argument qui stipule l’opération qu’on veut faire (qui, en l’occurrence, est une création).--domain: Est une option pour préciser sur quel domaine d’OpenStack (et non pas pour le module Heat) sera défini ce nouvel utilisateur et auquel la valeur attribuée dans l’exemple est “default”.--password-prompt: Est une option qui a pour but de demander à saisir le mot de passe à attribuer à l’utilisateur.heat: Les nom de l’utilisateur à créer.
Vous aurez une sortie qui devrait être semblable à celle-ci :
User Password:
Repeat User Password:
+---------------------+----------------------------------+
| Field | Value |
+---------------------+----------------------------------+
| domain_id | default |
| enabled | True |
| id | e3957881e9bf4fee847e22af92723f5b |
| name | heat |
| options | {} |
| password_expires_at | None |
+---------------------+----------------------------------+
Il faut maintenant attribuer à ce nouvel utilisateur le rôle d’administrateur dans OpenStack. Pour ça il faut exécuter la commande suivante :
$ openstack role add --project service --user heat admin
Encore une explication des arguments :
role: Argument pour dire qu’on veut opérer sur les rôles des utilisateurs.add: Argument pour préciser l’opération, qui, ici, est l’attribution d’un rôle existant à un utilisateur.--project: Une option pour attribuer le rôle pour un projet donné (ici c’est pour le projet “service”).--user: L’option qui précise l’utilisateur auquel on veut attribuer un rôle (dans notre cas “heat”, qui a été créé précédement).admin: Le rôle attribué à l’utilisateur.
Cette commande ne donne aucune sortie.
4. Création des services
Nous allons maintenant procéder à la création des services heat et heat-cfn :
$ openstack service create --name heat --description "Orchestration" orchestration +-------------+----------------------------------+ | Field | Value | +-------------+----------------------------------+ | description | Orchestration | | enabled | True | | id | 0dd42c77e4344ea4bf796d76dda31ba7 | | name | heat | | type | orchestration | +-------------+----------------------------------+
$ openstack service create --name heat-cfn --description "Orchestration" cloudformation +-------------+----------------------------------+ | Field | Value | +-------------+----------------------------------+ | description | Orchestration | | enabled | True | | id | eb9bdbcbcf0a44eab41fe5f025e40d1f | | name | heat-cfn | | type | cloudformation | +-------------+----------------------------------+
5. Création des points d’entrés
Pour chaque service créé dans l’étape précédente, on défini des points d’entrés pour son API. Ces derniers sont les points ; publique, interne et administrateur.
A. Points d’entrés du service “orchestration”
Pour le point d’entré publique :
$ openstack endpoint create --region RegionOne orchestration public <ip_address>:8004/v1/%\(tenant_id\)s +--------------+-------------------------------------------+ | Field | Value | +--------------+-------------------------------------------+ | enabled | True | | id | 05233060158443e0bb7c9620ce457c60 | | interface | public | | region | RegionOne | | region_id | RegionOne | | service_id | 0dd42c77e4344ea4bf796d76dda31ba7 | | service_name | heat | | service_type | orchestration | | url | <ip_address>:8004/v1/%(tenant_id)s | +--------------+-------------------------------------------+
Encore une fois , veillez à remplacer <ip_address> par l’adresse IP (ou le nom du hôte) du nœud contrôleur (c’est à dire la machine qui héberge Heat, c’est utile quand on décide d’une architecture d’OpenStack où les modules utilisés ne sont pas sur le même nœud).
De même pour le point d’entré interne :
$ openstack endpoint create --region RegionOne orchestration internal <ip_address>:8004/v1/%\(tenant_id\)s +--------------+-------------------------------------------+ | Field | Value | +--------------+-------------------------------------------+ | enabled | True | | id | 28b8016965fc4b06af12aa3c78cccfe3 | | interface | internal | | region | RegionOne | | region_id | RegionOne | | service_id | 0dd42c77e4344ea4bf796d76dda31ba7 | | service_name | heat | | service_type | orchestration | | url | <ip_address>:8004/v1/%(tenant_id)s | +--------------+-------------------------------------------+
Et enfin, pour l’administrateur :
$ openstack endpoint create --region RegionOne orchestration admin <ip_address>:8004/v1/%\(tenant_id\)s +--------------+-------------------------------------------+ | Field | Value | +--------------+-------------------------------------------+ | enabled | True | | id | 73490ffb1f944db1a9bbbe1eea511b4c | | interface | admin | | region | RegionOne | | region_id | RegionOne | | service_id | 0dd42c77e4344ea4bf796d76dda31ba7 | | service_name | heat | | service_type | orchestration | | url | <ip_address>:8004/v1/%(tenant_id)s | +--------------+-------------------------------------------+
B. Points d’entrés du service “cloudformation”
Pour le point d’entré publique :
$ openstack endpoint create --region RegionOne cloudformation public <ip_address>:8000/v1 +--------------+----------------------------------+ | Field | Value | +--------------+----------------------------------+ | enabled | True | | id | f394c9a7e1c74878ae93b64ce88822a8 | | interface | public | | region | RegionOne | | region_id | RegionOne | | service_id | eb9bdbcbcf0a44eab41fe5f025e40d1f | | service_name | heat-cfn | | service_type | cloudformation | | url | <ip_address>:8000/v1 | +--------------+----------------------------------+
Ensuite pour le point d’entré interne :
$ openstack endpoint create --region RegionOne cloudformation internal <ip_address>:8000/v1 +--------------+----------------------------------+ | Field | Value | +--------------+----------------------------------+ | enabled | True | | id | 1f4d7892a6c44ee0969bbc1887956683 | | interface | internal | | region | RegionOne | | region_id | RegionOne | | service_id | eb9bdbcbcf0a44eab41fe5f025e40d1f | | service_name | heat-cfn | | service_type | cloudformation | | url | <ip_address>:8000/v1 | +--------------+----------------------------------+
Et enfin pour l’administrateur :
$ openstack endpoint create --region RegionOne cloudformation admin <ip_address>:8000/v1 +--------------+----------------------------------+ | Field | Value | +--------------+----------------------------------+ | enabled | True | | id | 68a83c0d04a542dd821d818189de7cee | | interface | admin | | region | RegionOne | | region_id | RegionOne | | service_id | eb9bdbcbcf0a44eab41fe5f025e40d1f | | service_name | heat-cfn | | service_type | cloudformation | | url | <ip_address>:8000/v1 | +--------------+----------------------------------+
6. Mise en place du domaine
Les domaines sont une notion de gestion de droits d’accès sur un ensemble de projets pour un groupe d’utilisateur. Afin d’avoir une définition plus détaillé de ce que sont les domaines, je vous invite à lire cet article.
Ici, nous allons créer un domaine pour heat, puis un utilisateur administrateur de ce dernier et lui donner les droits d’administration. Suite à celà il faudrait définir un utilisateur standard qui sera l’exploitant de Heat.
Commençons par le domaine “heat” :
$ openstack domain create --description "Stack projects and users" heat +-------------+----------------------------------+ | Field | Value | +-------------+----------------------------------+ | description | Stack projects and users | | enabled | True | | id | 9ff4f84437894dedbb1664b41cf22ff9 | | name | heat | | tags | [] | +-------------+----------------------------------+
Ensuite, nous créons l’utilisateur administrateur de heat, le “heat-domain-admin”.
$ openstack user create --domain heat --password-prompt heat_domain_admin
User Password:
Repeat User Password:
+---------------------+----------------------------------+
| Field | Value |
+---------------------+----------------------------------+
| domain_id | 9ff4f84437894dedbb1664b41cf22ff9 |
| enabled | True |
| id | 6a65644647984a55a8f528c058690d3e |
| name | heat_domain_admin |
| options | {} |
| password_expires_at | None |
+---------------------+----------------------------------+
Attribution du rôle d’administrateur :
$ openstack role add --domain heat --user-domain heat --user heat_domain_admin admin
Création d’un rôle standard “heat-stack-owner” qui permet aux utilisateurs qui en disposent de créer des “stacks” (ou piles de ressources) Heat et dont il est propriétaire.
$ openstack role create heat_stack_owner +-------------+----------------------------------+ | Field | Value | +-------------+----------------------------------+ | description | None | | domain_id | None | | id | d151483ce356485f9fabd43d04e4b796 | | name | heat_stack_owner | +-------------+----------------------------------+
Attribuer ce rôle à l’utilisateur “demo” :
$ openstack role add --project demo --user demo heat_stack_owner
On peut aussi créer un rôle, qu’on utilisera peut-être plus tard, pour les utilisateurs non-propriétaires des piles de ressources (ou stacks).
$ openstack role add --project demo --user demo heat_stack_owner stack@khalil:~/devstack$ openstack role create heat_stack_user +-------------+----------------------------------+ | Field | Value | +-------------+----------------------------------+ | description | None | | domain_id | None | | id | 1046beaa33104cbebac85d0fd3e8d2af | | name | heat_stack_user | +-------------+----------------------------------+
7. Installation des packages Heat
On procède maintenant à l’installation des packages du module Heat.
$ sudo apt install heat-api heat-api-cfn heat-engine
8. Configuration
Suite à l’installation des packages qui composent le module Heat, il nous faut apporter des changement (ou plutôt ajouter ce qui manque) au fichier /etc/heat/heat.conf. Ces derniers sont les suivants :
[database] connection = mysql+pymysql://heat:HEAT_DBPASS@<ip_address>/heat [DEFAULT] transport_url = rabbit://openstack:RABBIT_PASS@<ip_address> heat_metadata_server_url = http://<ip_address>:8000 heat_waitcondition_server_url = http://<ip_address>:8000/v1/waitcondition stack_domain_admin = heat_domain_admin stack_domain_admin_password = <heat_domain_pass> stack_user_domain_name = heat [keystone_authtoken] auth_uri = http://<ip_address>:5000 auth_url = http://<ip_address>:35357 memcached_servers = <ip_address>:11211 auth_type = password project_domain_name = default user_domain_name = default project_name = service username = heat password = <heat_pass> [trustee] auth_type = password auth_url = http://<ip_address>:35357 username = heat password = <heat_pass> user_domain_name = default [clients_keystone] auth_uri = http://<ip_address>:5000
En prenant bien le soin de remplacer les valeurs de <ip_address>, <heat_domain_pass> et <heat_pass> par l’adresse du nœud hébergeant Heat, le mot de passe pour le domaine Heat et le mot de passe de l’utilisateur “heat” respectivement par les bonnes valeurs (celles définies dans les étapes précédentes).
Il est important de noter que le contenu précédent n’est pas à prendre en copier/coller directement, puisqu’il faut mettre chaque ligne (ou ensemble de lignes) dans la section correspondante. Le début de section est définit par un mot clé entre crochets ([mot_cle]) et sa fin par soit le début d’une autre section, soit la fin du fichier. Il faut donc copier les lignes appropriées à chaque section et les coller dans le fichier à l’endroit approprié.
9. Redémarrer les services
Une fois la configuration faite, on procède au redémarrage des services Heat par les commandes suivantes :
$ service heat-api restart $ service heat-api-cfn restart $ service heat-engine restart
Un peu de troubleshooting
Dans cette partie, nous allons lister quelques erreurs rencontrées lors de l’intégration (par la méthode 2) de Heat dans une installation existante d’OpenStack et leurs significations, ainsi que les solutions qui y remédient.
La première erreur que nous verrons est la suivante :
Missing value auth-url required for auth plugin password
Celle-ci veut dire que la variable OS_AUTH_URL n’est pas défini, il faudrait donc faire un $ export OS_AUTH_URL=<ip_address>/identity, ou alors renseigner cette ligne dans le fichier admin-openrc.sh.
La deuxième erreur que vous êtes susceptible de rencontrer est :
Expecting to find domain in project. The server could not comply with the request since it is either malformed or otherwise incorrect. The client is assumed to be in error. (HTTP 400) (Request-ID: req-724c3b00-68c4-47f2-8327-feae0afc1539)
Cela-dit, avec un “Request-ID” différent. Cette erreur veut dire que la variable OS_PROJECT_DOMAIN_NAME n’est pas défini. Il faudrait de la même manière que la précédente de lui donner une valeur, nous lui donnerons “default” pour notre exemple.
Et enfin, une dernière erreur :
Expecting to find domain in user. The server could not comply with the request since it is either malformed or otherwise incorrect. The client is assumed to be in error. (HTTP 400) (Request-ID: req-31dd16a2-8edf-4bcc-9c9d-ceb2b02e8342)
Pour laquelle cette fois-ci c’est la variable OS_USER_DOMAIN_NAME qui n’est pas défini, et où on attribuera la valeur “heat”.
Saif Al-Qazweny, Khalil Hamani, Abdelhaq Ouattari
