Antonio, Guillaume et Emmanuel discutent 11, le 42 du rockeur, Quarkus, Java 17, limites de Kubernetes, #Y2k22, web3, Maven, Log4J, et et et cloud souverain.
Enregistré le 14 janvier 2022
Téléchargement de l’épisode LesCastCodeurs-Episode–271.mp3
News LangagesQuoi de neuf dans Java 18 de Loïc Mathieu
- Feature complete (mais encore des bugs)
- UTF–8 par défaut
- exemples de code dans la javadoc avec @snippet y compris des references a des fichiers extérieurs
- Simple Web Server pour des resources statiques (comme d’autres platformes comme Ruby ou Python je crois. En code ou via la commande jwebserver
- le mécanisme de finalisation proposé à la suppression --finalization=disabled pour tester. Celui-là il ne nous manquera pas
- ré-implementation de la réflection avec les MethodHandle
Le calendrier de l’Avent Java 2021 a plein d’articles très intéressants
- pas tous révolutionnaires, mais c’est sympa
- RXJava vs Kotlin Coroutines
- Analyser votre repo Git en Java avec jgit
Cinq choses que vous ne saviez pas sur la concurrence en Java
- l’ordre du programme et l’ordre d’exécution n’est pas le même, mais il est sémantiquement similaire
- le nombre de threads dans une JVM est limité (dépend de la machine)
- plus de threads ne veut pas dire plus de perfs
Quarkus 2.5 et 2.6 sont sortis:
- API programmatique pour interagir avec le cache
- Kotlin 1.6
- Java 17 par défaut pour les nouveaux projets générés
- des extensions ont bougé du core vers le quarkiverse hub, peut-être quelques impacts de migration
- images container plus petites en natif et compression UPX possible
- plus petit sur disque mais plus gros en memoire (pour la décompression)
- quarkus.native.compression.level de 1 à 10 dans le fichier de config
- dev service pour Oracvle DB
Utiliser Neo4J pour analyser le chemin de code et pourquoi un bout de code est inclus en natif
- super utile pour les compilations natives
- quarkus.native.enable-reports pour avoir le rapport exploitable par neo4j
- service discovery et client side load balancing
- support pour Consul, Eureka, and Kubernetes
- extensible notamment pour le load balancing
- intégration avec Quarkus REST Client et gRPC
- dans la config stork://hello-service
Pourquoi et comment de la taille des containers Kubernetes
- quand on ne partage pas, inefficient mais sécurisé
- Avec des VM, on peut overcommitter des resources sur l’hyperviseur mais risque sur mésentente
- Ne remplace pas le capacity planning
- Containers définissent des filtrages plus fins et tuent les process qui dépassent
- Discussion cpu_share (proportion en balance), cpu quota, cpu period pour définir les limites basses et hautes
- mais si ça reste statique par host c’est pas très pratique
- Orchestration de container via Kubernetes (request = min, limit = max)
- Kube donne au minimum request mais peut donner plus si le noeud n’est pas occupé à 100%
- Attention, la partie libre n’est pas distribuée équitablement mais en proportion du ratio de request demandé vs les autres. Donc les containers avec des grosses request sont privilégiés. Donc mettre limit est important
- Donc jouer le jeu request et monitored pour ajuster à la baisse si nécessaire. Tous les workloads doivent jouer le jeu.
- Kubernetes QoS (best effort , burstable et guaranteed) utilisé lorsque on tourne bas en mémoire (pas en cpu !)
- Discussion de la sélection du noeud (selector, affinity, taints and tolerations ou isolation/ restriction) pour isoler des qualités de service ou prédictabilité, pour la sécurité etc )
- besoins mémoire : si utilisation max, pod killed. Besoins CPU : si utilisation max, on est throttled -> slow
- Mettre mémoire request = limit sauf si le process peut rendre de la mémoire (pas fait avant java 11)
- CPU request = limit si la prédictabilité de l’application est très important.
- Etudier conso CPU de l’appli en percentile et targeted par exemple une garantie à 99% ou 90 ou moins si pas sensible
- Article ne parle pas du scale out
Exchange 2016 et 2019 souffrent du bug de l’an 2022 Y2K22
- Après Matrix et son opus Resurection, Microsoft relance le bug de l’an 2000, 22 ans après, Y2k22
- dans Exchange server 2016 et 2019 et d’autres systems non microsoft
- pour Exchange c’est du au systeme de scan d’antivirus qui ne reconnaissait pas les dates des signatures de virus 22010100001 parce que le software stocke les dates dans un entier signé 2^31-1=2147483647 et la date est stockée sur les deux premiers chiffres.
- le workaround initial est assez marrant, le software considère qu’on est le 33 décembre 2021 2112330001
Moxy de Signal (ex) discute web3
- web1 était décentralisé, web2 est riche mais centralisé, web3 sera riche et décentralisé
- problème: les gens n’aiment pas faire tourner leurs propres serveurs et ne l’aimeront jamais
- même les entreprises ne font plus tourner leurs serveurs
- un protocole (standard) bouge beaucoup plus lentement qu’une plateforme
- exemple Spring, exemple Quarkus vs Microprofile ou Jakarka EE
- puis discute blockchain et NFT
- l’état et la logique / les permissions pour mettre a jour sont décentralisées mais pas l’interface avec l’utilisateur
- blockchain est une confiance entre serveurs plus qu’entre clients
- avec le mobile, les clients ne peuvent pas acter en tant que server (voir Bitcoin)
- donc des gens vendent des accès centralisés aux noeuds de la blockchain
- et les clients de ses APIs ont une confiance implicite (et pas par le système)
- et centralisation des accès et donc mining de ces informations
- NFTs stockent l’URL de l’objet (sans hash) donc pas sécurisé sans parler du rachat de domaine
- il a fait un NFT qui se change en émoji caca pour celui qui l’a acheté
- et il s’est fait virer son NFT ET sa preuve de possession
- mais c’est une blockchain ???
- sauf que le wallet passe par des fournisseurs centralisés
- pour faire web3, les gens se concentrent autour de plateformes, un comportement tres web2
- donc la blockchain et NFT ont du succès pas parce que c’est distribué mais parce que c’est un gold rush
- la dynamique rend les projets web3 successful mais fondamentalement les mêmes dynamiques vont les centraliser
- propositions
- accepter que les gens ne font pas tourner leur serveurs et utiliser la crypto pour distribuer la confiance
- le POM est figé parce c’est ce que publie maven central, donc maven 3 ne fera que des améliorations mineures
- Maven 5 la proposition: avoir un POM de build (v5) et produire un POM de consommation en v4, comme les autres systèmes de builds font
- Maven 4 va faire la meme séparation mais en faisant un POM v4 build to PO)M v4 consumer conversion en étape intermédiaire
- maven 4 alpha 1 se rapproche, il attend juste des contributions de @aheritier
- blog de Hervé Boutemy
- Maven Wrapper (ex takari) est désormais un projet officiel apache maven : https://maven.apache.org/wrapper/maven-wrapper-plugin/
- idem pour Maven Daemon https://github.com/apache/maven-mvnd
- Le maven Build Cache arrive : https://github.com/apache/maven-build-cache-extension
Comme prévu, la saga log4j continue avec Log4j 2.17 et 2.17.1
- avec l’augmentation de la visibilité, plus de problèmes vont être trouvés
- Log4J 2.17 corrige un appel récursif infini exploitable en déni de service. Besoin d’avoir un pattern non standard dans la config (utilisant les context lookup) et un accès au Thread Context Map par l’attaquant (5.9) https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45105
- Log4J 2.17.1 fixe un abus du JDBCAppender qui peut référencer une URL JNDI et executer du code a distance mais l’attaquant doit pouvoir modifier la configuration de log4j (6.6) https://logging.apache.org/log4j/2.x/security.html#CVE-2021-44832
- doit-on quitter le navire ? équilibre entre fonctionnalités et sécurité
- on fera un épisode spécial log4Shell bientôt
H2 vulnérable à une attaque JNDI
- fondamentalement comme log4shell
- Mais exploitable pour ceux qui passent une url ou un login mot de passe via des infos utilisateur
- Par exemple h2 console
- Mais localhost par défaut
- Sauf dans jhipster
Tribune de Didier Girard sur le cloud souverain
- investissement de 1,8 milliards sur 4 ans dans le cloud français sur 4 ans. C’est moins que chaque grand cloud provider par an
- consortiums européens mais mauvaise histoire CloudWatt, Gaia-x et ses problèmes de gouvernance
- initiative Soutenu par la dépense publique
- Cloud de confiance est un moyen pour Didier du transfert technologique et de casser l’asymétrie de compétence et d’investissement
- Ça répond pas aux problèmes clés levés par Quentin dans l’interview
La Maison Blanche demande à Oracle et Microsoft de réfléchir à la sécurisation des logiciels libres
Outils de l’épisode- en general je préfère les applis natives pour chaque service
- Mais avec les messageries instantanées c’est la chianlie
- Et il y a les apps qui sont des tabs dans le navigateur (Trello, Gmail, calendar etc)
- Là tout est centralisé dans une seule app (notifications etc)
- C’est comme un mini browser dédié avec des sites webs fixes
- Et contre toute attente j’aime bien
- Version gratuite et version pro.
- Encore des limitations (vue de deux apps en parallèle) mais ils travaillent à une nouvelle version
Sunny Tech à Montpellier le 30 juin et 1er juillet — CfP ouvert jusqu’au 28 février
Nous contacterSoutenez Les Cast Codeurs sur Patreon https://www.patreon.com/LesCastCodeurs Faire un crowdcast ou une crowdquestion Contactez-nous via twitter https://twitter.com/lescastcodeurs sur le groupe Google https://groups.google.com/group/lescastcodeurs ou sur le site web https://lescastcodeurs.com/