Les avantages en termes de développement de l’utilisation de Docker avec Java comparés à d’autres langages plus proches des fichiers binaires Unix sont-ils compromis?

J'ai eu un ami qui a dit:

Docker est incroyable. Vous pouvez l'utiliser pour répliquer la production et tous ses défauts sur votre ordinateur local. Ensuite , vous pouvez déployer cette ligne droite par exemple à travers toute la mise en scène des flux de travail super rapide .

Or, cela serait vrai si les développeurs écrivaient Ruby, PHP ou Go , où il existait 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, assurant la cohérence des opérations quel que soit le système d'exploitation sous-jacent.

Dans ce cas, les avantages de l'exécution de Docker pour les développeurs localement afin de répliquer l'environnement de production sont niés . (Comparé à Ruby, PHP ou Go).

Je suis ouvert à la discussion à ce sujet et je souhaite entendre un point de vue dissident (avec des preuves).

Les avantages en termes de développement de l’utilisation de Docker avec Java comparés à d’autres langages plus proches des fichiers binaires Unix sont-ils compromis?

Pas du tout.

Imaginez que vous exécutiez la version 1.8.0 de Java sur votre ordinateur de développement et sur le serveur. En passant, vous travaillez simultanément sur deux projets, tous deux utilisant Java.

Un jour, un bogue est détecté dans la machine virtuelle Java et les serveurs sur lesquels est exécuté le premier projet sur lequel vous travaillez sont migrés vers la version 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 ne souhaitent peut-être pas passer à la version 1.8.1.

Maintenant, au moins pour l’un des projets, vous exécutez une version différente de Java.

Cela ne vous dérangera 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 ordinateur local, ce qui permet insectes à se glisser po

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 diffèrent de ceux de la production, vous vous exposez à un risque d'écriture de code qui échouera en production. Au lieu de prendre ce risque, vous pouvez utiliser la virtualisation ou Docker, avec une perte de productivité minime voire nulle.

Vous ne faites que rarement déployer une "application Java". Votre application java comporte de nombreux programmes d'assistance différents. Nous utilisons Apache HTTPD, Apache Tomcat, ActiveMQ pour la messagerie, un FTP Deamon, MySQL et une poignée de services personnalisés à intégrer à des programmes qui ne fonctionnent pas directement avec Java.

Cela ne va même pas dans le logiciel de développement qui va avec - éclipse, fourmi, adobe flex, groovy, firefox et subversion (j'en saute assez)

La configuration d’un nouveau poste de travail prend entre une journée et une semaine. Nous avons envisagé de passer à Docker pour simplifier ce problème. Ce serait étonnant si nous pouvions déployer de manière fiable un nouveau poste de travail en quelques heures.

Sans oublier le fait que lorsque nous déployons, nous devons maintenir plus de 20 serveurs; Docker commence à ressembler à une très bonne affaire!

(20 semble assez pénible pour une application qui ne s'exécute que sur un serveur à la fois ... mais multipliez ce serveur par des clusters (x2), des tests / de la staging / des prod (x3), des internes / externes (x2) et des sites principaux / backup site (x2) et vous y montez 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, ce qui incite les utilisateurs à créer un conteneur docker à partir du environnement de développement.

Il y a deux points à répondre ici:

Un: il doit y avoir un meilleur moyen , et il y a: vous pouvez construire des conteneurs de docker plus petits (et plus efficaces) en utilisant uniquement l'environnement d'installation, ce qui offre des avantages similaires à ceux de Golang avec environnement par rapport à Golang -binaires conteneurs. Dans le cas de Java, vous pouvez créer un gros fichier jar ou une application installable contenant tous les fichiers jar 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 construction (et vous pouvez utiliser C ++ avec des liens statiques produisant presque le même effet).

Deux: pour quoi avez-vous besoin de docker? En Java, vous pouvez faire beaucoup de séparation entre différents composants en utilisant des chargeurs de classes, mais l’essentiel est ce qui est autour de l’application Java. Aucune application Java ne s'exécute par elle-même - si elle ne s'exécute pas dans le menu fixe, elle devrait généralement être supervisée par supervisord, systemd ou autres. Entrez dans le nuage Kubernetes, Marathon ou Docker, qui utilise l'abstraction de conteneur pour virtualiser non pas l'hôte lui-même, mais virtualise l'ensemble du réseau de sorte que vous ne puissiez déployer que des conteneurs et qu'ils s'exécutent sur un hôte aléatoire.

Les microservices fonctionnent généralement sur des nuages ​​basés sur un menu fixe, car ils vous permettent de traiter vos hôtes du menu fixe comme du bétail, et non comme des animaux domestiques, et de la même manière avec les applications dockerisées. Bien sûr, cette abstraction présente des fuites dès que vous montez des volumes d’hôte sur le menu fixe et que vous devez exécuter des conteneurs de menu fixe sur l’hôte qui possède ces volumes. Certaines personnes parviennent même à éviter cela.

C'est une très bonne question, mais après avoir travaillé avec Docker, je la renversais:

Les avantages de la machine virtuelle Java sont-ils annulés par la conteneurisation (par exemple, Docker)?

Les conteneurs remettent vraiment en cause un grand nombre de mes hypothèses de développement découlant 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 devez le rendre configurable. Mais si vous ciblez un conteneur, est-ce vraiment le cas? Lorsque vous construisez le conteneur, vous lui indiquez quelles sont les structures de répertoires. Vous configurez le chemin là-bas. 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 la partie ancienne du segment de mémoire atteignait un pourcentage seuil, elle s'arrêtait d'elle-même. Docker (mode essaim) en créerait alors un nouveau. Pour l’essentiel, cela éliminait le besoin de cycles GC majeurs dans la JVM et permettait à docker de les gérer. Cela n'a pas fonctionné aussi bien que j'aurais pu l'espérer (les clients ont constaté l'impact de la fermeture), mais il était suffisamment fonctionnel pour faire une démonstration en direct devant un public.

Vous devriez vraiment juste essayer des conteneurs si vous êtes curieux. C'est vraiment une technologie perturbatrice et vous devrez vous y attaquer. Docker est un excellent endroit pour commencer, mais il existe au moins une autre alternative viable qui convient à tout le monde, l’OMI.