Introduction à la GraalVM

[Loïc Lefèvre]

Hello,

une vidéo assez sympa sur un channel Youtube! qui l'est tout autant :)

Turning the JVM into a Polyglot VM with Graal

Enjoy

Loïc

[Laurent Caillette]

Salut Loïc,

Chouette présentation. Je résume pour les flemmards : le projet GraalVM fournit des primitives pour intégrer des langages "exotiques" à la JVM, de façon à en faire du bytecode qui bénéficie des mêmes optimisations que du bytecode Java standard. Il devient possible d'appeler d'entremêler des fonctions JRuby, JavaScript et Java sans dégradation notable des performances par rapport à du pur Java. C'est techniquement très impressionnant. 

Ça y est j'ai déjà épuisé le quota de gentillesses ? La présentation repose sur cet argument : "Si les gens utilisent différents langages sur le même projet c'est qu'ils ont de bonnes raisons." Euh, ça ressemble à un renoncement à comprendre le vrai besoin. Moins on a de langages sur le même projet mieux on se porte. Ne serait-ce que pour minimiser la dépense d'énergie mentale pour effectuer les changements de contexte. Et je ne parle pas des problèmes d'intéropérabilité idiomatique etc. 

En piratant le capteur d'ultra-sons de la machine à café j'ai réussi à capter cette discussion ultra-confidentielle chez Oracle :

--- Oh les mecs on est pas en train de se faire doubler par tous les acteurs du marché sur les trucs pointus ? Là si y'avait pas Java on n'aurait plus que des vieux trucs. Et encore je dis ça mais la JVM c'est un projet d'il y a 20 ans.

--- Ouais mais se lancer dans un projet de R&D aussi ambitieux que Java c'est trop risqué. De toutes façons c'est le yacht volant de Larry qui pompe tout le budget.

--- C'est les boules enfin toutes les Fortune 500 sont en train de migrer vers PHP-MySQL ou du Node.js avec Redis.

--- Eh ben y'a qu'à les faire fonctionner dans la JVM ! Comme ça on pourra dire qu'on est toujours à la pointe !

Ce que les mecs oublient de mentionner c'est qu'un langage c'est aussi un environnement de développement. Avec NetBeans l'offre d'Oracle est remarquablement stable depuis plus d'une décennie, dans le registre de l'électoencéphalogramme plat. Et si on a plusieurs langages, c'est aussi parce qu'ils permettent certains trucs impossibles sur une JVM, notamment tourner sur iOS. 

Concernant le polyglottisme, si on veut voir quelque chose de super-puissant il vaut mieux s'interesser à ce que devient Kotlin. Non seulement JetBrains continuent d'investir dans le transpileur JavaScript, mais il y a également un projet pour compiler Kotlin vers du code natif, y compris iOS. Concernant l'intéropérabilité avec Java c'est une préoccupation majeure depuis le début, aujourd'hui on arrive à quelque chose de très propre, et concernant l'intégration à un IDE avec IntelliJ c'est du cousu-main.

Je ne veux pas dire que la JVM est obsolète. C'est un morceau de code super-impressionnant, qui rend des services incommensurables. Je ne veux pas dire que GraalVM c'est pas bien. Je veux juste dire qu'Oracle est à la rue quand il s'agit de trouver le truc dont on besoin les développeurs. Le mec qui me colle du JRuby dans mon appli je lui défonce la tête à coup de concombre.

Allez on va finir sur une note encourageante. Au catalogue d'Oracle on trouve de gros serveurs, des JVM d'excellente facture, une solution de virtualisation fantastique (VirtualBox), plus de la compartimentation (Solaris Containers) avec un système de fichiers de capacité quasi-illimitée, supportant la prise d'instantanés (ZFS). Oh, j'allais oublier l'instrumentation de code en temps réel (DTrace). Et qu'est-ce que ça donnerait si on mélangeait tout ça ? Autrement dit, quand est-ce qu'on a une solution pour enregistrer //toutes// les transitions d'état d'une JVM en prod ? Et tout rejouer en pas-à-pas, en cherchant éventuellement certains motifs correspondant à des problèmes connus. La preuve que je ne suis pas le seul à rêver :

