Automatisation » Historique » Version 23

« Précédent - Version 23/43 (diff) - Suivant » - Version actuelle
Daniel Dehennin, 22/04/2021 11:34

Automatisation
Pré requis pour utiliser cette fonctionnalité
Exigences de fonctionnement
Cas d’usage
- Mise en place d’une infrastructure depuis 0
- Ajout d’un nouveau serveur à l’établissement
Comment fonctionne l'automatisation
Procédure postservice hapy

Automatisation¶

Dans le cas de l'utilisation d'un serveur Hapy, l'utilisateur doit créer ses machines virtuelles manuellement comme expliqué dans un article de blog.

L'idée est de pouvoir proposer une automatisation de ce type de déploiement.

À la suite de l'étude faite par Cadoles :

Nous imposons l'utilisation d'un Zéphir
Les utilisateurs téléchargerons des images pré-crées et distribuées par un marketplace à installer nous même
Nous ne proposons pas de modèle d'infrastructure (Amon + Scribe, Amon + Seth AD + Seth filer, ...) (l'idée serait à travailler plus tard)
Nous proposerons ultérieurement un outillage pour que les utilisateurs puissent créer leurs propres images (l’outillage Cadoles peut être une solution à ce propos)

Pré requis pour utiliser cette fonctionnalité¶

Avoir un Zéphir pour manager les Hâpy et les VM installées sur ces Hâpy
Avoir au moins un Hâpy instancié et configuré.
l'accès vers le dépôt des images Eole/Hâpy doit être possible (proxy,...) (et le dépot préparé)
Les images devront être Cloudifiées (cloud-init ou one-context). Voir #32118

Exigences de fonctionnement¶

Toutes les VM managées utilisent des images persistantes
Toutes les VM sont enregistrées sur Zéphir
Si la VM existe déjà sur l'Hapy, on ne la recrée pas (attention: seul le template peut être actualisé)

Cas d’usage¶

Nous partons du principe qu’un ensemble d’établissement partagent les mêmes caractéristiques :

même topologie réseau: internet, admin, pédago et dmz
même caractéristiques de machine virtuelle (par exemple tous les amons ont la même quantité de RAM, etc)

Mise en place d’une infrastructure depuis 0¶

Le processus global se résume ainsi :

Sur le serveur Zéphir
1. Créer une variante Hâpy pour pré-définir la liste des réseaux virtuels (les adresses IP et autres devront être remplies à la main lors de la configuration de chaque Hâpy)
2. Créer une variante pour Amon afin de définir les paramètres communs de machines virtuelles (RAM, taille de disque, etc)
3. Créer une variante pour Scribe afin de définir les paramètres communs de machines virtuelles (RAM, taille de disque, etc)
4. Pour chaque établissement
  1. Le créer s’il n’existe pas
  2. Créer le serveur Amon de la bonne variante et finir sa configuration
  3. Créer le serveur Scribe de la bonne variante et finir sa configuration
  4. Créer le serveur Hâpy de la bonne variante et finir sa configuration avec notamment la liste des serveurs créés précédemment à déployer automatiquement
Dans chaque établissement
1. Installer physiquement le serveur Hâpy
2. Installer le module EOLE Hâpy
3. Enregistrer le serveur Hâpy sur Zéphir
4. Appliquer la configuration en exécutant la commande instance

Le déploiement des serveurs de l’établissement doit se faire automatiquement sans autre intervention humaine.

Ajout d’un nouveau serveur à l’établissement¶

Nous allons ajouter un serveur Eolebase à l’infrastructure existente.

Le processus global se résume ainsi :

Sur le serveur Zéphir
1. Créer une variante pour Eolebase afin de définir les paramètres communs de machines virtuelles (RAM, taille de disque, etc)
2. Pour chaque établissement
  1. Créer le serveur Eolebase de la bonne variante et finir sa configuration
  2. Éditer la configuration du serveur Hâpy et ajouter l’identifiant du serveur Eolebase à la liste des serveurs à déployer automatiquement
  3. Programmer l’envoie de la configuration du serveur Hâpy
