Ayant travaillé dans l'informatique pendant 10 ans, je me suis rendu compte qu'il est tout simplement irréaliste de s'appuyer sur du matériel. Il a tendance à se décomposer. Très souvent. De façon inattendue.
Heureusement, le monde continue de tourner et de plus en plus de solutions de haute disponibilité apparaissent chaque année. Il n'est pas facile de créer une bonne architecture HA. En essayant d'équilibrer qualité et prix, j'ai appliqué la virtualisation, drdb, pacemaker, nginx, haproxy, j'ai construit divers clusters de bases de données à haute disponibilité postgres, mysql avec basculement automatique, etc.
Naturellement, le construire manuellement ne peut être intéressant que plusieurs fois. Plus tard, ces solutions ont été automatisées à l'aide de Puppet, qui a été suivie en un an par SaltStack.
Tout semblait bien fonctionner.
Cependant, c'est plus compliqué qu'il n'y paraît :
Il ne fait aucun doute que la virtualisation résout la plupart de ces problèmes. J'ai choisi de ne pas utiliser KVM à l'époque et j'ai configuré tous les nouveaux environnements sur cette base. De nombreuses machines virtuelles nécessitent un contrôle. Des plates-formes telles que CloudStack, OpenStack et d'autres s'acquittent parfaitement de cette tâche.
Cependant, ces solutions ne sont efficaces que pour les projets de moyenne et grande envergure. Si un projet est petit et qu'il commence à croître de façon spectaculaire, nous avons un problème. Nous devons soit payer trop cher et configurer à l'origine une architecture complexe et volumineuse, soit commencer à migrer vers le cloud alors qu'il y a déjà beaucoup de trafic de production. Et, comme vous le savez tous, le passage de la production à une architecture différente avec un minimum de temps d'arrêt est un défi de taille.
Puis j'ai commencé à regarder les conteneurs, FreeBSD étant mon préféré (à vrai dire, je suis presque devenu fan de FreeBSD). Il s'agissait d'un moyen rapide et facile d'exécuter un conteneur avec l'ensemble des logiciels nécessaires dans un environnement isolé, de le contrôler et de le cloner facilement. J'ai tellement aimé travailler avec Jail et ZFS, en particulier avec ZFS, que j'ai transféré un projet d'hébergement Python/Django de ZFS à Jail.
Le seul inconvénient était qu'il était difficile d'utiliser FreeBSD partout : les gens, en particulier les développeurs, se sont habitués à Linux. C'était compréhensible ; Linux avait exclu BSDN du marché de l'hébergement il y a longtemps.
Puis, en 2013, alors que je me détendais quelque part le long de la côte vietnamienne, je suis tombée sur un projet OpenSource appelé Docker. La technologie était tellement inspirante que je n'ai pas pu m'empêcher de rédiger une application d'une page intitulée Lancez votre site en 1 clic.
L'idée était simple : vous avez cliqué sur un gros bouton et vous avez obtenu un domaine, un dépôt git et un port SSH. Vous pouvez placer votre code Python dans le git et le voir sur le site, ainsi qu'obtenir un accès root au conteneur si nécessaire.
Le lendemain matin, j'ai publié le lien vers ce site dans un groupe Google+ dédié à Python et j'ai pris ma moto pour me rendre au phare de la côte sud. Quand je suis rentré dans mon village, mon téléphone a été connecté à Internet et j'ai vu que mon compte Google+ était plein de messages. D'ailleurs, des centaines de personnes se sont précipitées pour tester ce service !
Mais ce qui est triste, c'est que quelqu'un a écrit : « J'ai arrêté ton serveur ». J'ai commencé à m'y intéresser dès mon retour. Il s'est avéré que le disque SSD du serveur était à court d'espace. Quelqu'un avait simplement exécuté :
« alors que c'est vrai ; do date >> ~/1.bin ; terminé ».
Cette personne s'est identifiée dans les commentaires. Il a dit que Docker était une mauvaise technologie, qu'elle n'avait aucune chance dans cet univers et qu'openvz était la solution ultime.
.jpg)
Franchement, j'ai été frustré par une telle tournure des événements. Il n'y avait en effet aucune limite à l'espace disque pour un conteneur Docker. Je me suis habitué aux quotas dans ZFS et je n'arrivais pas à comprendre comment quelque chose de similaire pouvait être créé dans Docker.
Tout compte fait, cette personne a ébranlé mon enthousiasme pour Docker et j'ai arrêté de développer dans cette direction. Mais pas avant longtemps.
En 2014, je travaillais uniquement en tant que freelance et j'avais beaucoup de jeunes projets avec des exigences très similaires. Tout le monde avait besoin de solutions d'architecture similaires, de technologies standard et de besoins commerciaux similaires :
Puis je me suis souvenu de Docker. À peu près au même moment, j'ai découvert Gitlab (j'avais l'habitude de configurer gitolite + redmine auparavant, ce qui n'était pas très pratique).
Finalement, j'ai trouvé une solution qui connectait Docker à Gitlab. Git a simplement accroché la création d'images après l'avoir envoyée à un référentiel, l'a envoyée à un registre Docker privé, a lancé des tests de conteneurs et, si tout allait bien, il a commandé aux serveurs de différents environnements de recréer le conteneur. Cela a très bien fonctionné.
À cette époque, j'avais très bien appris à travailler avec Docker Volume, le réseau Docker, et je collectais ma propre collection de Dockerfiles, qui contenait les images les plus courantes utilisées dans les projets.
Plus tard, j'ai obtenu des fichiers docker-compose, qui m'ont permis de développer rapidement Compose pour le développement local.
Tout allait bien jusqu'à ce que le projet prenne de l'ampleur. Bash force ne suffisait plus et un problème d'orchestration des conteneurs est apparu. Puis j'ai découvert Tutum (maintenant c'est https://cloud.docker.com/).
Tutum était un rêve. Cela a permis de transformer un projet très dynamique basé sur une architecture de microservices http://checkio.org dans des conteneurs sans rencontrer de problèmes, le seul inconvénient étant la nécessité de stocker les images sur ses serveurs. Tous les clients ne seraient pas d'accord là-dessus.
Chaque mois, Docker devenait de plus en plus stable et pleinement fonctionnel. En un an, j'ai même arrêté de le comparer à FreeBSD Jail ! Cela s'est poursuivi jusqu'à l'automne 2016, date à laquelle il est devenu nécessaire de créer un cluster de haute disponibilité avec orchestration et évolutivité pour une société de paris.
L'une des exigences importantes était la rapidité de déploiement, la modularité et l'hébergement des nouveaux environnements sur leurs serveurs dédiés. Les conteneurs s'inscrivent parfaitement dans ce paradigme, mais il fallait trouver un autre élément pour faciliter leur gestion dans une architecture multiservices.
À l'époque, il y avait :
J'ai commencé mes recherches avec Docker Swarm car il était beaucoup plus stable et plus proche du Docker lui-même. Swarm a fait ses preuves lors des tests, mais le plus important qui m'a poussé à continuer à chercher, c'est son manque de flexibilité et même une certaine part de sa rareté technologique.
Kubernetes de Google s'est révélé être un projet très important et prometteur doté de fonctionnalités flexibles et d'un format de manifeste pratique utilisant YAML.
J'ai rapidement développé un prototype à partir d'un nœud maître et de plusieurs nœuds minion et j'ai commencé à expérimenter. Au cours du premier mois, j'ai trouvé tellement de bugs que j'ai passé tout mon temps à les vérifier dans les problèmes de Githib, et s'il y avait un bogue nouveau, à le signaler. Le code a été corrigé et développé à une vitesse incroyable !
Je me souviens d'avoir signalé un bug d'installation et d'être allé à la gare. Pendant que j'étais dans mon taxi (environ 40 minutes), le bogue a été corrigé et envoyé au maître !
Pendant quelques mois, mon expérience avec Kubernetes a été similaire à celle de me frayer un chemin à travers des arbustes épineux quelque part dans les montagnes.
Chaque jour, Kuber devenait de plus en plus stable, tandis que mes compétences s'amélioraient.
Kubernetes a démarré la production avec un minimum de temps d'arrêt (quelques minutes pour rediriger les requêtes vers la base de données) et le voilà, fonctionnant à merveille.
Le déploiement avec Rolling Update (nous y reviendrons plus tard) a supprimé les interruptions de service dans la plupart des déploiements ultérieurs. La description de l'architecture dans les fichiers YAML de Kubernetes a permis de déployer de nouveaux environnements très rapidement. Et l'intégration de Gitlab a permis aux développeurs d'oublier les problèmes d'incompatibilité des différentes bibliothèques dans différents environnements.
Plus tard, nous avons défini des limites qui ont permis de fonctionner efficacement en cas de fuite de mémoire sur l'un des microserveurs, et nous avons même rendu ce problème à peine perceptible pour l'utilisateur jusqu'à ce qu'il soit corrigé dans le code.
.jpg)
La surveillance a permis de collecter les mesures en fonction de groupes de services spécifiques et de comprendre comment les modifications apportées au code affectent la latence et la consommation de ressources.
Au cours des 6 derniers mois, notre équipe s'est spécialisée dans des projets traitant des crypto-monnaies. Il s'agit d'un marché extrêmement curieux et dynamique et, ce qui est important, c'est que nos produits et notre expertise répondent aux exigences du domaine : haute disponibilité, sécurité et mise à l'échelle automatique. Jusqu'à présent, nous avons développé plusieurs solutions d'architecture prêtes à l'emploi pour des projets typiques côté serveur qui fonctionnent avec la blockchain :
Nous travaillons actuellement à la création d'un service REST, qui peut simplifier le travail des crypto-monnaies avec la blockchain : créer des adresses, effectuer des opérations de transfert d'argent et envoyer automatiquement l'argent vers le portefeuille distant.
Nous travaillons également à la création d'un programme d'installation automatique HA Kubernetes dans AWS avec interface Web, qui vous présentera certaines de nos solutions et vous donnera l'occasion de les tester.
Nous avons donc de nombreuses découvertes en réserve, que mon équipe et moi partagerons avec vous.
Le voyage est en cours.
.jpg)