https://github.com/panda-re/panda

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "techos".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse techos+unsubscribe@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse tec...@googlegroups.com.
Visitez ce groupe à l'adresse https://groups.google.com/group/techos.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

[Henri Tremblay]

Je ne suis pas vraiment d'accord avec l'analyse. Pour en avoir discuter pas mal avec des gars non Oracle qui utilisent Graal.

Donc:

• En fait, ça a pour but de remplacer le compilateur java actuel. Parce que c'est le bordel, surtout depuis les lambdas.
• Et dans le détour, c'est super pratique pour faire n'importe quel langage incluant un DSL maison très performant
• Oracle veut tout le monde sur la JVM. C'est ce qu'ils vendent. Donc plus il y a de langages performant dessus, mieux c'est
• Et oui, mettre plein de langage c'est débile. Les exceptions ça peut être Javascript parce que tu veux réutiliser la même chose sur ton navigateur. Ou que la librairie qui t'arrange est dans un autre langage. Ou un DSL. Mais dire "Je vais mettre du scala parce que c'est beaucoup plus expressif pour faire des react", c'est débile parce que ça change pas grand chose à grand chose.

Kotlin c'est en effet assez hot. C'est assez proche de ce que j'aurai fait. Un Java mais avec quelques tweaks au lieu de révolutionner la galaxie.

Le profiling avec des métriques systèmes et de l'heuristique s'en vient. Tu as JMH+perfasm (compteurs systèmes), JClarity (compteurs systèmes et heuristiques et machine learning) et XRebel (heuristiques et système expert, mais instrumenté).

[Laurent Caillette]

Salut Henri,

Non décidément en tant qu'utilisateur final, GraalVM ne me remue pas trop. C'est super que ça soit l'occasion de remettre à neuf le compilateur mais si ça se passe bien je ne verrai pas trop la différence. Pour le reste on dit à peu près la même chose.

Tu mentionnes JMH, JClarity et XRebel. Ce sont des outils de mesures de performance à l'exécution. Moi ce que je veux c'est enregistrer toutes les instructions exécutées par le processeur, pour ensuite faire du minage de données sur les différents états. Par exemple, tu peux détecter des problèmes de concurrence d'accès par de l'analyse statique, mais on connaît tous les limites d'une telle approche. Tu peux dire que l'accès à telle et telle variable doit être synchronisée sur tel verrou, mais si tu laisses "fuir" les références l'analyse statique devient aveugle. Rust résoud le problème pour qui est prêt à se faire greffer un nouveau cerveau. Une autre solution c'est l'analyse dynamique. Là tu peux détecter des motifs d'accès concurrents répertoriés comme dangereux. C'est une approche encore peu répandue donc c'est normal que mon exemple ne soit pas très parlant. De cette façon, des mecs ont réussi à détecter des accès mémoire foireux qui entraînaient des failles de sécurité exploitables (dans la paravirtualisation des périphériques de Xen par exemple). 

Évidemment l'approche consistant à tout enregistrer génère un coût énorme. Par exemple il faut 5 heures pour démarrer un Linux avec Panda qui est basé sur QEMU. Mais ça c'est sans aucune accélération matérielle. Maintenant imagine un enregistreur en temps réel sans dégradation de performances, grâce à des extensions matérielles qui déversent toutes les opérations enregistrées vers des serveurs qui vont analyser ces données pour te trouver les problèmes avant qu'ils n'explosent à la face de l'utilisateur. Un slogan légèrement tendancieux ça serait "Le data mining va enfin servir à quelque chose."

Bon, pour ce qui est de supporter plusieurs langages dans la JVM, les mecs d'Azul ont trouvé l'idée qui tue : LLVM.

Le communiqué officiel d'Azul : "Azul Systems seizes Java runtime performance lead with Falcon, a new Just-in-Time compiler based on LLVM"

https://www.azul.com/press_release/falcon-jit-compiler/

