Distribution EOLE » Modules » EOLE OpenNebula

{{>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@*)

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)

<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. 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.