Les avantages de développement de l'utilisation de Docker sont-ils annulés lors de l'utilisation de Java par rapport à d'autres langages plus proches des binaires Unix?
J'avais un ami qui m'a dit:
Docker est incroyable. Vous pouvez l'utiliser pour répliquer la production et toutes ses bizarreries sur votre machine locale. Ensuite, vous pouvez déployer cette instance directement à travers tous les workflows de mise en scène super - rapide .
Maintenant, cela serait vrai si les développeurs écrivaient Ruby, PHP ou Go - où il y avait un lien binaire directionnel vers le système d'exploitation.
Mais lors de l'utilisation de Java - il existe déjà une couche virtuelle entre le système d'exploitation et le langage, ce qui rend la cohérence de fonctionnement quel que soit le système d'exploitation sous-jacent.
Sans doute, dans ce cas, les avantages de l'exécution de Docker pour les développeurs localement pour répliquer l'environnement de production sont niés . (Par rapport à Ruby, PHP ou Go).
Je suis ouvert à la discussion à ce sujet et je suis impatient d'entendre un point de vue dissident (avec des preuves).
Les avantages de développement de l'utilisation de Docker sont-ils annulés lors de l'utilisation de Java par rapport à d'autres langages plus proches des binaires Unix?
Pas du tout.
Imaginez que vous exécutez la version 1.8.0 de Java à la fois sur votre machine de développement et sur le serveur. Soit dit en passant, vous travaillez simultanément sur deux projets, tous deux utilisant Java.
Un jour, un bogue est trouvé dans JVM et les serveurs qui exécutent le premier projet sur lequel vous travaillez sont migrés vers 1.8.1. Soit dit en passant, les serveurs exécutant le deuxième projet ne sont pas affectés par le bogue et sont gérés par une autre équipe d'administrateurs système, qui peuvent ne pas vouloir mettre à jour vers 1.8.1.
Maintenant, au moins pour l'un des projets, vous exécutez une version différente de Java.
Cela ne vous gênera peut-être pas trop (jusqu'à ce qu'un serveur migre vers la version 1.9, tandis que l'autre conserve l'ancienne version), mais cela signifierait que vous ne répliquez plus l'environnement de production sur votre machine locale, ce qui permet à de minuscules des bugs pour s'introduire.
Si vous imaginez que votre système de fichiers, vos dépendances, vos paramètres de sécurité, votre configuration locale et votre version de Linux elle-même diffèrent de la production, vous vous exposez au risque d'écrire du code qui échouera en production. Au lieu de prendre ce risque, vous pourriez utiliser la virtualisation ou Docker, avec une perte de productivité minime à nulle.
Vous déployez rarement une "application Java". Votre application Java comprend de nombreux programmes de support différents. Nous utilisons Apache HTTPD, Apache Tomcat, ActiveMQ pour la messagerie, un FTP Deamon, MySQL et une poignée de services personnalisés pour intégrer des programmes qui ne fonctionne pas directement avec Java.
Cela ne va même pas dans le logiciel de développement qui l'accompagne - Eclipse, ant, Adobe flex, groovy, firefox et Subversion (j'en saute pas mal)
Il faut entre une journée et une semaine pour configurer un nouveau poste de travail - nous avons discuté du passage à Docker pour simplifier ce problème. Ce serait incroyable si nous pouvions déployer de manière fiable un nouveau poste de travail en quelques heures.
Sans parler du fait que lorsque nous déployons, nous devons maintenir plus de - 20 serveurs; Docker commence à ressembler à une assez bonne affaire!
(20 semble assez pénible pour une application qui ne fonctionne que sur un seul serveur à la fois ... mais multipliez ce serveur par des clusters (x2), test/staging/prod (x3), Internal/External (x2) et site principal/site de sauvegarde (x2) et vous y arriverez assez rapidement)
Cette question serait également pertinente pour golang, où vous pouvez simplement extraire des binaires liés statiquement et les exécuter quelque part, contrairement à Python ou C++ où vous avez généralement un grand nombre de bibliothèques liées qui conduisent les gens pour simplement construire un conteneur Docker à partir de l'environnement de développement.
Il y a deux points à répondre ici:
Un: il doit être un meilleur moyen, et il y a: vous pouvez construire des conteneurs docker plus petits (et plus efficaces) en utilisant uniquement l'environnement d'installation, ce qui conduit à des avantages similaires à ceux de Golang- avec-environnement par rapport aux conteneurs de Golang-juste-binaires. Dans le cas de Java, vous pouvez créer un gros pot ou une application installable qui contient tous les pots de la bibliothèque et un script Shell; dans le cas de Python, vous pouvez utiliser auditwheel pour créer des roues autonomes indépendantes de l'environnement de génération (et vous pouvez utiliser C++ avec une liaison statique pour presque le même effet).
Deux: pour quoi avez-vous besoin de docker? Dans Java land, vous pouvez faire beaucoup de séparation entre les différents composants en utilisant des chargeurs de classe, mais le point principal est ce que est autour de l'application Java. Non Java s'exécute d'elle-même - si elle ne s'exécute pas dans Docker, elle devrait généralement être supervisée par Supervisord ou Systemd). ou similaires. Entrez dans le cloud Kubernetes, Marathon ou Docker, qui utilise l'abstraction de conteneur pour virtualiser non pas l'hôte lui-même, mais virtualise en fait l'ensemble du réseau de sorte que vous pouvez simplement déployer des conteneurs et qu'ils s'exécutent sur un hôte aléatoire.
Les microservices s'exécutent généralement sur des clouds basés sur des dockers car ils vous permettent de traiter vos hôtes dockers comme du bétail, pas comme des animaux de compagnie, et de la même manière avec les applications dockées. Bien sûr, cette abstraction devient fuyante dès que vous montez des volumes Host sur Docker et que vous devez exécuter des conteneurs Docker sur l'hôte qui a ces volumes. Certaines personnes s'en sortent même.
C'est une très bonne question mais après avoir travaillé avec Docker, je la retournerais:
Les avantages de la JVM sont-ils annulés par la conteneurisation (par exemple Docker)?
Les conteneurs remettent vraiment en question bon nombre des hypothèses que j'ai sur le développement qui découlent de mon expérience. Par exemple, si quelqu'un codait en dur un chemin d'accès à un fichier de ressources dans une application, de nombreux développeurs expérimentés sauraient que cela pose problème et vous devriez le rendre configurable. Mais si vous visez un conteneur, est-ce vraiment le cas? Lorsque vous créez le conteneur, vous lui dites quelles sont les structures de répertoires. Vous y configurez le chemin. Alors, devriez-vous le configurer deux fois? Quel est l'avantage? Si vous ne les faites pas correspondre, cela ne fonctionnera pas alors ... SEC?
J'ai récemment créé un prototype d'application avec Java et Docker qui surveillait essentiellement les événements GC et lorsque l'ancienne partie du tas atteignait un pourcentage seuil, elle s'arrêtait. Docker (mode essaimage) puis en lancer un nouveau. Essentiellement, cela a éliminé le besoin de cycles GC majeurs dans la JVM et a laissé Docker les gérer. Cela n'a pas fonctionné aussi bien que je l'aurais espéré (les clients ont vu un certain impact de l'arrêt), mais il était suffisamment fonctionnel pour faire une démo en direct à une foule.
Vous devriez vraiment essayer les conteneurs si vous êtes curieux. C'est vraiment une technologie perturbatrice et vous devrez la maîtriser. Docker est un excellent point de départ, mais il existe au moins une autre alternative viable qui convient à tout le monde, l'OMI.