Pour une version abrégée : "Azul introduces LLVM compiler to Java runtime"

http://www.javaworld.com/article/3193874/java-platform/azul-introduces-llvm-compiler-to-java-runtime.html

Pour ceux qui auraient réussi l'exploit de ne jamais entendre parler de LLVM, c'est une infrastructure de compilation qui spécifie notamment un code machine "pivot" compilable et optimisable pour différentes architectures. Tu écris un compilo qui crache du bytecode LLVM, et tu bénéficies automatiquement des meilleures optimisations écrites par les différents fabricants de processeurs. Les langages récents comme Rust et Swift reposent sur LLVM. Clang, le compilateur `C++`, supporte également LLVM. 

J'extrapole, mais un intérêt évident de LLVM c'est de fournir à des langages qui n'en sont pas dotés la vérification de bytecode et le ramasse-miettes de Java. Par contre à aucun moment le communiquée d'Azul ne mentionne l'intéropérabilité entre langages ; soit ils considèrent le point comme évident, soit ils le considèrent comme trop épineux pour mériter une mention.

Même si le support de LLVM dans la JVM ne changera rien à ma vie de développeur, je trouve l'approche d'Azul plus impressionnante car plus aggressive. Ils font évoluer leur produit pour aller croquer de plus grands territoires chez les voisins. Swift sur la JVM sans réécrire le compilateur, c'est brillant.

[Loïc Lefèvre]

Laurent,

voici un peu plus de doc sur le projet GraalVM :

http://www.oracle.com/technetwork/oracle-labs/program-languages/overview/index.html

Donc la GraalVM utilise LLVM (super projet) et l'augmente.

et son associé Truffle (au-dessus de SuLong notamment) :

https://labs.oracle.com/pls/apex/f?p=labs:49:::::P49_PROJECT_ID:130

pour intégrer de nouveaux languages... le COBOL par exemple.......... qui pourrait invoquer des scripts R...............................

Bonne soirée

Loïc

[Laurent Caillette]

Colossal ! Ça donne encore quelques longueurs d'avance à la JVM d'Oracle, alors que des alternatives commençaient à montrer le bout du nez, comme  PNaCl puis WebASM. Ce qui est complètement fou c'est que la JVM, qui est sur le papier le truc le plus approprié pour confiner du code, se soit fait sortir par d'autres trucs moins pertinents comme la VM de JavaScript (dans les navigateurs) ou LXC (LinuX Containers, qui motorise Docker). Est-ce que ça sera l'occasion pour Oracle de reprendre le dessus sur le sujet absolument brûlant des conteneurs ? (Oui je sais Solaris Containers est génial, mais Solaris tout le monde s'en fout notamment depuis l'abandon d'OpenSolaris.) 

[Henri Tremblay]

Aïe aïe aïe. Je ne vois pas du tout le rapport entre les containeurs et LLVM. Et de mémoire, Docker n'utilise plus LXC.

Oracle veut faire du cloud. C'est un échec total pour l'instant mais ils veulent faire du cloud. Ils ont maintenant des images officielles Docker et la license Java devrait s'éclairer un jour. Ils ne vont pas sortir une alternative à Docker ou se sera voué à l'échec.

Ensuite, tu réfléchis trop. Bozo le clown qui fait du nodejs, il n'a pas réfléchit plus que ça. Soit c'est un dev front qui veut faire du back, c'est un gars qui trouve ça hype. La VM, il s'en fout un peu. S'il ne s'en foutait pas, personne n'aurait fait de Ruby. Au niveau NodeJS, depuis typescript, ça pourrait quasiment ressembler à quelque chose. 

Par contre, Oracle aimerait bien récupérer tous les langages sur la JVM et vendre des licenses. Et les grosses entreprises aiment bien avoir des license. Donc les hipsters de dev vont vouloir faire du node et leur pas drôle de prod va la faire tourner sur Java. JRuby, Jython, Javascript (Nashorn) et patata.

Mais je te confirme, Graal c'est pas pour les end-users. C'est pour Oracle et les fabricants de langage. 

