Y a-t-il des inconvénients à utiliser un package deb comme s'il s'agissait d'un conteneur pour déployer une application?

Mon équipe essaie actuellement de décider si nous devons déployer notre application Nodejs en tant que package deb au lieu d'essayer de l'exécuter dans un conteneur tel que Docker.

J'ai eu cette idée en lisant ce blog ici qui présente de bons arguments pour utiliser un paquet deb pour une application python préexistante. Le point principal de ce blog qui nous séduit est la question du maintien de l'écosystème Docker (partage de port, autorisations, hébergement d'images Docker, etc.)

Il semble que "dep-packages comme conteneurs d'origine" ait beaucoup de sens pour les petits services où il n'y a pas de soucis de conflits de port et où toutes les dépendances sont maintenues dans un environnement virtuel.

Mon instinct, cependant, me dit que si les packages deb étaient un bon choix, ce serait plus courant et le docker serait annoncé comme une solution plus spécifique à la langue. Y a-t-il des inconvénients à utiliser quelque chose comme des packages deb pour déployer nos services, au lieu d'utiliser un système complet tel que docker?

Tout d'abord, bien que Docker soit parfois vu et utilisé comme un système de packaging ad hoc , il résout en fait un problème totalement différent: Docker concerne l' exécution de programmes. Le Docker système permet de décrire les services, qui peuvent être mis à l' échelle à volonté et de contrôler des essaims de conteneurs. Les paquets Debian sont destinés à l'installation de programmes et ils sont capables de gérer les dépendances entre les versions du logiciel. Docker ne sont certainement pas considérés comme un système de packaging descendant: chaque "package" ne peut avoir qu'une seule dépendance, le système n'a pas d'option "build récursif" et ne supporte pas les contraintes de version complexes!

Une réponse possible serait que, si vous êtes prêt à écrire un paquet Debian pour votre application, vous pouvez également utiliser Docker pour déployer votre application. Ceci peut être réalisé avec un script de configuration apt_setup.shqui ressemblerait à

apt-key add - <<EOF
-----BEGIN PGP PUBLIC KEY BLOCK-----
<YOUR RELEASE OFFICER PGP KEY GOES HERE>
EOF

cat >> /etc/apt/sources.list <<EOF
deb https://my.organisation.org/repo debian-jessie main
apt-get update -y
apt-get upgrade -y
EOF

et un le Dockerfilelong des lignes de

ADD apt_setup.sh /root
RUN sh -ex /root/apt_setup.sh && rm /root/apt_setup.sh
RUN apt-get install -y my-node-js-package

(Dans votre situation spécifique, le apt_setup.shserait plus compliqué, en ajoutant les référentiels nœudsource et certains packages d'assistance tels que apt-transport-https .)

Il est donc vraiment possible d'utiliser simultanément les paquets Debian et Docker …

Mon instinct […] me dit que si les paquets deb étaient un bon ajustement, ce serait plus courant

C'est un attelage correct qui nous amène à nous demander pourquoi Docker s'avère être populaire en tant que système d'emballage ad hoc , alors qu'il n'est pas destiné à en être un. (Voir au dessus.)

Le système de conditionnement «officiel» d'une distribution donnée n'est qu'une possibilité parmi tant d'autres d'installer des logiciels dans un environnement informatique. Il existe de nombreuses autres sources disponibles, comme les gestionnaires de packages spécifiques à la communauté tels que npm ou opam, les arborescences de ports comme pkgsrc et la distribution de code source standard . De ce point de vue, il est facile de comprendre le succès de Docker en tant que système d'emballage ad hoc :

• Les spécifications de Docker sont très proches d'un script shell et quelle que soit la source, nous installons des logiciels en utilisant le shell.

• Docker dispose d'un service «intégré» (payant) pour l'hébergement des artefacts qu'elle produit, le Docker Hub .

Maintenant, quelle est la force des paquets Debian sur les images Docker en tant que système de paquets? Le contrôle strict des dépendances lors de l'installation. (La possibilité de mise à niveau et de rétrogradation existe également mais n'a aucune importance pratique si nous implémentons le modèle de serveur immuable .)

Conclusion

Si vous n'avez qu'un seul produit déployé dans une seule version (ce qui est typique du SaaS), vos besoins de gestion de version sont très simples et l'utilisation de Docker en tant que gestionnaire de packages ad hoc ne devrait pas présenter d'inconvénients majeurs. Dès que vous travaillez avec plusieurs versions d'un même produit ou de plusieurs produits, la complexité du problème de contraintes de version que vous devez résoudre augmente et vous avez besoin d'un outil approprié pour cela, qui peut être des paquets Debian ou un système de gestion de configuration si vous êtes mélange de logiciels d'origines différentes.

Oui, il y a des inconvénients.

Avec un package .deb, vous ne pourrez pas avoir deux versions de la même application sur le même hôte. Vous devrez vous fier aux packages de distribution disponibles, si votre application s'appuie sur nodejs par exemple, soit vous serez bloqué avec la version de distribution, soit vous devrez installer la vôtre.

Maintenant, lorsque vous souhaitez héberger plusieurs applications sur le même hôte, vous heurterez un mur très rapidement lorsqu'elles dépendent de la même chose (gardons nodejs ici) dans deux versions différentes.

Le principal objectif de Docker est d'isoler chaque application du système d'hébergement et d'autres applications sur le même hôte. il y a deux raisons de faire cet isolement: 1. pour éviter la compromission de l'application pour pouvoir prendre le contrôle de l'hôte ou avoir un impact sur une autre application 2. pour donner à l'application ses dépendances exactes et éviter qu'elle ne soit affectée par une mise à jour du système ou une autre application dépendance.

Un paquet Debian (ou RedHat) pour installer des applications a été une bonne pratique lorsqu'il est fait correctement. Les packages sont utilisés dans le but de déployer des applications qui sont rarement modifiées. Les paquets Debian impliquent certains frais généraux, comme la gestion des versions, la gestion des dépendances, les scripts de pré et post-installation, etc ...

Dans de nombreux cas, la mise à niveau d'une ancienne version vers une nouvelle version nécessite une écriture soigneuse des scripts, une attention aux détails dans la version, etc. Parce que la mutation de l'état existant est difficile. Il serait beaucoup plus facile de remplacer l'état actuel par un nouvel état, sans rien muter.

Une fois que vous décidez de remplacer complètement votre configuration ou vos dépendances ou votre application sur chaque déploiement, car c'est plus facile et moins sujet aux erreurs. La plupart des organisations (auparavant) basculent vers une toute nouvelle VM ou instance cloud. Ce qui signifie que l'installation du package se ferait sur un serveur "propre", et la mutation des fichiers et de la configuration sur le serveur n'est plus un problème.

Les développeurs qui ont créé des packages et n'ont pas compris le sophisme et la complexité des mutations ont en conséquence rencontré beaucoup de difficultés.

Le remplacement de machines virtuelles n'est pas optimal lorsque vous n'avez besoin que de remplacer une application, c'est pourquoi des conteneurs légers ont été introduits comme réponse. À l'aide de Docker (ou d'un autre LWC), vous pouvez remplacer la base d'utilisateurs, y compris toutes les dépendances, sans remplacer le serveur lui-même. Vous pouvez également héberger plusieurs versions de la même application, avec différentes dépendances, sur le même serveur et ne commuter le trafic réseau entrant que lors de la mise à niveau. En plus de rétablir le trafic réseau lors de la restauration (bleu-vert), ce qui était remarquablement difficile dans le cas de la gestion des déploiements via des packages.

Les conteneurs introduisent un moyen de regrouper tout le code d'application, les dépendances et la configuration dans une image. Cette image possède plusieurs propriétés qui la rendent bien meilleure que les packages de système d'exploitation traditionnels. Par exemple, il a des balises qui permettent le contrôle de version, mais il a également des couches, qui permettent d'économiser de l'espace. Il permet de transporter facilement ces images vers des serveurs et des environnements de développement à l'aide d'un registre. Et ces images peuvent être exécutées en tant que conteneurs dans n'importe quel environnement et n'importe quel serveur, presque à l'identique. Cela inclut l'ordinateur portable du développeur ainsi que l'environnement de production. Encore une fois, quelque chose qui était beaucoup plus difficile à faire avec les machines virtuelles et / ou avec les versions du logiciel basées sur des packages. Le fait de tester la même image sur l'ordinateur portable du développeur et de conserver les mêmes bits et octets en production supprime beaucoup de "

En parlant spécifiquement de la partie de conditionnement d'image de Docker, pas de l'exécution du conteneur, il y a quelques bits mineurs. Le plus important est qu'une image Docker ressemble plus à un chroot, ce qui signifie que vous ne pouvez pas accidentellement dépendre de l'état du système partagé car chaque fichier utilisé doit être explicitement inclus dans l'image tandis qu'un package système peut récupérer des liens dynamiques que vous n'avez pas attendez-vous ou obtenez plus entrelacé avec d'autres packages. Cela peut aboutir à des dépendances C complexes chargées à votre insu, par exemple OpenSSL. De plus, l'utilisation des paquets deb ne supprime pas les bits partagés dans le système de stockage de Docker. Pour certains, cela peut être une bonne chose, de meilleures performances d'E / S et moins de pièces mobiles, mais pour d'autres, cela peut être un problème.