Comment je suis passé d'un serveur dédié monolithique à une archi. basée sur la virtu, découpée, isolée, automatisée, monitorée, ...
TLDR : Je suis reparti from scratch en utilisant toute l'expèrience acquise pendant la maintenance de mon serveur précédent et j'ai utiliser des outils modernes de virtualisation, de containerisation, de configuration et d'orchestration (ça fait beaucoup de "ion") afin d'avoir une infrastructure solide et souple.
En 2006, j'ai commandé mon premier serveur dédié chez Dedibox. A l'époque, je débutais en administration système et les seuls serveurs que j'avais utilisés jusque là étaient des petits mutualisés. Bien sur, j'avais travaillésur des serveurs dédiés maintenus par les administrateurs au boulot mais je n'avais jamais fait tout cela seul, sur mes propres serveurs.
Déjà à cette époque, je me disais qu'être développeur web impliquait obligatoirement de connaître les problèmatiques système sous-jacentes. Je pense qu'il est impossible de produire une application correcte sans être un minimum au courant des problèmatiques de déploiement, de disponibilité, de charges, ...
J'ai donc sauté le pas et commander ma première Dedibox... le début de la galère !
A l'époque, je travaillais exclusivement sur Windows, équipé de mon Notepad++ et de cmd.exe. J'étais hallergique aux lignes de commandes et d'ailleurs je n'y comprenais rien. Mais je savais que c'était un outil que je devais maîtriser afin d'être plus performant.
De même, en bon utilisateurs de Windows, je n'aimais pas du tout les sytème Unix qui, d'après mon expèrience du moment, nécessitaient bien trop de manipulation pour faire des choses simples, des choses qu'on pouvait faire avec quelques clics sur Windows...
Je me trompais, bien sur, mais je ne le savais pas encore.
Avant d'en arrivé à une belle Debian 7, je suis passé par pas mal de distributions, essentiellement des Ubuntu server. Là encore, avec l'expèrience, je pense que je me suis trompé mais passons.
J'ai donc installé ma première distribution Linux sur ce serveur en 2006. J'avais très peu d'expèrience et je l'ai donc cassée plusieurs fois. Je l'ai donc réinstallée plusieurs fois et ai commencé par y héberger de simple sites web ou applications PHP basiques que je développais sur mon temps libre.
Je ne me souciais pas de savoir si installer tel ou tel paqet était bon ou pas, si passer par une compilation personnalisée aurait été mieux ou pas. J'installais bêtement les paquets en essayant de suivre les tutos et en me rendant compte que ça ne fonctionnait pas comme je le voulais ou que ça ne fonctionnait pas du tout.
Bref tout ça pour dire que mon système était totalement pourri par mes manipulations.
Pour corser un peu le tout, j'ai subi plusieurs migration : changement de datacenter, changement de machine, ... J'ai donc du apprendre à faire des backups propres et à les appliquer sur les nouveaux serveurs.
Pour finir, bien que petit à petit je me sois familiariser avec quelques commandes très utiles, je n'avais aucune idée des possibilités offertes par les shells modernes et donc aucune idée de comment je pouvais automatiser toutes ces tâches un peu barbentes.
Voilà en gros pour le flashback : je travaillais en 2006-2010 comme les vrais admininistrateurs travaillaient en 1990 (et encore...). Je cassais souvent mon serveur, je perdais donc beaucoup de temps à le remettre sur pieds et accessoirement, je perdais des données.
Finalement, après quelques années, je me suis rendu compte de tous les problèmes que j'avais avec mon serveur. En parallèle de tout ça, je suis passez par quelques jobs qui m'ont permis de gagner beaucoup d'expèrience en administration et surtout qui m'ont fait aimer ça.
De plus en plus, je me disais que, en tant que développeur, connaitre les problèmes d'administration était une bonne chose.
j'ai donc continué à explorer cette voie mais je ne me suis pas lancé immédiatement dans la refonte de mon serveur : j'ai attendu encore et encore.
Pendant ce temps, j'ai découvert plein de nouvelles choses, de nouvelles méthodes de travail et aujourd'hui, beaucoup de personne me dise que j'ai un profil très DevOps. Je me suis orienté sur l'outillage commun pour les développeur et les administrateurs.
Aujourd'hui je ne démarre plus un projet sans avoir au préalable construit un environnement de développement reproductible (j'utilise exclusivement Vagrant pour ça). S'il faut que je tape plus de trois lignes de commandes pour démarrer ce même projet, je m'arrête et j'optimise tout cela. Le but : masquer toutes la complexité pour que chaque intervenant (vous l'aurez compris, je parle des développeurs et des administarateurs) puisse démarrer le projet en local, sur un serveur ou ailleurs sans se soucier trop des détails et problèmes.
J'ai donc appliqué cette même logique dans la reflexion qui m'a menée à migrer tout mon serveur. Ce que je voulais c'était avant tout avoir une infrastructure solide et surtout en grande partie automatisée. Je voulais pouvoir préparer l'hébergement d'un projet en moins d'une heure, monitorer tout cela facilement, faire des backups et les restaurer en un clin d'oeil, ... Et surtout, je voulais avoir un environement propre, dans lequel je pouvais faire mes tests sans impacter des applications en prod, jeter ce test, en démarrer un nouveau, ... La virtualisation était donc ce qu'il me fallait !
D'après les problèmes que j'avais rencontré auparavant, la solution qui me convient le plus est donc basée sur de la virtualisation. La raison est très simple. En fait il y en a plusieurs :
- des environnements isolés les uns des autres
- des environnements jetables
- des environnements reproductibles
- une gestion des droits simplifiée
Après avoir regarder ce qui se fsaisait et écouter les conseils de "ceux qui savent" (les administrateurs de mon réseau), je me suis tourné vers ProxMox. C'est un hyperviseur comme d'autres que vous pouvez connaître (Virtualbox par exemple) qui permet de gérer aussi bien des machines virtuelles que de containers.
Le plus dans tout cela, c'est qu'Online.net, chez qui je commande tous mes serveurs, propose en standard ProxMox comme distribution à installer sur les serveurs. Je n'ai donc eu aucun soucis pour l'installer : le service était up en quelques heures à peine en comptant la livraison du serveur. Magnifique !
ProxMox est finalement très simple à utiliser et propose pas mal de fonctionnalité en standard :
- authentification PAM : super, on peut directement se connecter en utilisant les utilisateurs du serveurs
- création et gestion de machines virtuelles KVM
- création et gestion de containers OpenVZ
- gestion des storages (des espaces de stockage dédiés)
- gestion du réseau
- ...
Dernière chose, ProxMox est accessible directement depuis une interface web, voilà à quoi ça ressemble :
L'interface ne donne pas forcément envie, c'est du ExtJS, mais, dans la stack que j'ai montée, c'est loin d'être la pire :)
KVM est l'un des technologie supportée par ProxMox en standard. Mais KVM, c'est quoi ?
KVM (for Kernel-based Virtual Machine) is a full virtualization solution for Linux on x86 hardware containing virtualization extensions (Intel VT or AMD-V). It consists of a loadable kernel module, kvm.ko, that provides the core virtualization infrastructure and a processor specific module, kvm-intel.ko or kvm-amd.ko. KVM also requires a modified QEMU although work is underway to get the required changes upstream.
Vous l'aurez compris, KVM est une solution de virtualisation pour Linux basé sur QEMU. Je ne rentrerais pas trop dans les détails ici pour éviter de vous raconter n'importe quoi. Si vous souhaitez obtenir plus de précisions sur cette technologie, demandez à "ceux qui savent", en l'occurence, pas moi car je ne suis pas spécialiste dans la virtualisation.
Maintenant, vous vous demandez peut-être une chose : à l'heure ou les containers sont à la mode et qu'à priori, ils sont capables de résoudre pas mal de problèmes, pourquoi j'ai choisi de garder la possibilité de construire des machines virtuelles lourdes ?
Tout simplement parce que les containers ne peuvent pas tout faire et que surtout, je ne suis pas spécialiste de ces derniers et que, quand je pense que je vais avoir un problème avec des containers je passe sur des machines virtuelles que je connais mieux.
Pour choisir, généralement je me pose ces questions :
- Qu'est-ce que je dois virtualiser ?
- Est-ce que j'ai réellement besoin de virtualiser un système complet ?
- Est-ce que je vais avoir besoin de m'y connecter en SSH ?
- Est-ce que je vais avoir besoin de démarrer des containers dedans ?
- Pour qui ?
La plupart du temps, ces questions me permettent de choisir la solution qui convient. Ce ne sont certainement pas les bonnes question, ou en tout cas, pas toutes les bonnes questions mais elle fonctionnent pour l'instant dans mon cas.
Grosso-modo, je virtualise un système complet dans les cas suivants :
- Je veux reproduire un système complet, par exemple, pour faire un serveru de staging
- Afin d'éviter les problèmes, si je dois démarrer des containers je choisirais de le faire dans un VM (je ne sais pas si démarrer un container dans un container fonctionne et est stable)
- Si je dois livrer ce système à un tiers, je livrerais une VM
Reste une dernière question : celle du SSH. Il n'y a pas si longtemps un article est sorti sur le fait que démarrer le démon SSH dans un container était une erreur. Je suis plutôt d'accord sur ce point (vous comprendrez pourquoi en lisant la suite) et quand j'ai besoin d'un SSH, je part sur une machine virtuelle.
Pour finir, quelques chiffres : aujourd'hui, je surveille uniquement deux machines virtuelles (contre une douzaine de containers). Je dis "surveille" car ces machines virtuelles ne sont pas "à moi".
OpenVZ est la seconde technologie supportée en standard par ProxMox. C'est une solution de virtualisation basée sur les containers (vous connaissez certainement Docker qui fournit des containers LXC). Les containers, c'est un peu comme les machines virtuelles mais en beaucoup plus léger :
OpenVZ is container-based virtualization for Linux. OpenVZ creates multiple secure, isolated Linux containers (otherwise known as VEs or VPSs) on a single physical server enabling better server utilization and ensuring that applications do not conflict.
Qu'est-ce qui est intéressant dans cette définition ? Principalement une chose : "ensuring that applications do not conflict". En gros, les containers permettent d'isoler une application dans un environnement. C'est très pratique et je suis presque sur que ces derniers auraient pu vous sauver la vie plus d'une fois si vous ne les utilisez pas.
Essayez de remonter dans vos souvenirs. Vous avez certainement déjà essayer de mettre un jour une brique sur l'un de vos serveurs et renoncer car la libc installée était trop vieille pour pouvoir installer la dernière version trop bien de tel ou tel service.
Avec les containers tout cela, c'est de l'histoire ancienne. Chacun de vos services aura son propre environnement, isolé et adapté. C'est juste magique !
Mon utilisation des containers est assez basiques mais me permet d'adresser presque tous les problèmes que j'ai pu avoir jusqu'à aujourd'hui, à savoir, isoler des services afin de pouvoir les mettre à jour sans risque de casser autre chose.
Généralement, lorsque je mets en place un containers, je le fais de la manière suivante :
- démarrage du container avec une configuration surdimensionnée
- installation du service dans l'environnement
- monitoring du container
- adaptation de la configuration au fur et à mesure
Vous l'aurez compris, mes containers sont très spécialisés, il n'héberge généralement qu'un seul service. Je m'autorise parfois à y installer plusieurs service tant que ceux-ci ont un scope commun : par exemple, un de mes containers héberge mon bouncer IRC mais aussi l'application web qui me permet de consulter les logs des salons et mon bot IRC. Le scope est le même, on travail avec IRC.
Comme je vous le disais, je commence toujours par démarrer mes containers avec une configuration surdimensionnée que j'adapte ensuite. Cela va me permettre de vous parler d'une chose que les containers propose : on peut les modifier à chaud. Si je veux ajouter un processeur, je le fais sans avoir de coupure de service. Même chose pour la RAM.
Voilà, maintenant vous savez comment j'utlise la virtuaisation pour subvenir à mes besoins. Mais la virtualisation ne fait pas tout. Avec ces technologie, vous vous retrouverez presque dans le même cas qu'un administrateurs qui gère plein de machines physiques. Gérer une infrastructure de ce type demande de mettre en place d'autre outils afin de lier les environnement et de les monitorer.
La première couche de services me permettant de gérer correctement ce cluster est directement installée sur l'hyperviseur. Ce n'est pas forcément la meilleure chose à faire, mais pour commencer à travailler correctement, j'ai eu un choix à faire, et j'ai fait celui-ci.
En effet, lors de la livraison de mon serveur tout neuf, sur lequel ProxMox était installé, il me fallait quelques services indispensables : du NAT et des logs.
- router les requêtes vers les bons VMs/CTs
- sécuriser les routes internes
- présentation des outils : service init.d/nat, nat-add, nat-remove, ...
- centraliser les logs
- lier les VMs/CTs entre eux facilement à l'intérieur du cluster
- gestion des configurations
- déploiement des services/configurations
- un cookbook par service/application/configuration
- un noeud par VM/CT
- chaque VM/CT est bootstrapé avec son chef-client
- parce que j'aime bien Hashicorp
- décentralisé
- présentation des outils : bootstraping, définitions de healthcheck et services
- sondes simples lancées sur les VMs/CTs
- rapports basiques
- pas d'historique (donc pas de graph)
- déclaration simple des services
- centralisation des services (annuaire)
- couplé au healthcheck permet de faire du fallback
- API basée sur le protocole DNS (je ne sais pas encore comment bien l'exploiter)
- supporte HTTP et TCP
- healthcheck
- présentation du cookbook haproxy-config
- très puissant
- remplace nginx
- très puissant
- simple à configurer
- simple à monitorer
- Parce que j'aime bien Gitlab
- Pour centraliser tous les outils d'administration internes
- Gérer avec Chef (installation, mise à jour, configuration)