[Laurent Caillette]

Ouaaaais là j'ai bien peur que tu aies raison : si les gens comprenaient ce qu'ils font, Ruby et d'autres trucs à la mode auraient conservé leur statut de curiosité expérimentale. 

Le rapport entre Docker et la JVM ? 

--- Docker est un outil pour confiner un environnement d'exécution avec ses dépendances. Si les dépendances à l'exécution n'avaient débouché sur un bordel colossal, on se passerait probablement de Docker. Docker c'est la meta-distro Linux qui trivialise la notion de distro. 

--- La JVM enferme toutes les dépendances dans un seul processus. Tu mets tout ce que tu veux dans ton classpath et tu as la paix. La JVM se débrouille avec le système sous-jacent.

Donc cette histoire de dépendances constitue un point commun assez frappant. 

Dans ma vie à moi j'ai du mal à trouver de l'intérêt à Docker parce que je fais déjà tout dans une JVM. Ma pile serveur HTTP-serveur d'application-base de données tourne dans une seule JVM. Je démarre la totale dans un test JUnit en moins d'une seconde, et je déploie un zip avec tous les jars, qui fonctionne pareil sur macOS et Debian. 

Évidemment si tu déploies plein d'exécutables différents tu es plus réceptif à l'approche de Docker. 

Après j'ai l'impression que tu as plus de visibilité sur ce qui se passe dans une JVM que dans des processus gérés par Docker. Je ne maîtrise pas DTrace, je ne maîtrise pas plein d'outils système, donc peut-être que j'ai faux là-dessus. Mais les belles stacktraces de Java, les sondes JMX et tout ça, c'est gratuit et disponible immédiatement. Donc je tiens pour acquis que faire tourner du code dans une JVM c'est mieux.

Le support de LLVM répond à l'objection "Mais il y a trop de bibliothèques natives dont tu ne peux pas te passer, tu vas pas tout réécrire en Java." 

Tout cela nous donne les contours d'une chaîne d'outils pour déployer du code qui s'exécute dans des JVM, avec plus ou moins la même granularité que les images Docker, et en résolvant plus de problèmes que Docker. Je suis d'accord il ne faut pas présenter ça comme une alternative à Docker. Le mec qui a inventé Docker n'a jamais prétendu inventer une alternative à VMWare. Il a voulu résoudre un problème hors de portée de VMWare. 

[Henri Tremblay]

Hum. Je suis encore à moitié mêle.

Docker est juste un container linux. Dedans tu mets une JVM avec ton application. Donc tu peux avoir du JMX et des stacktraces.

Docker a deux avantages:

1- Tu as une isolation système moins couteuse que de spinner une VM. C'est d'ailleurs ce qui a amené à l'invention de docker (et LXC). C'est donc une alternative à VMWare en effet. Pour certains cas d'utilisation.

2- Le provisionning est instantané et tu démarres le containeur où tu veux. Un VM, tu peux faire une image, mais elle est propriétaire et c'est quand même long à partir. Et sinon, chef, c'est long et désagréable.

La JVM devait être multi-tenancy. Mais c'est un échec. Les modules de Java 9 ne vont pas amélioré. C'est pas le but. OSGi le permet mais c'est trop compliqué pour le commun des mortels. Faut être obligé.

Ensuite, dans ton cas, tu es une exception. Mais précédent SI c'était 1000 VMs contenant un peu tout et n'importe quoi. J'aurai pu faire un peu de ménage mais en gros, tout sert. Juste pour avoir un environnement de test c'est un joyeux party. Docker peut beaucoup aider ça.

[Laurent Caillette]

Oui pour l'état des lieux je suis d'accord. On empile des composants avec des dépendances pas très claires et on emballe ça dans du Docker. Donc si tu veux monter un environnement de test tu te trimballes plein de trucs système, et le moindre test devient un test d'intégration. C'est juste se fabriquer des problèmes. 

