Aller au contenu
Langue
DE EN FR
Démarrer un projet

Portainer et VDC au service de l’architecture cloud

Sous chaque plateforme que nous exploitons se trouve la même base : un Virtual Data Center en Suisse, des conteneurs Docker par projet et une exploitation que nous maîtrisons nous-mêmes.

L’article sur le stack de plateforme cloudtec portait sur sa structure en couches. Ici, nous nous penchons sur la plus basse d’entre elles : l’infrastructure sur laquelle tournent toutes les applications.

La base est virtualisée. Les ressources sont regroupées et partagées via un réseau, au lieu d’installer une machine distincte pour chaque projet. Linux, des serveurs web, MariaDB et PHP y tournent, complétés par des services issus d’autres écosystèmes. La recherche plein texte, par exemple, apporte son propre environnement Java. Plutôt que de louer de la capacité chez un hyperscaler, nous exploitons un cloud privé et plaçons les applications dans des conteneurs Docker.

Ce qui se trouve sous les conteneurs

Le matériel ne nous appartient pas : il se trouve chez un fournisseur suisse, dans un centre de données en Suisse. Notre Virtual Data Center (VDC) y tourne, réparti en machines virtuelles que nous configurons et exploitons nous-mêmes. La quantité de mémoire vive, de puissance de calcul et d’espace disque dont dispose une plateforme relève ainsi de la configuration, et non d’un achat de matériel.

Le VDC repose sur OpenNebula, une plateforme open source de cloud computing. Les machines virtuelles y tournent, majoritairement sous Linux, reliées par un LAN virtuel et formant ensemble un Docker Swarm.

En amont se trouve la sécurité réseau : un pare-feu et un pare-feu applicatif web contrôlent chaque requête selon les règles définies, complétés par la segmentation du réseau et des accès VPN pour l’exploitation. Ce qui passe est pris en charge par le reverse proxy, qui relie la requête au conteneur compétent, y compris la terminaison SSL et la répartition de charge lorsqu’une plateforme tourne sur plusieurs instances.

Diagramme en couches de l’architecture cloud : tout en haut, l’accès web ; en dessous, le contrôle d’accès avec pare-feu et proxy HA ; puis, pour chaque plateforme client, des conteneurs d’application et de service dédiés à côté de services partagés comme la recherche, la file de messages, l’antivirus et l’indexation de documents ; tout en bas, la couche Docker et Swarm exploitée par cloudtec, au-dessus du centre de données virtuel à triple redondance.
L’architecture cloud de haut en bas : contrôle d’accès, conteneurs dédiés par plateforme, services partagés et, en dessous, Docker Swarm dans le Virtual Data Center.

Un conteneur par projet

Docker sépare l’application de l’infrastructure. Une application fonctionne ainsi partout de la même manière : sur l’ordinateur portable de la développeuse, en staging et en production. Le système d’exploitation est conteneurisé et abstrait, au lieu d’être reconfiguré pour chaque projet.

Un conteneur regroupe les processus logiciels d’une application : serveur web, base de données et langage de programmation. Il est mis à disposition via une image qui contient tous les éléments exécutables.

Chaque projet client dispose d’au moins un conteneur propre. Les données sont ainsi isolées et segmentées, et les composants logiciels concernés ne voient que leur propre application. Nous mettons également à disposition des services auxiliaires comme l’antivirus ou l’indexation de PDF sous forme de conteneurs ; ils communiquent localement avec les conteneurs des projets via des réseaux virtuels. Ces réseaux déterminent aussi quel service peut en voir un autre.

Docker Swarm répartit les conteneurs entre les hôtes. Si un hôte tombe en panne, le conteneur redémarre automatiquement sur un autre. Le tout est géré avec Portainer : configurer, orchestrer, sécuriser et surveiller les conteneurs de manière centralisée, avec une interface web plutôt qu’exclusivement en ligne de commande.

Pourquoi notre propre cloud plutôt qu’un kit prêt à l’emploi

Les grands fournisseurs livrent des briques toutes faites, mais imposent leurs cycles de release et leurs directives. Avec notre propre architecture, nous décidons de ce qui est mis à jour et quand, et nous pouvons l’adapter lorsqu’un projet l’exige. Grâce à la conteneurisation, un nouveau service profite à tous les projets, et Docker Swarm maintient l’exploitation même lorsqu’un hôte lâche.

Indépendamment de notre configuration, un cloud privé offre en général :

  • un contrôle total des droits d’accès
  • la séparation des ressources et du lieu de stockage
  • un niveau de sécurité élevé, chiffrement compris
  • une bande passante élevée grâce à l’accès exclusif
  • des ressources évolutives en toute flexibilité

Le prix à payer, c’est que nous assumons nous-mêmes la responsabilité de l’exploitation. En contrepartie, c’est la même équipe qui construit et exploite la plateforme : en cas de panne, pas de chaîne de tickets entre trois fournisseurs.

Rédigé par Christian Knellwolf CEO

Tech 3 minutes de lecture