Un jour, j'ai décidé d'écrire un article sur la livraison de colis docker et deb sous forme de conteneurs, mais quand j'ai commencé, pour une raison quelconque, j'ai souffert dans les jours lointains des premiers ordinateurs personnels et même des calculatrices. En général, au lieu de comparaisons sèches entre docker et deb, ce sont les réflexions sur l'évolution, que je présente à votre cour.
Tout produit, quel qu'il soit, doit en quelque sorte atteindre les serveurs de produits, doit être configuré et lancé. Cet article sera à ce sujet.
Je vais réfléchir dans le contexte historique, "ce que je vois - que je chante", ce que j'ai vu quand j'ai commencé à écrire du code et ce que j'observe maintenant, ce que nous utilisons nous-mêmes en ce moment et pourquoi. L'article ne prétend pas être une étude à part entière, certains points manquent, c'est ma vision personnelle de ce qui était et de ce qui est maintenant.
Donc, au bon vieux temps ... la première méthode de livraison que j'ai trouvée était avec des cassettes. J'avais un ordinateur BK-0010.01 ...
L'âge des calculatrices
Non, il y avait un point encore plus tôt, il y avait aussi une calculatrice
MK-61 et
MK-52 .
Donc, quand j'avais
MK-61 , la façon de transférer le programme était d'utiliser une feuille de papier ordinaire dans une boîte sur laquelle le programme était enregistré, qui, si nécessaire, était écrit manuellement sur la calculatrice. Si vous voulez jouer (oui, même il y avait des jeux sur cette calculatrice antédiluvienne), vous vous asseyez et entrez le programme dans la calculatrice. Naturellement, lorsque la calculatrice a été éteinte, le programme est tombé dans l'oubli. En plus des codes de calculateurs écrits sur papier personnellement, les programmes ont été publiés dans les magazines Radio and Technique of Youth, ainsi que dans les livres de l'époque.
La prochaine modification a été la calculatrice
MK-52 , il est déjà apparu une sorte de stockage de données non volatile. Désormais, le jeu ou le programme ne devait plus être manuellement piloté, mais, après avoir effectué quelques passes magiques avec des boutons, il se chargeait.
Le volume du plus grand programme de la calculatrice était de 105 pas, et la taille de la mémoire permanente du MK-52 était de 512 pas.
Soit dit en passant, s'il y a des fans de ces calculatrices qui lisent cet article - au cours du processus de rédaction de l'article, j'ai trouvé à la fois un émulateur de calculatrice pour Android et des programmes pour celui-ci. Passons au passé!
Une petite digression sur MK-52 (de Wikipedia)
Le MK-52 a volé dans l'espace à bord du vaisseau spatial Soyouz TM-7. Il était censé être utilisé pour calculer la trajectoire d'atterrissage en cas de panne de l'ordinateur de bord.
Le MK-52 avec l'unité d'extension de mémoire "Electronics-Astro" depuis 1988 a été fourni aux navires de la Marine dans le cadre d'un kit informatique de navigation.
Les premiers ordinateurs personnels
Revenons à l'époque de
BK-0010 . Il est clair qu'il y avait plus de mémoire là-bas, et ce n'était plus une option pour piloter du code à partir d'un morceau de papier (bien qu'au début je l'ai fait, car il n'y avait tout simplement pas d'autre support). Les principaux moyens de stockage et de livraison des logiciels sont les cassettes audio pour magnétophones.
Le stockage sur une cassette était généralement sous la forme d'un ou deux fichiers binaires, tout le reste était contenu à l'intérieur. La fiabilité était très faible, je devais garder 2-3 copies du programme. Le temps de chargement n'était pas non plus satisfaisant, les passionnés ont expérimenté différents codages de fréquence afin de pallier ces lacunes. À cette époque, je n’étais pas encore engagé dans le développement de logiciels professionnels (en dehors des simples programmes de base), donc, malheureusement, je ne vous dirai pas en détail comment tout était organisé à l’intérieur. Le fait de n'avoir que de la RAM sur l'ordinateur a pour la plupart déterminé la simplicité du schéma de stockage des données.
L'émergence de supports de stockage fiables et volumineux
Plus tard, des disquettes apparaissent, le processus de copie est simplifié et la fiabilité augmente.
Mais la situation ne change radicalement que lorsque des stockages locaux suffisamment grands apparaissent sous la forme d'un disque dur.
Le type de livraison change fondamentalement: des programmes d'installation apparaissent qui contrôlent le processus de configuration du système, ainsi que le nettoyage après la suppression, car les programmes ne sont pas simplement lus en mémoire, mais sont déjà copiés sur le stockage local, à partir duquel vous devez pouvoir effacer et inutiles si nécessaire.
Dans le même temps, la complexité du logiciel fourni augmente.
Le nombre de fichiers dans la livraison augmente d'unités à des centaines et des milliers, des conflits de versions de bibliothèque et d'autres joies commencent lorsque différents programmes utilisent les mêmes données.
À cette époque, l'existence de Linux n'était pas encore ouverte pour moi, je vivais dans le monde de MS DOS et, plus tard, de Windows, et j'écrivais en Borland Pascal et Delphi, jetant parfois un coup d'œil vers C ++. Pour fournir des produits à cette époque, beaucoup ont utilisé InstallShield
ru.wikipedia.org/wiki/InstallShield , qui a réussi à résoudre toutes les tâches de déploiement et de configuration de logiciels.
Âge d'Internet
Progressivement, la complexité des systèmes logiciels devient encore plus compliquée, à partir d'un monolithe et d'applications de bureau, il y a une transition vers des systèmes distribués, des clients légers et des microservices. Maintenant, vous devez configurer non pas un seul programme, mais leur ensemble, et pour qu'ils soient amis tous ensemble.
Le concept a complètement changé, Internet est venu, l'ère des services cloud est arrivée. Jusqu'à présent, il n'est interprété qu'au stade initial, sous forme de sites, personne ne rêvait surtout de services. mais ce fut un tournant dans l'industrie du développement et de la livraison effective des applications.
Pour ma part, j'ai remarqué qu'à ce moment il y avait un changement dans les générations de développeurs (ou c'était seulement dans mon environnement), et j'avais le sentiment que toutes les bonnes vieilles méthodes de livraison étaient oubliées à un moment et tout a commencé dès le début: ils ont commencé à faire la livraison entière avec des scripts à hauteur de genoux et l'a fièrement appelé «livraison continue». En fait, une période de chaos a commencé, lorsque l'ancien est oublié et non utilisé, mais il n'y a tout simplement pas de nouveau.
Je me souviens des moments où dans notre entreprise, où je travaillais à l'époque (je n'appellerai pas), au lieu de construire par le biais de fourmis (maven n'était pas encore populaire ou pas du tout), les gens venaient de ramasser des pots dans IDE et de s'engager lui en svn. En conséquence, le déploiement consistait à obtenir le fichier de SVN et à le copier via SSH sur la machine souhaitée. Si simple et maladroit.
Dans le même temps, la livraison de sites simples en PHP a été rendue assez primitive en copiant simplement le fichier corrigé via FTP sur la machine cible. Parfois, il n'y avait rien de tel - le code a été modifié en direct sur le serveur du produit, et c'était particulièrement chic s'il y avait des sauvegardes quelque part.
Forfaits RPM et DEB
D'autre part, avec le développement d'Internet, les systèmes de type UNIX ont commencé à gagner en popularité, en particulier, c'est à cette époque que j'ai découvert RedHat Linux 6 pour moi, vers 2000. Naturellement, il y avait certains outils pour la livraison de logiciels là-bas, selon Wikipedia, RPM comme le principal gestionnaire de paquets est apparu déjà en 1995, dans la version de RedHat Linux 2.0. Et depuis lors jusqu'à maintenant, le système a été livré sous forme de packages RPM et existe et se développe avec succès.
Les distributions de la famille Debian sont allées dans le même sens et ont implémenté la livraison sous forme de paquets deb, qui est également inchangée à ce jour.
Les gestionnaires de packages vous permettent de livrer les produits logiciels eux-mêmes, de les configurer pendant le processus d'installation, de gérer les dépendances entre les différents packages, de supprimer les produits et de nettoyer l'excédent lors de la désinstallation. C'est-à-dire pour la plupart, c'est tout ce qui est nécessaire, c'est pourquoi ils ont duré plusieurs décennies avec peu ou pas de changement.
Les nuages ont été ajoutés à l'installation des gestionnaires de packages non seulement à partir de supports physiques, mais également à partir de référentiels cloud, mais fondamentalement, peu de choses ont changé.
Il convient de noter qu'à l'heure actuelle, il y a quelques incitations à éviter deb et à passer aux packages snap, mais plus à ce sujet plus tard.
Ainsi, cette nouvelle génération de développeurs cloud, qui ne connaissait ni DEB ni RPM, a également progressé lentement, acquis de l'expérience, les produits sont devenus plus compliqués et des méthodes de livraison plus raisonnables étaient nécessaires que le FTP, les scripts bash et les métiers similaires des étudiants.
Et c'est ici que Docker entre en scène, une sorte de mélange de virtualisation, d'allocation de ressources et de méthodes de livraison. C'est à la mode, les jeunes, mais est-ce nécessaire pour tout? Est-ce une panacée?
Selon mes observations, très souvent Docker n'est pas proposé comme un choix raisonnable, mais simplement parce qu'il est, d'une part, parlé dans la communauté, et ceux qui le proposent ne le savent que. D'un autre côté, pour la plupart, ils se taisent sur les bons vieux systèmes d'emballage - ils le sont et le sont, ils font leur travail tranquillement et imperceptiblement. Dans une telle situation, il n'y a pas d'autre choix - le choix est évident - Docker.
J'essaierai de partager mon expérience sur la façon dont nous avons implémenté Docker et ce qui s'est passé en conséquence.
Scripts auto-écrits
Au départ, il y avait des scripts bash qui déployaient des archives jar sur les machines nécessaires. Géré ce processus par Jenkins. Cela a fonctionné avec succès, car l'archive jar elle-même est déjà un assemblage contenant des classes, des ressources et même une configuration. Si vous y mettez tout au maximum - puis développez-le avec un script - ce n'est pas la chose la plus difficile dont vous avez besoin
Mais les scripts ont plusieurs inconvénients:
- les scripts sont généralement écrits à la hâte et sont donc si primitifs qu'ils ne contiennent qu'un des scripts les plus réussis. Ceci est facilité par le fait que le développeur est intéressé par une livraison rapide et qu'un script normal nécessite une quantité décente de ressources.
- en conséquence du paragraphe précédent, les scripts ne contiennent pas la procédure de désinstallation
- aucune procédure de mise à niveau établie
- lorsqu'un nouveau produit apparaît, vous devez écrire un nouveau script
- pas de prise en charge des dépendances
Bien sûr, vous pouvez écrire un script sophistiqué, mais, comme je l'ai écrit ci-dessus, c'est le temps de développement, et pas le plus petit, mais, comme vous le savez, il n'y a toujours pas assez de temps.
Tout cela limite évidemment la portée de cette méthode de déploiement aux systèmes les plus simples. Le moment est venu de changer cela.
Docker
À un certain point, des middles fraîchement cuits au four ont commencé à venir à nous, bouillonnant d'idées et délirant avec un docker. Eh bien, le drapeau à la main - faites-le! Il y a eu deux tentatives. Les deux ont échoué - disons-le, à cause de grandes ambitions, mais du manque d'expérience réelle. Était-il nécessaire de forcer et de finir par quelque moyen que ce soit? C'est peu probable - l'équipe doit évoluer au niveau souhaité avant de pouvoir utiliser les outils appropriés. En plus de cela, en utilisant des images prêtes à l'emploi du docker, nous sommes souvent tombés sur le fait que le réseau ne fonctionnait pas correctement là-bas (ce qui, peut-être, était également lié à l'humidité du docker lui-même) ou qu'il était difficile d'agrandir les conteneurs d'autres personnes.
Quels inconvénients avons-nous rencontrés?
- Problèmes de réseau en mode pont
- Il n'est pas pratique de consulter les journaux dans le conteneur (s'ils ne sont pas transférés séparément vers le système de fichiers de la machine hôte)
- ElasticSearch périodiquement étrange se bloque à l'intérieur du conteneur, la raison n'a pas été établie, le conteneur est officiel
- C'est gênant d'utiliser la coque à l'intérieur du conteneur - tout est très bien coupé, il n'y a pas d'outils familiers
- Grands conteneurs à collecter - coûteux à stocker
- En raison de la grande taille des conteneurs, il est difficile de prendre en charge plusieurs versions
- Construction plus longue, contrairement à d'autres méthodes (scripts ou packages deb)
D'un autre côté, est-il pire de déployer un service Spring sous la forme d'une archive jar via le même deb? L'isolement des ressources est-il vraiment nécessaire? Vaut-il la peine de perdre des outils pratiques du système d'exploitation, en fourrant le service dans un conteneur fortement garni?
Comme la pratique l'a montré, en réalité ce n'est pas nécessaire, un paquet deb suffit dans 90% des cas.
Quand le bon vieux deb échoue-t-il et quand avons-nous vraiment besoin d'un docker?
Pour nous, il s'agissait d'un déploiement de services en python. De nombreuses bibliothèques nécessaires à l'apprentissage automatique et non disponibles dans la livraison standard du système d'exploitation (et ce qu'il y avait de mauvaises versions), des hacks avec des paramètres, la nécessité de différentes versions pour différents services vivant sur le même système hôte ont conduit à que le seul moyen raisonnable d'approvisionner ce mélange nucléaire était le docker. La complexité de l'assemblage du conteneur Docker s'est avérée inférieure à l'idée de tout emballer dans des paquets Deb séparés avec des dépendances, et personne de bon sens ne l'aurait pris.
Le deuxième point où vous envisagez d'utiliser Docker concerne le déploiement de services à l'aide du schéma de déploiement bleu-vert. Mais ici, je veux obtenir une augmentation progressive de la complexité: d'abord, les packages deb sont collectés, puis un conteneur docker est assemblé à partir d'eux.
Paquets instantanés
Retour aux packages snap. Ils sont apparus officiellement pour la première fois dans Ubuntu 16.04. Contrairement aux packages deb et rpm habituels, snap transporte toutes les dépendances. D'une part, cela évite les conflits de bibliothèques, d'autre part, cela signifie des tailles plus importantes du package résultant. De plus, la même chose peut affecter la sécurité du système: dans le cas d'une livraison instantanée, toutes les modifications apportées aux bibliothèques incluses doivent être surveillées par le développeur qui crée le package. En général, tout n'est pas si simple et le bonheur général de leur utilisation ne vient pas. Mais, néanmoins, c'est une alternative tout à fait raisonnable, si le même Docker n'est utilisé que comme moyen de packaging, et non de virtualisation.
En conséquence, nous utilisons maintenant les packages deb et les conteneurs docker dans une combinaison raisonnable, que nous remplacerons peut-être dans certains cas par des packages snap.