Merci pour ton commentaire, au milieu de toute cette bile un peu de positif fait plaisir.
On est parti du principe que les services qu'on héberge sont de grosses usines à gaz, lourdes et complexes. La meilleure chose à faire c'est d'y toucher le moins possible (faire les mises à jour, la maintenance, etc), du coup il nous fallait isoler correctement l'ensemble de notre infrastructure.
On a donc retenu la virtualisation « à l'ancienne », avec un hyperviseur et des machines virtuelles propres à chaque service. Globalement on a une sorte de workflow comme ça :
On monte la VM sous le système d'exploitation choisi, on la configure de manière standard (réseau, installation de screen et openssh-server).
On déploie le logiciel (exemple : Gitlab) en utilisant de préférence les dépôts officiels puis on le configure.
On fait pointer notre DNS sur l'adresse IP de la machine puis on déploie des certificats (Let's Encrypt) avec le script acme.sh.
On ajoute éventuellement les règles de pare-feu spécifiques à la machine si il y a (exemple : Git pour Gitlab).
On adapte la configuration du système de sauvegardes à la nouvelle machine et on vérifie que ça fonctionne bien en lançant une procédure de sauvegarde manuellement.
On test l'ensemble des fonctionnalités prévues par le logiciel installé en interne puis on ouvre le service au public.
Une fois que tout ça est fait on considère qu'il reste juste les mises à jours à réaliser (suivant le cycle de publication des logiciels utilisés), en dehors de ça on y touche plus.
Si il y arrive un problème (bug logiciel suite à une mise à jour, etc) on stoppe la machine, on déploie la dernière sauvegarde en date et on rouvre directement le service. Ensuite on clone la VM et on debug sur la nouvelle image, c'est super confortable pour les administrateur-ice-s et les utilisateur-ice-s.
Le principe du conteneur est vraiment différent, personnellement je le vois comme idéal dans des cas d'application précis. Par exemple tu montes un projet spécifique d'hébergement de haute-disponibilité en NodeJs, avec des logiciels périphériques comme PostgreSQL, HAproxy et InnoDB. Dans ce cas le système de conteneur te permettra de gérer l'ensemble de ton système de manière très pointue et précise (au cas par cas) tout en gardant un ensemble lié et cohérent.
Cette manière de faire ne colle pas avec ce que nous faisons car par exemple déployer Gitlab (en Ruby) à côté d'ownCloud (en PHP) et Pelican (en Python) n'a pas de sens. Ceci car chacun est optimisé pour certains logiciels tiers, ownCloud recommande l'utilisation de MySQ et Apache, Gitlab c'est Postgres et Nginx... Installer tout ça sous la forme de conteneur (de petites briques par dessus le système hôte donc) rends juste la stabilité de l'ensemble plus précaire et complexifie largement les tâches d'administration à notre niveau.
Si tu as une demi-heure devant toi je te recommande de visionner la conférence d'un ami qu'il a donné au dernier Passage en Seine : Wilfried Ollivier, Cloisonner pour mieux partager. En plus d'être quelqu'un de brillant il explique bien mieux que moi les différences de fond entre les conteneurs et les machines virtuelles.
Pour ce qui concerne la partie associative du projet je ne pense pas que ce soit forcément un problème d'outil. On utilisait l'IRC, Telegram, le forum et le wiki conjointement, c'est plus une question d'investissement personnel (temps à donner, disponibilité).
[^] # Re: Choix des VM par rapport à Docker ?
Posté par Fkdikdbejdid . En réponse à la dépêche Unixcorn, trois mois plus tard : évolutions, remises en questions et stabilisation. Évalué à -2.
Salut !
Merci pour ton commentaire, au milieu de toute cette bile un peu de positif fait plaisir.
On est parti du principe que les services qu'on héberge sont de grosses usines à gaz, lourdes et complexes. La meilleure chose à faire c'est d'y toucher le moins possible (faire les mises à jour, la maintenance, etc), du coup il nous fallait isoler correctement l'ensemble de notre infrastructure.
On a donc retenu la virtualisation « à l'ancienne », avec un hyperviseur et des machines virtuelles propres à chaque service. Globalement on a une sorte de workflow comme ça :
Une fois que tout ça est fait on considère qu'il reste juste les mises à jours à réaliser (suivant le cycle de publication des logiciels utilisés), en dehors de ça on y touche plus.
Si il y arrive un problème (bug logiciel suite à une mise à jour, etc) on stoppe la machine, on déploie la dernière sauvegarde en date et on rouvre directement le service. Ensuite on clone la VM et on debug sur la nouvelle image, c'est super confortable pour les administrateur-ice-s et les utilisateur-ice-s.
Le principe du conteneur est vraiment différent, personnellement je le vois comme idéal dans des cas d'application précis. Par exemple tu montes un projet spécifique d'hébergement de haute-disponibilité en NodeJs, avec des logiciels périphériques comme PostgreSQL, HAproxy et InnoDB. Dans ce cas le système de conteneur te permettra de gérer l'ensemble de ton système de manière très pointue et précise (au cas par cas) tout en gardant un ensemble lié et cohérent.
Cette manière de faire ne colle pas avec ce que nous faisons car par exemple déployer Gitlab (en Ruby) à côté d'ownCloud (en PHP) et Pelican (en Python) n'a pas de sens. Ceci car chacun est optimisé pour certains logiciels tiers, ownCloud recommande l'utilisation de MySQ et Apache, Gitlab c'est Postgres et Nginx... Installer tout ça sous la forme de conteneur (de petites briques par dessus le système hôte donc) rends juste la stabilité de l'ensemble plus précaire et complexifie largement les tâches d'administration à notre niveau.
Si tu as une demi-heure devant toi je te recommande de visionner la conférence d'un ami qu'il a donné au dernier Passage en Seine : Wilfried Ollivier, Cloisonner pour mieux partager. En plus d'être quelqu'un de brillant il explique bien mieux que moi les différences de fond entre les conteneurs et les machines virtuelles.
Pour ce qui concerne la partie associative du projet je ne pense pas que ce soit forcément un problème d'outil. On utilisait l'IRC, Telegram, le forum et le wiki conjointement, c'est plus une question d'investissement personnel (temps à donner, disponibilité).
Encore merci à toi et à la prochaine !