Automatisation » Historique » Version 33
Version 32 (Daniel Dehennin, 29/04/2021 10:40) → Version 33/43 (Daniel Dehennin, 29/04/2021 10:53)
{{>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
* Les IP des différents modules EOLE seront obligatoirement Statiques.
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
## [[Automatisation#Procédure-postservice-hapy|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.
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@*
## [[Automatisation#Procédure-postservice-hapy|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@*)
* Créer le paquet *@eole-modele-vm@*
* Créer le dicos avec une famille *@machine_virtuelle@* contenant les variables de caractéristique de machine virtuelle
** variable *@activer_modele_vm@* à *@non@* par défaut
** *@vm_marketplace@* : nom du MarketPlace OpenNebula où récupérer l’image disque, par défaut *@EOLE@*
** *@vm_app@* : nom de l’application au sens OpenNebula MarketPlace
** *@vm_memory@* : taille de la mémoire en Go
** *@vm_vcpu@* : nombre de CPU virtuels
** Disques :
*** *@vm_disk_size@* : taille en Go du disque
** Interfaces, en fonction de la valeur *@nombre_interfaces@*
*** *@vm_net_name0@* nom du réseau hâpy associé à l’interface 0
*** *@vm_net_name1@* nom du réseau hâpy associé à l’interface 1
*** *@vm_net_nameX@* nom du réseau hâpy associé à l’interface X
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@* 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)
<pre>
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
</pre>
** Exporter l’Apps avec son identifiant, cela créé un *@ID@* de template et un *@ID@* d’image disque
<pre>
root@hapy:~# onemarketapp export 515 "My Debian 10" --datastore 101
IMAGE
ID: 4
VMTEMPLATE
ID: 2
</pre>
** Modifier le template créé avec les caractéristiques récuppérées depuis Zéphir
<pre><code class="xml">
<!-- 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>
</code></pre>
h2. Configuration du serveurs Hâpy
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 de déploiment des VMs sur Hâpy postservice hapy
La préparation du Hâpy création des interfaces aura été faite lors de son instance/reconfigure : l’instance/reconfigure de l'Hapy.
* création des réseaux et assignation des interfaces Idem pour les datastores....
* création des datastores
* création des marketPlaces Idem pour la déclaration du marketplace EOLE/Hapy
Voir postservice : #32120
Voir diagnose : #32123
La procédure de déploiment des machines virtuelles sur Hâpy est faites par un script (par exemple *@eole-hapy-autodeploy-vms@*).
Ce script doit :
# Vérifier si le déploiement automatique est activé (*@activer_deploiement_automatique@* == *@oui@*) Si *@activer_deploiement_automatique@* = *@non@*, stop
# récupérer la [[Automatisation#Configuration-du-serveurs-Hâpy|liste des serveurs à déployer]] Pour chaque *@IdZéphir@*
## Récuppérer récupérer toute la configuration des serveur 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
# Pour chaque serveur
## Créer/mettre créer/mettre à jour un *@FILE@* FILE dans hapy pour exposer la chaque configuration à l’interieur de la VM
## télécharger les images Apps sur l'Hapy
## Télécharger l’application depuis le marketPlace (cela créé une image et un template de base) créer les images nécessaires Os
## Créer Créer/mettre à jour un modèle de VM à partir de l’apps téléchargé en mode persistant avec TEMPLATE (Avec une contextualisation active, le +Le fichier de configuration et le Configuration, +Le script de post installation 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
*** l’utilisation de "oneGate":https://docs.opennebula.io/6.0/management_and_operations/multivm_service_management/onegate_usage.html nécessite que la VM ait accès au frontend Hâpy
*** autre méthode ? suivante.
DaD:
* Il n’est pas sûr de pouvoir interroger le serveurs Zéphir de façon automatique depuis Hâpy.
** Sur Amon, la mise en place du tunnel IPSec requiert la saisie d’identifiant afin de faire une connexion XMLRPC (eole-vpn:source:scripts/active_rvp@7232d10f#L169)
** Serait-il envisageable d’ajouter une procédure automatique sur le Zéphir lors de la préparation de la configuration pour Hâpy ?
### Sélectionner le serveur Hâpy
### Cliquez sur *@Actions sur le serveur@*
### Cliquer sur *@Envoyer la configuration au serveur@*
### Une procédure automatique prépare la configuration avec des *@.tar.gz@* pour tous les serveurs concernés par le déploiement sur Hâpy
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
* Les IP des différents modules EOLE seront obligatoirement Statiques.
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
## [[Automatisation#Procédure-postservice-hapy|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.
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@*
## [[Automatisation#Procédure-postservice-hapy|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@*)
* Créer le paquet *@eole-modele-vm@*
* Créer le dicos avec une famille *@machine_virtuelle@* contenant les variables de caractéristique de machine virtuelle
** variable *@activer_modele_vm@* à *@non@* par défaut
** *@vm_marketplace@* : nom du MarketPlace OpenNebula où récupérer l’image disque, par défaut *@EOLE@*
** *@vm_app@* : nom de l’application au sens OpenNebula MarketPlace
** *@vm_memory@* : taille de la mémoire en Go
** *@vm_vcpu@* : nombre de CPU virtuels
** Disques :
*** *@vm_disk_size@* : taille en Go du disque
** Interfaces, en fonction de la valeur *@nombre_interfaces@*
*** *@vm_net_name0@* nom du réseau hâpy associé à l’interface 0
*** *@vm_net_name1@* nom du réseau hâpy associé à l’interface 1
*** *@vm_net_nameX@* nom du réseau hâpy associé à l’interface X
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@* 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)
<pre>
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
</pre>
** Exporter l’Apps avec son identifiant, cela créé un *@ID@* de template et un *@ID@* d’image disque
<pre>
root@hapy:~# onemarketapp export 515 "My Debian 10" --datastore 101
IMAGE
ID: 4
VMTEMPLATE
ID: 2
</pre>
** Modifier le template créé avec les caractéristiques récuppérées depuis Zéphir
<pre><code class="xml">
<!-- 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>
</code></pre>
h2. Configuration du serveurs Hâpy
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 de déploiment des VMs sur Hâpy postservice hapy
La préparation du Hâpy création des interfaces aura été faite lors de son instance/reconfigure : l’instance/reconfigure de l'Hapy.
* création des réseaux et assignation des interfaces Idem pour les datastores....
* création des datastores
* création des marketPlaces Idem pour la déclaration du marketplace EOLE/Hapy
Voir postservice : #32120
Voir diagnose : #32123
La procédure de déploiment des machines virtuelles sur Hâpy est faites par un script (par exemple *@eole-hapy-autodeploy-vms@*).
Ce script doit :
# Vérifier si le déploiement automatique est activé (*@activer_deploiement_automatique@* == *@oui@*) Si *@activer_deploiement_automatique@* = *@non@*, stop
# récupérer la [[Automatisation#Configuration-du-serveurs-Hâpy|liste des serveurs à déployer]] Pour chaque *@IdZéphir@*
## Récuppérer récupérer toute la configuration des serveur 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
# Pour chaque serveur
## Créer/mettre créer/mettre à jour un *@FILE@* FILE dans hapy pour exposer la chaque configuration à l’interieur de la VM
## télécharger les images Apps sur l'Hapy
## Télécharger l’application depuis le marketPlace (cela créé une image et un template de base) créer les images nécessaires Os
## Créer Créer/mettre à jour un modèle de VM à partir de l’apps téléchargé en mode persistant avec TEMPLATE (Avec une contextualisation active, le +Le fichier de configuration et le Configuration, +Le script de post installation 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
*** l’utilisation de "oneGate":https://docs.opennebula.io/6.0/management_and_operations/multivm_service_management/onegate_usage.html nécessite que la VM ait accès au frontend Hâpy
*** autre méthode ? suivante.
DaD:
* Il n’est pas sûr de pouvoir interroger le serveurs Zéphir de façon automatique depuis Hâpy.
** Sur Amon, la mise en place du tunnel IPSec requiert la saisie d’identifiant afin de faire une connexion XMLRPC (eole-vpn:source:scripts/active_rvp@7232d10f#L169)
** Serait-il envisageable d’ajouter une procédure automatique sur le Zéphir lors de la préparation de la configuration pour Hâpy ?
### Sélectionner le serveur Hâpy
### Cliquez sur *@Actions sur le serveur@*
### Cliquer sur *@Envoyer la configuration au serveur@*
### Une procédure automatique prépare la configuration avec des *@.tar.gz@* pour tous les serveurs concernés par le déploiement sur Hâpy