Un jour, j'ai décidé d'écrire un article sur la livraison sous forme de conteneurs Docker et de paquets deb, mais en commençant, je me suis retrouvé à plonger dans les temps anciens des premiers ordinateurs personnels et même des calculatrices. Ainsi, au lieu de comparaisons sèches entre Docker et deb, voici mes réflexions sur le thème de l'évolution, que je vous soumets.
Tout produit, peu importe ce qu'il est, doit d'une manière ou d'une autre parvenir aux serveurs de production, il doit être configuré et lancé. C'est ce dont cet article va parler.
Je vais réfléchir dans un contexte historique, « je chante ce que je vois », ce que j'ai vu lorsque j'ai commencé à écrire du code et ce que j'observe maintenant, ce que nous utilisons actuellement et pourquoi. Cet article ne prétend pas être une recherche complète, certains points sont omis, c'est mon point de vue personnel sur ce qui a été et ce qui est maintenant.
Alors, dans les bons vieux temps… le moyen de livraison le plus ancien que j'ai connu était les cassettes de magnétophones. J'avais un ordinateur BK-0010.01…
L'époque des calculatrices
Non, il y avait un moment encore plus ancien, il y avait une autre calculatrice et .
Ainsi, lorsque j'avais , le moyen de transférer le programme était une simple feuille de papier quadrillée sur laquelle était inscrite le programme, qui, en cas de besoin, était tapé manuellement dans la calculatrice. Tu veux jouer (oui, oui, même sur cette calculatrice préhistorique, il y avait des jeux) — tu t'assois et tu entres le programme dans la calculatrice. Évidemment, en éteignant la calculatrice, le programme disparaissait. En plus des codes que j'avais écrits à la main sur le papier, des programmes étaient publiés dans les revues « Radio » et « Technique des jeunes » et étaient également imprimés dans des livres de l'époque.
La modification suivante était la calculatrice , elle avait déjà un semblant de stockage de données non volatile. Maintenant, il n'était plus nécessaire de taper le jeu ou le programme manuellement, après avoir effectué quelques mouvements magiques avec les boutons, il se chargeait tout seul.
Le volume du plus grand programme dans la calculatrice était de 105 étapes, et la taille de la mémoire permanente dans le MK-52 était de 512 étapes.
Au fait, s'il y a des fans de ces calculatrices qui lisent cet article — pendant que j'écrivais cet article, j'ai trouvé un émulateur de calculatrice pour Android et des programmes pour cela. En avant, dans le passé !
Une petite digression sur MK-52 (de Wikipédia)
MK-52 a volé dans l'espace à bord du vaisseau « Soyouz TM-7 ». Il était prévu de l'utiliser pour le calcul de la trajectoire d'atterrissage en cas de défaillance de l'ordinateur de bord.
Depuis 1988, le MK-52 avec le module d'extension de mémoire « Électronique-Astro » était fourni aux navires de la marine dans le cadre de l'ensemble de calcul pour navigateurs.
Les premiers ordinateurs personnels
Retournons à l'époque . Évidemment, il y avait plus de mémoire, et il n'était plus du tout envisageable de saisir le code à partir d'un document (bien que, pendant un certain temps, j'ai fait précisément cela, car je n'avais pas d'autre support). Les cassettes audio pour magnétophones deviennent le principal moyen de stockage et de distribution de logiciels.
Le stockage sur cassette était généralement sous la forme d'un ou deux fichiers binaires, tout le reste étant contenu à l'intérieur. La fiabilité était très faible, il fallait garder 2-3 copies de programme. Le temps de chargement n'était pas non plus satisfaisant, les passionnés expérimentaient avec divers codes de fréquence pour surmonter ces inconvénients. À cette époque, je ne m'occupais pas encore de développement logiciel professionnel (à l'exception de quelques programmes simples en Basic), donc je ne peux malheureusement pas expliquer comment tout cela était agencé à l'intérieur. Le simple fait que l'ordinateur ne dispose que de RAM déterminait en grande partie la simplicité du schéma de stockage des données.
L'apparition de supports d'information fiables et volumineux
Plus tard, les disquettes apparaissent, simplifiant le processus de copie et augmentant la fiabilité.
Mais la situation change radicalement seulement avec l'apparition de supports locaux suffisamment grands sous forme de HDD.
Le type de distribution change fondamentalement : des programmes d'installation apparaissent, qui gèrent le processus de configuration du système ainsi que le nettoyage après suppression, car les programmes ne sont plus simplement lus en mémoire, mais sont déjà copiés sur le stockage local, à partir duquel il faut également savoir supprimer ce qui ne sert plus en cas de besoin.
Parallèlement, la complexité des logiciels livrés augmente.
Le nombre de fichiers dans la distribution passe d'une unité à des centaines et des milliers, des conflits de versions de bibliothèques et d'autres désagréments commencent, lorsque différents programmes utilisent les mêmes données.
À cette époque, je ne connaissais pas encore l'existence de Linux, je vivais dans un monde de MS DOS et, plus tard, de Windows, et je programmais en Borland Pascal et Delphi, tout en jetant parfois un œil vers C++. Pour la livraison des produits à cette époque, beaucoup utilisaient InstallShield , qui était tout à fait capable de résoudre toutes les tâches de déploiement et de configuration des logiciels.
L'ère de l'Internet
La complexité des systèmes logiciels augmente progressivement, passant de monolithes et d'applications de bureau à des systèmes distribués, des clients légers et des microservices. Il ne s'agit plus de configurer une seule application, mais un ensemble d'entre elles, de manière à ce qu'elles fonctionnent ensemble.
La conception a complètement changé, Internet est arrivé, ouvrant l'ère des services cloud. À cette époque, c'était encore aux premiers stades, sous forme de sites, et personne ne rêvait encore vraiment de services. Mais cela a marqué un tournant dans l'industrie, tant en matière de développement que de livraison d'applications.
Pour moi, ce moment a marqué un changement de génération chez les développeurs (ou était-ce juste dans mon entourage) et il y avait une impression que toutes les anciennes méthodes de livraison avaient été oubliées d'un coup et que tout avait recommencé depuis le début : toute la livraison s'est faite avec des scripts temporaires, que l'on a fièrement appelés « Continuous delivery ». En réalité, une sorte de période de désordre a commencé, où l'ancien était oublié et inutilisé, et le nouveau n'était tout simplement pas là.
Je me souviens des temps où, dans l'entreprise où je travaillais alors (je ne dirai pas son nom), au lieu de faire un build avec ant (maven n'était pas encore populaire ou n'existait pas), les gens compilaient simplement des jar dans l'IDE et les commettaient paisiblement dans SVN. Du coup, le déploiement consistait à récupérer le fichier de SVN et à le copier par SSH sur la machine cible. C'était aussi simple que ça.
À cette époque, la livraison de simples sites en PHP se faisait de manière très primitive, en copiant simplement le fichier corrigé via FTP sur la machine cible. Parfois, même cela n'était pas fait — le code était modifié en temps réel sur le serveur de production, et c'était particulièrement chic s'il y avait des sauvegardes quelque part.
des paquets RPM et DEB
D'un autre côté, avec l'évolution d'Internet, les systèmes de type UNIX ont commencé à gagner en popularité, et c'est à cette époque que j'ai découvert RedHat Linux 6, vers 2000. Il est évident qu'il y avait également des outils pour la distribution de logiciels, selon Wikipédia, RPM, le principal gestionnaire de packages, est apparu en 1995 avec la version 2.0 de RedHat Linux. Depuis lors, et jusqu'à nos jours, le système est distribué sous forme de paquets RPM et continue de fonctionner et de se développer avec succès.
Les distributions de la famille Debian ont suivi une voie similaire et ont mis en place une distribution sous forme de paquets deb, ce qui reste inchangé jusqu'à aujourd'hui.
Les gestionnaires de packages permettent de fournir les logiciels eux-mêmes, de les configurer lors de l'installation, de gérer les dépendances entre différents paquets, ainsi que d'effectuer la suppression des produits et le nettoyage des restes lors de la désinstallation. En gros, c'est tout ce dont on a besoin, et c'est pourquoi ils ont duré plusieurs décennies pratiquement sans changements.
L'essor du cloud a ajouté aux gestionnaires de packages la possibilité d'installer non seulement à partir de supports physiques, mais aussi depuis des dépôts cloud, mais fondamentalement, peu de choses ont changé.
Il convient de noter qu'actuellement, il y a quelques tentatives de passer de deb à des paquets snap, mais nous en parlerons plus tard.
Ainsi, cette nouvelle génération de développeurs cloud, qui ne connaissait ni DEB ni RPM, a également progressivement grandi, acquérant de l'expérience, les produits devenaient plus complexes, et il fallait des méthodes de distribution plus raisonnables que FTP, des petits scripts bash et d'autres bricolages étudiants.
C'est ici que Docker entre en scène, une sorte de mélange de virtualisation, de cloisonnement des ressources et de méthode de distribution. C'est à la mode, c'est jeune, mais en a-t-on besoin pour tout ? Est-ce une panacée ?
D'après mes observations, Docker est souvent proposé non pas comme un choix raisonnable, mais simplement parce que, d'un côté, on en parle dans la communauté, et ceux qui le proposent ne connaissent que ça. D'autre part, les anciens systèmes d'emballage font souvent l'objet de silences — ils existent et font leur travail silencieusement et discrètement. Dans cette situation, il n'y a pas vraiment d'autre choix — le choix est évident : Docker.
Je vais essayer de partager mon expérience sur la manière dont nous avons intégré Docker et ce que nous en avons tiré.
Scripts faits maison
Au départ, il y avait des scripts bash qui déployaient des archives jar sur les machines nécessaires. Jenkins gérait ce processus. Cela fonctionnait bien, d'autant plus que l'archive jar elle-même est déjà un assemblage contenant des classes, des ressources et même une configuration. Si l'on y met tout ce qu'il faut, le déployer avec un script n'est pas la tâche la plus complexe.
Mais les scripts ont plusieurs inconvénients :
- les scripts sont généralement écrits à la hâte et sont donc si primitifs qu'ils contiennent uniquement un seul scénario couronné de succès. Cela est dû au fait que le développeur est intéressé par une livraison rapide, alors qu'un script de qualité nécessite un investissement assez conséquent en ressources.
- comme conséquence du point précédent, les scripts ne contiennent pas de procédure de désinstallation.
- il n'y a pas de procédure de mise à jour établie.
- lorsqu'un nouveau produit apparaît, il faut écrire un nouveau script.
- il n'y a pas de prise en charge des dépendances.
Bien sûr, on peut écrire un script sophistiqué, mais comme je l'ai mentionné plus haut, cela prend du temps à développer, et ce n'est pas négligeable ; or, comme on le sait, le temps manque toujours.
Tout cela limite clairement l'utilisation de cette méthode de déploiement à des systèmes très simples. Il est temps d'y apporter des changements.
Docker
À un moment donné, des développeurs de niveau intermédiaire sont venus nous voir, débordants d'idées et passionnés par Docker. Eh bien, nous y voilà ! Il y a eu deux tentatives. Les deux ont échoué, disons, en raison de grandes ambitions mais d'un manque d'expérience réelle. Fallait-il forcer et terminer à tout prix ? Difficile à dire : l'équipe doit évoluer de manière organique jusqu'au niveau requis avant de pouvoir utiliser les outils appropriés. De plus, en utilisant des images Docker prêtes à l'emploi, nous avons souvent rencontré des problèmes de réseau (ce qui, peut-être, était aussi lié à l'immaturité de Docker lui-même) ou à la difficulté d'étendre des conteneurs d'autrui.
Quels désagréments avons-nous rencontrés ?
- Problèmes de réseau en mode bridge.
- Il est difficile de consulter les logs dans le conteneur (s'ils ne sont pas extraits dans le système de fichiers de la machine hôte).
- Parfois, un étrange gel d'ElasticSearch à l'intérieur du conteneur, la cause n'a jamais été établie, le conteneur étant officiel.
- Il est peu pratique d'utiliser le shell dans le conteneur : tout est très limité, il n'y a pas d'outils familiers.
- La grande taille des conteneurs collectés - coûteux à stocker
- À cause de la grande taille des conteneurs, il est difficile de maintenir plusieurs versions
- Assemblage plus long, contrairement à d'autres méthodes (scripts ou paquets deb)
D'un autre côté, en quoi un service Spring sous forme d'archive jar est-il pire à déployer via le même deb ? A-t-on vraiment besoin d'une isolation des ressources ? Faut-il renoncer aux outils pratiques du système d'exploitation en empaquetant le service dans un conteneur fortement réduit ?
Comme l'a montré la pratique, en réalité cela n'est pas nécessaire, un paquet deb suffit dans 90 % des cas.
Quand l'ancien paquet deb ne fonctionne-t-il pas et quand avons-nous réellement eu besoin de Docker ?
Pour nous, cela concernait le déploiement de services en python. De nombreuses bibliothèques nécessaires pour l'apprentissage automatique étaient absentes dans la distribution standard du système d'exploitation (et celles qui y étaient n'étaient pas les bonnes versions), des hacks de configuration, la nécessité d'avoir différentes versions pour différents services cohabitant sur le même système hôte, ont conduit à ce que le seul moyen raisonnable de fournir ce mélange complexe restait Docker. La charge de travail pour assembler un conteneur Docker s'est révélée inférieure à celle de l'idée d'emballer tout cela dans des paquets deb séparés avec des dépendances, et personne d'assez sain d'esprit ne s'en serait chargé.
Un deuxième point où Docker est prévu d'être utilisé - pour le déploiement de services selon le schéma blue-green deploy. Mais ici, on souhaite obtenir une augmentation progressive de la complexité : d'abord, des paquets deb sont assemblés, puis à partir de ceux-ci, un conteneur Docker est créé.
Paquets Snap
Revenons aux paquets Snap. Ils sont apparus officiellement pour la première fois dans Ubuntu 16.04. Contrairement aux paquets deb et rpm habituels, les snaps contiennent toutes les dépendances. D'un côté, cela permet d'éviter les conflits de bibliothèques, de l'autre, cela entraîne des tailles de paquets résultants plus importantes. De plus, cela peut également influencer la sécurité du système : lors de la livraison d'un snap, le développeur qui crée le paquet doit suivre toutes les modifications apportées aux bibliothèques incluses. En général, tout cela n'est pas aussi simple et le bonheur universel de leur utilisation ne se réalise pas. Cependant, cela reste une alternative raisonnable si Docker est utilisé uniquement comme moyen d'emballage et non de virtualisation.
En fin de compte, nous utilisons actuellement un mélange raisonnable de paquets deb et de conteneurs Docker, que nous remplacerons éventuellement par des paquets snap dans certains cas.
Seuls les utilisateurs enregistrés peuvent participer au sondage. , s'il vous plaît.
Qu'utilisez-vous pour la livraison ?
Scripts faits maison
Nous copions manuellement sur FTP
paquets deb
paquets rpm
paquets snap
images Docker
Images de machines virtuelles
Nous clonons entièrement le HDD
puppet
ansible
Autre
109 utilisateurs ont voté. 32 utilisateurs se sont abstenus.
Source : habr.com
