Automatisation » Historique » Version 39
Version 38 (Daniel Dehennin, 29/04/2021 11:35) → Version 39/43 (Daniel Dehennin, 29/04/2021 11:40)
{{>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 devrait se faire automatiquement sans autre intervention humaine mais il faut gérer les inscriptions Zéphir.
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 serveur Hâpy
Voir #32118
* Ajouter une variable *@activer_deploiement_automatique@* par défaut à *@non@*.
* Ajouter une variable définissant la liste des serveurs à déployer :
** Soit en récupérant la liste des serveurs Zéphirs du même établissement qui ont *@activer_modele_vm@* == *@oui@*
** Soit avec une liste statique ordonnée d’identifiants Zéphir de serveurs à déployer
Remarque: 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
La préparation du Hâpy aura été faite lors de son instance/reconfigure :
* création des réseaux et assignation des interfaces
* création des datastores
* création des marketPlaces
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@*)
# récupérer la [[Automatisation#Configuration-du-serveurs-Hâpy|liste des serveurs à déployer]]
## Récuppérer la configuration des serveur
## Vérifier la cohérence des informations Hapy/VMs. Si échec, alors on s'arrête en erreur
### Vérifier que les noms de réseaux déclarés pour les VMs existent sur Hâpy
# Pour chaque serveur
## Créer/mettre à jour un *@FILE@* dans hapy pour exposer la configuration à l’interieur de la VM
## Télécharger l’application depuis le marketPlace (cela créé une image et un template de base)
## Créer un modèle de VM à partir de l’apps téléchargé en mode persistant avec contextualisation active, le fichier de configuration et 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
*** par l’utilisation de SSH pour l’instance de la VM ?
*** 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 ?
Le script sera appelé en *@postservice@* durant *@instance@* *uniquement*
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 devrait se faire automatiquement sans autre intervention humaine mais il faut gérer les inscriptions Zéphir.
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 serveur Hâpy
Voir #32118
* Ajouter une variable *@activer_deploiement_automatique@* par défaut à *@non@*.
* Ajouter une variable définissant la liste des serveurs à déployer :
** Soit en récupérant la liste des serveurs Zéphirs du même établissement qui ont *@activer_modele_vm@* == *@oui@*
** Soit avec une liste statique ordonnée d’identifiants Zéphir de serveurs à déployer
Remarque: 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
La préparation du Hâpy aura été faite lors de son instance/reconfigure :
* création des réseaux et assignation des interfaces
* création des datastores
* création des marketPlaces
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@*)
# récupérer la [[Automatisation#Configuration-du-serveurs-Hâpy|liste des serveurs à déployer]]
## Récuppérer la configuration des serveur
## Vérifier la cohérence des informations Hapy/VMs. Si échec, alors on s'arrête en erreur
### Vérifier que les noms de réseaux déclarés pour les VMs existent sur Hâpy
# Pour chaque serveur
## Créer/mettre à jour un *@FILE@* dans hapy pour exposer la configuration à l’interieur de la VM
## Télécharger l’application depuis le marketPlace (cela créé une image et un template de base)
## Créer un modèle de VM à partir de l’apps téléchargé en mode persistant avec contextualisation active, le fichier de configuration et 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
*** par l’utilisation de SSH pour l’instance de la VM ?
*** 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 ?
Le script sera appelé en *@postservice@* durant *@instance@* *uniquement*
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