Sur chaque serveur Hâpy
1. S’assurer que la configuration est récuppérer en exécutant la commande synchro_zephir
2. Appliquer la configuration en exécutant la commande reconfigure

Le déploiement du nouveau serveur de l’établissement doit se faire automatiquement sans autre intervention humaine.

NB: L’application de la configuration manuellement sur chaque serveur Hâpy peut être remplacé par l’exécution automatique de la commande reconfigure lors de l’envoie de la configuration.

Comment fonctionne l'automatisation¶

Il faut créer la configuration des VM dans Zéphir (dont les caractéristiques de la VM)¶

Voir #32117

(si le paquet eole-modele-vm n'est pas installé, faire apt-eole install eole-modele-vm)

Pour cela, vous devez activer_modele_vm. Renseigner les variables suivantes :

mémoire : la mémoire en Go (par defaut : la préconisation EOLE pour le module)
vcpu :
Disque Os : nom du disque OS de la VM (par défaut: <eole-module>-<eole-release>) + Taille
Disque Data : nom du disque Data + Taille
Interface 1 : nom du réseau déclaré sur Hapy
Interface 2 : nom du réseau déclaré sur Hapy
Interface 3 : nom du réseau déclaré sur Hapy
Interface X : nom du réseau déclaré sur Hapy

Ceci peut être fait lors de la création des variantes et la création des serveurs. Ce travail reste manuel.

DaD:

Je pense qu’au lieu d’avoir Disque OS et Disque Data il faudrait une liste ordonnée de disque (nom de l’image + taille de l’image + bootable ?)

En fait, si nous utilisons le marketPlace, les choses ne se passent pas du tout comme cela :

Récupérer l’identifiant (ID) de l’Apps (nécessite un nom d’APPS et un nom de marketPlace afin d’éviter les soucis de doublons)
Exporter l’Apps avec son identifiant, cela créé un ID de template et un ID d’image disque

Modifier le template créé avec les caractéristiques récuppérées depuis Zéphir

root@hapy:~# onemarketapp list -f MARKET="OpenNebula Public" | head -n 10
  ID NAME                                   VERSION  SIZE STAT TYPE  REGTIME MARKET     ZONE
 522 Service WordPress - KVM             5.1.3-6.0.    4G  rdy  img 04/01/21 OpenNebula    0
 521 Service GitLab CE - KVM             13.10.0-6.    4G  rdy  img 04/01/21 OpenNebula    0
 520 Service VNF                         6.0.0-1.20 1024M  rdy  img 04/01/21 OpenNebula    0
 519 Service AWS IoT Greengrass - KVM    1.10.2-6.0    4G  rdy  img 04/01/21 OpenNebula    0
 518 Service Virtual Router              6.0.0-1.20 1024M  rdy  img 04/01/21 OpenNebula    0
 517 Service Kubernetes 1.18 - KVM       1.18.18-6.    4G  rdy  img 04/15/21 OpenNebula    0
 516 Vrouter Alpine - vCenter            5.0.2-0.20  256M  rdy  img 11/21/18 OpenNebula    0
 515 Debian 10                           6.0.0-1.20    2G  rdy  img 04/01/21 OpenNebula    0
 514 Ubuntu 20.04                        6.0.0-1.20  2.2G  rdy  img 04/01/21 OpenNebula    0

root@hapy:~# onemarketapp export 515 "My Debian 10" --datastore 101 
IMAGE
    ID: 4
VMTEMPLATE
    ID: 2

<!-- root@hapy:~# onetemplate show -x 2 -->
<VMTEMPLATE>
  <ID>2</ID>
  <UID>0</UID>
  <GID>0</GID>
  <UNAME>oneadmin</UNAME>
  <GNAME>oneadmin</GNAME>
  <NAME>My Debian 10</NAME>
  <PERMISSIONS>
    <OWNER_U>1</OWNER_U>
    <OWNER_M>1</OWNER_M>
    <OWNER_A>0</OWNER_A>
    <GROUP_U>0</GROUP_U>
    <GROUP_M>0</GROUP_M>
    <GROUP_A>0</GROUP_A>
    <OTHER_U>0</OTHER_U>
    <OTHER_M>0</OTHER_M>
    <OTHER_A>0</OTHER_A>
  </PERMISSIONS>
  <REGTIME>1619083814</REGTIME>
  <TEMPLATE>
    <CONTEXT>
      <NETWORK><![CDATA[YES]]></NETWORK>
      <SSH_PUBLIC_KEY><![CDATA[$USER[SSH_PUBLIC_KEY]]]></SSH_PUBLIC_KEY>
    </CONTEXT>
    <CPU><![CDATA[1]]></CPU>
    <DISK>
      <IMAGE_ID><![CDATA[4]]></IMAGE_ID>
    </DISK>
    <GRAPHICS>
      <LISTEN><![CDATA[0.0.0.0]]></LISTEN>
      <TYPE><![CDATA[vnc]]></TYPE>
    </GRAPHICS>
    <INFO><![CDATA[Please do not use this VM Template for vCenter VMs. Refer to the documentation https://bit.ly/37NcJ0Y]]></INFO>
    <LOGO><![CDATA[images/logos/debian.png]]></LOGO>
    <LXD_SECURITY_PRIVILEGED><![CDATA[true]]></LXD_SECURITY_PRIVILEGED>
    <MEMORY><![CDATA[768]]></MEMORY>
    <OS>
      <ARCH><![CDATA[x86_64]]></ARCH>
    </OS>
    <SCHED_REQUIREMENTS><![CDATA[HYPERVISOR!="vcenter"]]></SCHED_REQUIREMENTS>
  </TEMPLATE>
</VMTEMPLATE>

Dans la configuration de l'Hapy,¶

Voir #32118

Activer activer_deploiement_automatique
Saisir la liste des VMs :

Renseigner les Id Zéphir des serveurs devant être déployées sur cet Hapy (id zéphir ou nom de la vm ?)
La liste est ordonnée : les VM sont démarrée dans cette ordre.

RQ: il n'y a pas de contrôle entre la liste des Interfaces déclarées sur Hapy et les Interfaces venant des configurations de VM.

Depuis Zéphir, appliquer la configuration sur le serveur Hâpy¶

La nouvelle configuration est déployé sur la machine Hapy
Le reconfigure est exécuté
les VM vont être installées, instanciées et prêtes à l'usage dans l'ordre de déclaration de la liste des VM

Procédure postservice hapy¶

La création des interfaces aura été faite lors de l’instance/reconfigure de l'Hapy.
Idem pour les datastores....
Idem pour la déclaration du marketplace EOLE/Hapy

Voir postservice : #32120
Voir diagnose : #32123

Si activer_deploiement_automatique = non, stop
Pour chaque IdZéphir
1. récupérer toute la configuration de la VM dans un tar.gz
  1. Vérifier la cohérence des informations Hapy/VMs. Si échec, alors on s'arrête en erreur
2. créer/mettre à jour un FILE dans hapy pour chaque configuration de VM
3. télécharger les images Apps sur l'Hapy
4. créer les images nécessaires Os (et Data si besoin)
5. Créer/mettre à jour un TEMPLATE (Avec une contextualisation active, +Le fichier de Configuration, +Le script de post installation)
6. Démarrer la VM
7. Si l'instance n'est pas faite:
  - réponse aux questions de façon automatique
  - gestion des secrets
8. Monitorer la fin d'instance avant de passer à la suivante.

Projet

Général

Profil

Distribution EOLE » Modules » EOLE OpenNebula

Wiki