Automatisation » Historique » Version 22
Version 21 (Daniel Dehennin, 14/04/2021 16:22) → Version 22/43 (Daniel Dehennin, 14/04/2021 16:32)
{{>toc}}
h1. 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":https://pcll.ac-dijon.fr/eole/utiliser-hapy-virtualiser-modules-eole/.
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":https://docs.opennebula.io/6.0/management_and_operations/storage_management/marketplaces.html#public-marketplaces à installer "nous même":https://github.com/OpenNebula/appmarket-simple
* 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)
h1. 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
h1. 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é)
h1. 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)
h2. Mise en place d’une infrastructure depuis 0
Le processus global se résume ainsi :
# Sur le serveur Zéphir
## 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)
## Créer une variante pour Amon afin de définir les paramètres communs de machines virtuelles (RAM, taille de disque, etc)
## Créer une variante pour Scribe afin de définir les paramètres communs de machines virtuelles (RAM, taille de disque, etc)
## Pour chaque établissement
### Le créer s’il n’existe pas
### Créer le serveur Amon de la bonne variante et finir sa configuration
### Créer le serveur Scribe de la bonne variante et finir sa configuration
### 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
## Installer physiquement le serveur Hâpy
## Installer le module EOLE Hâpy
## Enregistrer le serveur Hâpy sur Zéphir
## Appliquer la configuration en exécutant la commande *@instance@* Instancier
Le déploiement des serveurs de l’établissement doit se faire automatiquement sans autre intervention humaine.
h2. 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
## Créer une variante pour Eolebase afin de définir les paramètres communs de machines virtuelles (RAM, taille de disque, etc)
## Pour chaque établissement
### Créer le serveur Eolebase de la bonne variante et finir sa configuration
### Éditer la configuration du serveur Hâpy et ajouter l’identifiant du serveur Eolebase à la liste des serveurs à déployer automatiquement
### Programmer l’envoie de la configuration du serveur Hâpy
# Sur chaque serveur Hâpy
## S’assurer que la configuration est récuppérer en exécutant la commande *@synchro_zephir@*
## 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.
h1. Comment fonctionne l'automatisation
h2. 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 ?@*)
h2. 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.
h2. 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
h1. 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@*
## récupérer toute la configuration de la VM dans un *@tar.gz@*
### Vérifier la cohérence des informations Hapy/VMs. Si échec, alors on s'arrête en erreur
## créer/mettre à jour un FILE dans hapy pour chaque configuration de VM
## télécharger les images Apps sur l'Hapy
## créer les images nécessaires Os (et Data si besoin)
## Créer/mettre à jour un TEMPLATE (Avec une contextualisation active, +Le fichier de Configuration, +Le script de post installation)
## Démarrer la VM
## Si l'instance n'est pas faite:
*** réponse aux questions de façon automatique
*** gestion des secrets
## Monitorer la fin d'instance avant de passer à la suivante.
h1. 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":https://pcll.ac-dijon.fr/eole/utiliser-hapy-virtualiser-modules-eole/.
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":https://docs.opennebula.io/6.0/management_and_operations/storage_management/marketplaces.html#public-marketplaces à installer "nous même":https://github.com/OpenNebula/appmarket-simple
* 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)
h1. 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
h1. 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é)
h1. 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)
h2. Mise en place d’une infrastructure depuis 0
Le processus global se résume ainsi :
# Sur le serveur Zéphir
## 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)
## Créer une variante pour Amon afin de définir les paramètres communs de machines virtuelles (RAM, taille de disque, etc)
## Créer une variante pour Scribe afin de définir les paramètres communs de machines virtuelles (RAM, taille de disque, etc)
## Pour chaque établissement
### Le créer s’il n’existe pas
### Créer le serveur Amon de la bonne variante et finir sa configuration
### Créer le serveur Scribe de la bonne variante et finir sa configuration
### 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
## Installer physiquement le serveur Hâpy
## Installer le module EOLE Hâpy
## Enregistrer le serveur Hâpy sur Zéphir
## Appliquer la configuration en exécutant la commande *@instance@* Instancier
Le déploiement des serveurs de l’établissement doit se faire automatiquement sans autre intervention humaine.
h2. 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
## Créer une variante pour Eolebase afin de définir les paramètres communs de machines virtuelles (RAM, taille de disque, etc)
## Pour chaque établissement
### Créer le serveur Eolebase de la bonne variante et finir sa configuration
### Éditer la configuration du serveur Hâpy et ajouter l’identifiant du serveur Eolebase à la liste des serveurs à déployer automatiquement
### Programmer l’envoie de la configuration du serveur Hâpy
# Sur chaque serveur Hâpy
## S’assurer que la configuration est récuppérer en exécutant la commande *@synchro_zephir@*
## 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.
h1. Comment fonctionne l'automatisation
h2. 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 ?@*)
h2. 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.
h2. 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
h1. 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@*
## récupérer toute la configuration de la VM dans un *@tar.gz@*
### Vérifier la cohérence des informations Hapy/VMs. Si échec, alors on s'arrête en erreur
## créer/mettre à jour un FILE dans hapy pour chaque configuration de VM
## télécharger les images Apps sur l'Hapy
## créer les images nécessaires Os (et Data si besoin)
## Créer/mettre à jour un TEMPLATE (Avec une contextualisation active, +Le fichier de Configuration, +Le script de post installation)
## Démarrer la VM
## Si l'instance n'est pas faite:
*** réponse aux questions de façon automatique
*** gestion des secrets
## Monitorer la fin d'instance avant de passer à la suivante.