(Parenthèse : Docker est un super-produit qui rend facile les trucs que je veux éviter, et qui n'a pas l'air d'aider pour le reste. Par exemple au niveau sécurité c'est un peu flippant d'entendre les auteurs dire que non le confinement n'est pas supposé être étanche, tout en donnant accès à un référentiel où on trouve tout et n'importe quoi.)

Effectivement il y a déjà eu cette idée de tout mettre dans la même boîte avec OSGI comme solution officielle, donc officiellement il ne reste plus qu'à se pendre. 

Mais alors pourquoi exécuter du code LLVM dans la JVM ? Juste pour diminuer l'utilisation de JNI ?

[Philippe Kernévez]

En plus du runtime tu as tout le tooling. Sur mon projet précédent on faisait de l'ansible, avec docker une ligne de commande et tu te retrouves dans le container (tout neuf) qui va bien avec les point de montage sur ton source : tu as la double vu sur ton code avec le volume : depuis ton host ou depuis ton shell dans ton container.

L'upgrade d'outil devient trivial pour tout le reste de l'équipe.

Tu retrouves cette approche avec GitLabCI : tu n'installes plus les outils sur le serveur (avec les pb de conflit de version entre projet) tu indiques le container à utiliser pour faire ton étape de build.

Pour des tests de recette automatisées (pas les tests unitaires) ça devient super facile de repartir d'une base vierge à chaque run, sans avoir besoin d'Oracle et ses snapshot.

Je pense que Docker est l'outil qui a le plus changé ma vie de dev (avec Git) dans les 10 dernières années.

Philippe Kernévez



Directeur technique (Suisse),
pker...@octo.com
+41 79 888 33 32

Retrouvez OCTO sur OCTO Talk : http://blog.octo.com
OCTO Technology http://www.octo.ch

[Henri Tremblay]

Je suis d'accord avec ça.

Par exemple, j'ai fait une application démo. Je dis au sales d'installer docker et en 5 minutes il a lancé l'application et sa base de données dans deux containers. Si je veux lancer elasticsearch, en 1 minute j'en ai un qui tourne. C'est magique.

En pratique, je recommande de faire des containers même pour en avoir un seul par VM. Parce que c'est plus simple à déployer que de monter une VM. Donc la sécurité je m'en fous pas mal.

LLVM sur JVM l'intérêt c'est la JVM. C'est extrêmement optimal en terme d'optimisation runtime. C'est donc une belle place pour faire tourner n'importe quoi. Le JNI est la pire chose du monde. Et peut être remplacer par le truc qu'ils ont utiliser pour JRuby (je sais plus quoi).

[Laurent Caillette]

Salut Kernie,

Oui dans le scénario que tu décris Docker est fantastique. J'utilise la même approche avec VirtualBox et les SharedFolders, et pareil je déploie avec Ansible sur des machines virtuelles super-propres. À un moment j'ai regardé le passage à Docker. Le but c'était de migrer l'environnement de dev sur macOS vers Ubuntu, avec une période de transition utilisant Ubuntu dans une VirtualBox. C'est Docker qui aurait hébergé les environnements de déploiement virtualisés (vu que VirtualBox ne tourne pas dans VirtualBox). Seul problème, mon script de démarrage crée une IP pour le démon de l'appli, ainsi que quelques règles de port-forwarding. Et ça Docker n'aime pas trop car il ne virtualise pas la couche réseau (alternative : laisser au système confiné des droits sur le système hôte, ce qui n'est pas envisagé). 

