Choix du système pour s'auto-héberger
Suite à un échange intéressant sur le choix d’une distribution dans Diaspora, j'ai eu envie de developper le sujet dans un article. je restreins au choix d'un système d'exploitation pour de l'auto-hébergement (à la maison ou chez un hébergeur avec une offre de serveur physique dédié) car je ne me sens plus assez qualifié pour parler de choix d'entreprise, m'étant recentré sur le développement ; bon je glisserai quand même quelques avis et les adminsys en activité commenteront.
En une quinzaine d’années, le choix d’un système a traversé trois phases successives : de "le meilleur système c'est Gloup" (remplacez Gloup par votre système d'exploitation préféré), à "le meilleur système c'est TOUS", nous sommes arrivés à "le meilleur système c'est AUCUN".
Phase 1 : le monolithe
Le serveur est monolithique donc le choix du système d'exploitation est crucial.
En entreprise, il dépend de la politique interne, des goûts et compétences des administrateurs système. Généralement on limite la fragmentation des systèmes déployés. On choisira par exemple RedHat pour les serveurs critiques et CentOS pour les autres afin d'avoir une homogénéité. Des besoins particuliers (comme le pare-feu) pourront amener à installer des systèmes spécifiques (comme PFSense).
Dans le cas de l'auto-hébergement, c'est open bar et nul besoin de se justifier. On choisit Gloup parce que c'est cool et qu'on veut appendre à le maîtriser, ou bien parce qu'on pense que c'est le meilleur choix technique (ou philosophique).
Ce qu'il faut savoir c'est que ce système fournit de base une logithèque plus ou moins étendue par son gestionnaire de paquets. S'il manque des choses, on peut ajouter d'autres sources, comme des dépôts tiers de contributeurs. En dernier ressort, on peut compiler à partir des sources, ce qui peut être un vrai travail de portage si le programme en question n'est pas prévu pour ce système. On est très dépendant des versions proposées par le système d'exploitation et si on a besoin de faire coexister plusieurs versions d'un même programme, ça commence à se compliquer grandement. Quand on montera en version le système d'exploitation, tous ces ajouts non standard (paquets non officiels, programmes compilés à partir des sources) compliqueront la mise à jour du système d'exploitation.
Phase 2 : pas de limite
Et puis est apparue la virtualisation ! le choix du système d'exploitation n'est plus une limitation, on mixe à son gré et le système hôte (appelé hyperviseur) a le rôle principal d'exécuter avec célérité les machines virtuelles. On a encore une petite adhérence à l'architecture matérielle : si on tourne sur une architecture x86, on doit installer des systèmes supportant cette architecture. La virtualisation a un coût même si elle s'appuie sur des instructions dédiées du processeur pour être très performante.
Sur du matériel modeste, ce qui est souvent le cas en auto-hébergement, on privilégiera les technologies de conteneurs (LXC pour Linux, Jails pour FreeBSD) pour isoler ses services et faire cohabiter des versions spécifiques ou différentes. Les conteneurs sont plus limités que les machines virtuelles car ils partagent le kernel du système hôte. Sur un serveur Linux, des containers LXC pourront exécuter différentes distributions GNU/linux, mais seulement du Linux. Cela permet déjà de faire plein de trucs cool, chaque conteneur a son IP, on choisit le système le plus adapté à ce qui sera installé dessus (Debian CentOS, Alpine, ...).
Si on a confiance dans ce qui s'exécute sur ses conteneurs (ce qui devrait être le cas en auto-hébergement perso), l'approche de la sécurité du serveur est simple : un gros pare-feu au niveau du serveur physique pour n'ouvrir que les ports publiques sur Internet et les conteneurs peuvent communiquer entre eux par des adresses privées.
Phase 3 : centré sur l'application
Puis Docker a lancé sa technologie de conteneur d'application, basé techniquement sur les conteneurs Linux LXC mais avec l'enjeu de faire oublier le système sous-jacent :
- un conteneur Docker = une application (le processus en PID 1)
- un portail d'applications permet de télécharger des images prêtes à l'emploi
- les dépendances entre conteneurs sont déclarées explicitement
Le tout s'accompagne d'un ensemble de bonnes pratiques : pas de données dans les conteneurs d'applications, une configuration passée au conteneur lors de son initialisation. Bref je vais pas détailler, plein de bons articles sur le sujet ont déjà été publiés. Mais c'est une technologie qui vaut la peine de jouer d'être essayée. Elle ne révolutionne pas la technique sous-jacente qui existait déjà mais les usages et la façon de repenser un déploiement de services, réparti entre plusieurs conteneurs faciles à mettre à jour, une abstraction totale par rapport au système hôte.
Ne nous voilons pas la face, Docker c'est la fin de la distribution serveur. Est-ce que Debian est mieux que CentOS sur un serveur ? On s'en cogne car peu importe la logithèque la distribution et les versions fournies de chaque librairie. En installant Docker dessus, on en fait un chef d'orchestre dont le rôle se limite à exécuter des dizaines ou des centaines de conteneurs. Et le catalogue d'applications est énorme, comme les versions proposées. Et si on ne trouve pas vie ou qu'on a besoin d'empaqueter ses propres applications en conteneurs Docker, on apprend à fabriquer ses propres conteneurs en quelques heures d'auto-formation.
Bon j'ai l'air emballé sur Docker et c'est le cas, d'un point de vue professionnel. Ce n'est pas mon rêve pour mon auto-hébergement, les conteneurs ont tous la même taille, ça manque de diversité et de fun pour moi.
La plupart des entreprises sont entre la phase 2 et la phase 3 : elle ont virtualisé tout ce qui est possible et elles migrent des services sous Docker.
Mais que choisir, au final, pour de l'auto-hébergement ? Et bien, je dirais : "faîtes vous d'abord plaisir". BSD, Linux, il y a de quoi faire. Quitter le monolithique et passer à l'étape 2 ou 3 ouvre d'autres perspectives dans la gestion de son serveur. Fan du pare- feu PF ? ajoutez une machine virtuelle avec PFSense pour gérer la sécurité de votre serveur. Si professionnellement vous risquez d'être concernés par Docker, formez-vous parce que c'est intéressant et que ça peut être utile (mais ne baclez pas l'aspect sécurité des containers). Moi j'ai une passion pour les conteneurs maison qui me permettent de moduler à ma guise : des petits conteneurs avec l'esprit Docker pour les micro- services (avec Alpine Linux), des gros conteneurs pour les applications plus conséquentes (comme Nextcloud). Longue vie à l'auto- hébergement, profitons-en tant que l'Internet n'est pas à péage :-)
Je me suis mis à utiliser lxc sous debian et c'est vraiment sympa. Avant ça, les services que j'hébergeais étaient dans des machines virtuelles sous virtualbox qui marchait très bien. Seulement quelques petits ralentissements par rapport à un serveur "bare-metal" mais ça allait. Par contre le poids de ces VMs quand il fallait les sauvegarder.... C'était de plus en plus long. Avec les conteneurs lxc: -ça démarre super vite, puisque plus de système complet à lancer -la sauvegarde, avec un petit tar.gz et le tour est joué ! -la rapidité de la machine physique puisque très peu de virtualisation (voire pas du tout) -la migration d'une machine à l'autre, ce fait super bien (simplement attention aux droits des conteneurs !) Je n'ai pas encore joué avec Docker, ça se resemble un peu, mais comme tu le dit c'est plus orienté applications avec abstraction de ce qu'il y a en dessous.
Merci en tout cas pour ton article qui résume très bien la situation de l'hébergement de manière générale, que ce soit pro ou perso ! ;-)
@Sytoka il faut que je regarde OpenStack c'est sur ma todo. C'est peut-être surdimensionné pour de l'auto-hébergement, mais au moins pour ma culture personnelle.
@Jonathan oui LXC ouvre plein de possibilités sympas.
Et sinon, un petit cluster Keburnetes ou Swarm de 3/4 rpi3 ça peut êtes très sympa pour l'auto-hébergement.
Tu as aussi des applications comme OpenStack (via kolla par exemple) qui te déploient non pas un gros conteneurs mais une multitude de petits conteneurs, un par service ;-)