Il s’agit d’une réflexion d’impact des techniques de DevOps sur la distribution EOLE.

Les objectifs de l’atelier étaient :

  • de tester l’utilisation d’un outil de Devops (docker) pour spécialiser une application ;
  • voir comment industrialiser la mise en œuvre de cette spécialisation.

Les travaux réalisés consistaient à transformer un module  Eolebase afin de gérer plusieurs technologies de virtualisation.

Technologies utilisées

  • Docker : Cette technologie permet d’embarquer une application dans un conteneur virtuel qui peut s’exécuter sur n’importe quel serveur. Elle a pour but de faciliter les déploiements d’application et la gestion du dimensionnement de l’infrastructure sous-jacente. Un conteneur est bootable en quelques secondes. Il existe un dépôt https://hub.docker.com/  sur lequel nous pouvons trouver plus de 460 000 images de conteneurs qui contiennent différents produits : Ubuntu, WordPress, MySQL, NodeJS… Cet espace est également intégré à GitHub ;
  • LXC : Un conteneur fait directement appel au système d’exploitation de la machine hôte pour réaliser des appels système et exécuter des applications. Le conteneur n’embarque pas de système d’exploitation, à la différence d’une machine virtuelle. Il est par conséquent beaucoup plus léger que cette dernière. Il n’a pas besoin d’activer un second système pour exécuter des applications. Cela se traduit par un lancement beaucoup plus rapide, mais aussi par la capacité à migrer un conteneur d’une machine physique à une autre. Un conteneur ne représente que quelques Mo ;
  • Qemu/KVM : Il s’agit de la technologie de virtualisation implémentée directement dans le noyau Linux. Elle permet, via un hyperviseur, de simuler une ou plusieurs machines virtuelles (VM) sur une machine physique. Ces VM intègrent elles-mêmes un système d’exploitation sur lequel les applications sont exécutées. Une machine virtuelle pourra avoir une taille de plusieurs Gigaoctets.

Réalisations

Création d’un projet Docker

Pour tester l’utilisation de Docker, le projet poc-roland a été créé sur GitHub : https://github.com/GggEole/poc-roland.

L’idée est de créer une image Docker en spécialisant l’outil Tomcat avec notre application « roro.war ».

   FROM tomcat:8.5.6-jre8
   COPY roro.war $CATALINA_HOME/webapps/
   CMD ["catalina.sh", "run"]

ou, par exemple :

   FROM eolebase:2.6.0
   COPY config.eol /etc/eole/config.eol
   CMD ["reconfigure", ""]

Eolisation de conteneurs

En étudiant ces différentes technologies, nous avons identifié plusieurs points :

  • il faut un accès au service (un nom) ;
  • la gestion de la persistance des données implique le partage de répertoires entre le module et le conteneur. Toutes les technologies le permettent ;
  • les conteneurs publient leurs services grâce à des ports IP. Nous devons réaliser le lien entre le frontal web et ces services.

Il s’agit de créer les dictionnaires et les templates EOLE pour gérer plusieurs conteneurs, et de proposer un moyen d’accès à chacun des ces conteneurs.

  • création des dicos ;
  • création des templates ;
  • mise au point du script d’instanciation ;
  • configuration de Nginx ;
  • création des dicos.

Plusieurs dictionnaires ont été créés : 1 dictionnaire global et autant de dictionnaires que de conteneurs souhaités.

  • dico global : « 10_conteneur »
    • fichier de variable : /etc/eole/conteneur-vars.conf
    • variable ‘nombre_conteneur’ : nombre de conteneurs à activer
  • dico conteneur : « 25_conteneurX »
    • variable ‘conteneur1_name’ : nom du conteneur, mais aussi le nom de la web apps présentée sur le module
      • ex: si ‘rocketchat’, alors l’accès se fera par http://<module>/rocketchat ou par https://<module>/rocketchat
    • variable ‘conteneur1_type’           : type de technologie
      • il s’agit d’une liste des différentes technologies pouvant être utilisées
      • ex: docker, docker+git, snap, snapcraft, vagrant, lxc
    • variable ‘conteneur1_url’            : URL du conteneur
      • c’est le nom publié de l’image
    • variable ‘conteneur1_tag’            : tag de version du conteneur
      • c’est l’identifiant de version de l’image.
      • Dans le cas d’un dépôt Git, il s’agit du tag du source
    • variable ‘conteneur1_repository’     : URL du repository
      • Il s’agit de l’URL du dépot ou l’on trouve l’image ‘conteneur1_url’
    • variable ‘conteneur1_mountpoint_in’  : volumes partagés dans le conteneur
    • variable ‘conteneur1_mountpoint_out’ : volumes partagés par le module
    • variable ‘conteneur1_port_in’        : ports IP exposés dans le conteneur
    • variable ‘conteneur1_port_out’       : ports IP exposés par le module

Lors de l’instance, il faut :

  • arrêter le conteneur s’il était déjà en cours ;
  • télécharger l’image (docker, vagrant, lxc, …) sur le dépôt du fournisseur. L’opération ne se fait qu’une fois tant que nous ne modifions pas l’image ;
  • démarrer le conteneur en lui affectant le nom du conteneur ;
  • configurer la redirection Nginx du nom de conteneur vers un port exposé par le conteneur.

Voici une image écran de la description d’un conteneur (docker / rocketchat ):

snapshot_genconfig

Bilan

  • il est facile de mettre en place un nouveau service grâce à ces techniques ;
  • l’indépendance entre les services et le système d’exploitation est plus importante ;
  • nous pouvons changer de technologie (ex: docker vers snap ) en changeant seulement une variable ;
  • la gestion des versions est entièrement renvoyée à la phase de développement. La modification d’une librairie, ou d’un service, ne risque pas de changer le fonctionnement du conteneur ;
  • dans notre cas, nous nous sommes limités à des services de type Web.