Je donne complètement raison à Henri sur la facilité de création d'un conteneur Docker. J'ai un script qui part de zéro (téléchargement de l'ISO Debian) et qui termine avec une image clonable, les VirtualBox Guest Additions, et une clé SSH déployée. Eh ben c'est pas trivial à mettre au point. Mais une fois que j'ai ça je peux tester la conf réseau dans une VM qui ressemble suffisamment à la prod, sans craindre de me couper l'accès SSH. 

Je ne peux pas dire que Docker ce n'est pas bien, mais ça tombe toujours à côté de mes besoins qui ne me semblent pourtant pas extravagants. C'est illustré par un autre cas où l'on voit clairement que le déploiement directement sur JVM et en passant par Docker peuvent être concurrents. 

Pour surveiller la production j'utilise une application qui tourne dans Google AppEngine. AppEngine est gratuit en-dessous de certains volumes. Tu balances une espèce de `.war` dedans et ça "juste marche". Pour les fonctionnalités autre que celles des Servlets tu tapes dans des API propriétaires. Google gère tout le cycle de vie de la JVM, te garantit la création d'instances à la demande en fonction de la montée en charge, ainsi que la persistance redondée, les files de messages etc. Accessoirement le kit de développement reproduit quelques-uns des comportements d'AppEngine. Donc c'est la joie, sauf qu'AppEngine ne supporte pas `Java 8` et ça pose plein de problèmes énervants. 

Pour avoir droit à `Java 8` il faut passer à GKE (Google Container Engine) qui prend des images Docker. Avec une petite conf tu t'en tires à `$6/mois`, c'est vraiment correct. Et dans Docker tu peux déployer tout ce que tu veux dont un `JRE 8` et du Netty. Donc je me suis réjoui de découvrir Docker et j'ai lu de la doc sur le déploiement dans GKE.

Ce qui m'a fait penser que Docker est "juste" une façon de réparer l'horrible bordel des dépendances dans les distros, c'est un paragraphe de la doc conseillant de déployer une image Docker par service, et indiquant clairement que faire tourner un démon SSH dans une image Docker c'est probablement le symptôme d'une mauvaise utilisation ou d'une utilisation détournée. 

Maintenant tu regardes le poids d'une image Docker minimale avec Alpine Linux et un JRE (``anapsix/alpine-java @8_server-jre_unlimited``) : `124 Mo`. Il doit rester de gros bouts du JDK. Mes jars font moins de `10 Mo`. Peut-être qu'en bricolant l'image d'Anapsix je m'en tire à `60 Mo`, donc un surcoût d'au moins `600 %` pour les temps de création et de téléchargement, bien joué Docker ! Ça c'est du déploiement léger ! 

Il vaut mieux créer son image Docker, la déployer une fois, et tout faire ensuite par SSH. Et dans ce cas la valeur ajoutée de Docker est juste négative à cause du surcroît de boulot. AppEngine fournit une bien meilleure granularité pour le déploiement, plus des services de stats, de journaux d'exécution etc.

Oui AppEngine est en train de mourir mais il y a d'autres raisons que la concurrence de Docker : les API plutôt énervantes et le kit de développement pas très sec. En tous cas AppEngine montre bien que le déploiement directement dans une JVM est une approche viable par rapport à Docker, et qui peut s'avérer plus performante.

[Henri Tremblay]

Là on change de sujet :-)

GAE supporte maintenant Java 8 en beta. Je suis un des testeurs. Tu peux demander un whitelisting de ton application. http://glaforge.appspot.com/article/testing-java-8-snippets-on-the-new-app-engine-java-8-runtime

Ensuite, avec Java 9 (mais donc pas sur GAE), tu devrais pouvoir avoir une image minuscule. Genre 10 Mo.

Normalement en Docker, tu n'as qu'un PID 1 qui tourne. Sauf si tu triches avec par exemple systemd. Tu n'as pas besoin de SSHD car tu peux te connecter à l'image avec docker exec. La contrainte d'un seul processus peut être tannante dans certains cas. C'est pour ça que kubernetes a des pods. C'est une super idée les pods mais kubernetes c'est un autre paradigme. 

Je suis d'accord avec toi, si tu as juste une petite app, c'est pas mal plus simple de la déployer sur GAE. En plus tu finis avec ton contenu statique sur le CDN de google. Donc tout as fait d'accord.

[Laurent Caillette]

