Prototype : Analyse technique

Objectif

L'objectif de ce prototype est de représenter au mieux l'architecture nécessaire à l'entreprise tout en restant dans un environnement simulé. Pour ce faire, ce prototype doit :

• Avoir une réseau simulé et isolé entre les services.
• Contenir tous les services nécessaires, vu qu'on n'a que 3 VPS, il faudra que certains services qui sont en théorie séparés se retrouvent sur un même hôte. Du coup, il faudra faire très attention à que ces services soient bien isolés avec comme seule issue cette couche réseau.
• Ces services doivent fournir correctement les fonctionnalités demandées par le CdC.
• Des postes utilisateurs doivent être simulés, avec autant de simulations que différents postes il y en a.

Application technique

Technologies utilisées

• Docker : Dans le but d'isoler les différents services, et faciliter leurs mise en place sur le vrai matériel. Chaque service aura une image docker associée avec tout ce qu'il faut pour tourner le service en question et qui sera utilisée dans le prototype.
• Docker Swarm : Pour gérer les containers sur les 3 VPS, on utilisera Docker Swarm pour 3 grandes raisons :
  • Pour être les plus génériques possibles, les services ne devraient pas être associés à un VPS spécifique ni, sauf quand c'est vraiment nécessaire, devoir être sur le même VPS qu'un autre service spécifique, Docker Swarm nous permet de mettre ces conditions pour les différents services, mais par défaut il distribuera les services en fonction de la charge actuelle des VPS de façon transparente.
  • Avoir une couche réseau simulée entre les services, isolée d'internet qui connecte tous les services entre eux.
  • Pouvoir ajouter des nouveaux services de façon simple, grâce à la distribution automatique expliquée précédemment mais surtout parce qu'un seul VPS sera en charge de repartir le boulot et donc le seul qui devra être mis à jour.

Schéma prototype

Nous avons décidé de n'utiliser qu'un seul VPS car on aurait besoin d'utiliser Docker Swarm pour utiliser plusieurs VPS.

Malheureusement Docker Swarm n'est pas une solution car il ne permet pas encore d'utiliser l'IPv6, et surtout on ne peut pas assigner des IPs statiques aux containers.

On doit donc faire un choix,

• soit changer les configs pour ne plus utiliser des addresses statiques, et donc ne plus être conforme au schéma réseau.
• soit se limiter à un seul vps qui devra supporter tous les services.

Pour vérifier que le VPS était capable de supporter cette charge, on a lancé une bonne partie des services dessus et vérifié quelles ressources étaient utilisées par containerd:

Avec les services web, dns et mail, et 5 containers qui effectuent les tests le %CPU ne dépasse pas 2% et le %MEM ne dépasse pas 10%. Le VPS devrait docc être capable de supporter avec aise la charge de quelques services supplémentaires.

Configuration en détail

• Pour chacun des services (les postes utilisateurs simulés inclus) il faudra mettre en place un Dockerfile
• Pour mettre en place le swarm il faudra un fichier stack docker-cloud.yml qui définit le comportement du swarm, notamment :
  • Les services à lancer et pour chacun d'eux :
    • Les contraintes de ces services
    • Les ports qui seront exposés
    • L'addresse ip locale du service
    • Les volumes (pour la persistance des données) auxquels ils ont accès
    • Combien de fois lancer ce service (pour du load-balancing et redondance)
  • Une définition du réseau local
  • Une définition des volumes (pour la persistance des données) à créer/utiliser

Documentation des technologies

• docker : http://docs.docker.oeynet.com/engine/reference/builder/
• docker-compose (sous-ensemble de la doc swarm) : http://docs.docker.oeynet.com/compose/compose-file/
• docker swarm : http://docs.docker.oeynet.com/docker-cloud/apps/stack-yaml-reference/
• docker swarm network : https://github.com/docker/labs/blob/master/networking/A3-overlay-networking.md
• docker swarm gestion des ports externes : https://docs.docker.com/engine/swarm/ingress/

Comparaison avec la mise en place sur le réseau réel

Pour garantir la validité de ce prototype, il doit être le plus semblable possible au réseau réel, mais, ceci étant un environnement simulé, il y aura des problèmes dans l'implémentation réelle qu'on ne trouvera pas dans le prototype et auxquels il faudra penser même si le prototype marchera très bien sans :

• Avec le réseau simulé, chaque service se trouvera sur un hôte virtuel différent, mais sur le réseau réel il ne sera pas rare de voir ces services partager un même hôte. Il faudra donc faire attention à ce que les services soient les plus indépendants possibles pour qu'on puisse les mettre dans n'importe quel ordre dans le réseau réel mais surtout faire en sorte qu'ils ne se chevauchent pas sur les ressources partagées, notamment les volumes et les ports exposés.
• Sur le réseau réel, il ne faudra plus le simuler mais plutôt le configurer, donc les parties dédiées à cette simulation devront être enlevées et remplacées par des instructions à suivre sur le vrai matériel (routeur, switch, firewall physique, configuration DMZ...)
• Dans le prototype on a juste un firewall, au niveau du VPS, alors que dans le réseau réel on aura un firewall dans chacun des serveurs et donc faudra couper ce firewall global pour que chaque serveur réel ne laisse ouverts que les ports des services qu'il contient.