Est-ce qu'on a vraiment changé de sujet ? Imagine un GAE amélioré qui prenne un überjar, avec dedans des exécutables compilés grâce à LLVM. Genre OpenSSH, LaTeX... Pour LaTeX il y a peut-être déjà moyen de le faire tourner dans une JVM car il a déjà été recompilé pour du JavaScript grâce à Emscripten (basé lui aussi sur LLVM) mais au revoir les perfs. Avec cette façon de déployer des binaires tu réduis considérablement l'intérêt de Docker, et tu augmentes la sécurité d'exécution (le Heartbleed n'est pas possible dans une JVM). Donc je maintiens que LLVM dans la JVM offre de nouvelles possibilités de déploiement, y compris dans le cloud, mais maintenant c'est peut-être plus clair.

Après, un gouglage rapide me donne l'impression qu'il y faut passer par un pod Kubernetes pour ouvrir une console sur son conteneur. Si ça peut m'éviter d'installer un sshd je prends merci !

[Philippe Kernévez]

>Maintenant tu regardes le poids d'une image Docker minimale avec Alpine Linux et un JRE (``anapsix/alpine-java @8_server-jre_unlimited``) : `124 Mo`. Il doit rester de gros bouts du JDK. Mes jars font moins de `10 Mo`. Peut-être qu'en bricolant l'image d'Anapsix je m'en tire à `60 Mo`, donc un surcoût d'au moins `600 %` pour les temps de création et de téléchargement, bien joué Docker ! Ça c'est du déploiement léger ! 

Non tu ne payes le coup que la première fois. Ensuite tes images s'appuyeront toujours sur la même couche Alpine et n'enverrons que la couche de l'oignon qui contient ton 'war'.

Dans les fait tant pis pour les 120 Mo (qui ne transit pas par ta bande passante mais dans le cloud) et tu continue d'envoyer uniquement tes 10Mo.

L'approche docker te permet d'être vraiment indépendant de ton fournisseur de cloud pour le coup. Si demain tu trouve plus intéressant d'avoir ton propre serveur OVH pour faire tourner tes images ce sera transparent ou de déployer en local sur ton Mac.

Maintenant si tu préfères utiliser les fonctionnalités de ta plateforme actuelle (genre le CDN) cette intérêt diminue...

Pour se connecter à une image docker y compris à distance l'approche est d'utiliser docker-machine (version amateur que j'utilise en mono serveur) pour configurer ton client docker puis de lancer une commande 'docker exec -it XXXX /bin/sh' pour se connecter à un shell.

a+

[Henri Tremblay]

mais docker exec c'est pas bien?

Et sinon, amusant mais Java 8 est maintenant officiel beta depuis ce matin. Plus besoin de whitelisting.

https://cloudplatform.googleblog.com/2017/06/Google-App-Engine-standard-now-supports-Java-8.html

Et LLVM, je suis très pour aussi.

[Philippe Kernévez]

>mais docker exec c'est pas bien? 

Pourquoi ?

(juste pour se connecter sur un container qui tourne)

[Laurent Caillette]

Ah trop fort, j'ai reçu le mail de Java 8 sur GAE (je suivais l'issue) en même temps que vos réponses. Pour la prochaine version de mon outil de surveillance je dois donc me décider entre GAE et GKE + Docker. 

La persistance du DataStore de GAE ça m'a bien gavé. Donc vive GKE + Docker. Si le déploiement et la connexion à distance sont plus simples que ce que je croyais c'est tant mieux, maintenant je sais quoi gougler.

[Henri Tremblay]

Oui. (mais oui, faut se connecter sur le host en ssh en premier)

[Loïc Lefèvre]

Preview : http://www.oracle.com/technetwork/database/multilingual-engine/overview/index.html

Inregration de la Graal VM dans le RDBMS Multi-Model pour faire tourner des procs stock en Javascript.

Feedback ici : https://community.oracle.com/community/database/developer-tools/multilingual-engine/

Enjoy

Loïc 

[Loïc Lefèvre]

Bonjour à tous,

et voilà : https://blogs.oracle.com/developers/announcing-graalvm

Bonne journée

Loïc

[Laurent Caillette]

Salut Loïc,

Aaah j'avoue que réutiliser le code du JIT pour faire de l'AOT c'est malin, ma foi !

[Henri Tremblay]

Finalement! La question est: Vont-on avoir le culot de le mettre par défaut en Java 11