Sheepux

Pour info, nous sommes désormais 7 à 9 tout les vendredi dans la bonne humeur. Cette semaine on teste le proximity chat. Les appels de présence sont fait sur le canal #jeux du discord (taper !joingamers dans le salon pour être ajouté au groupe qui est ping chaque semaine). Ce sera probablement mon dernier message dans ce fil, nous coordonnons tout sur le discord.

Première soirée découverte ce soir

Pour l'instant les votes sur le discord orientent vers vendredi/samedi. 6 joueurs d'identifié, viendez !

En janvier nous allons lancer des soirées Among Us sur le discord. Rejoignez nous. Fréquence/créneaux à déterminer. Niveau débutant (non joué pour nombreux). Nous préférons éviter les experts dans un premier temps pour avoir l'effet découverte.

J'ai vu énormément de projets demander du Istio pour l'observabilité des échanges micro service et pour les thématiques théoriques Blue/Green (genre ca fait tendance). Aprés en effet 27% utilisé en prod, ca me semble plus qu'étrange car ce n'est un use case que pour les gros projets.

Yep, je voulais prendre le temps de faire un résumé. Probablement pendant les vacances de noyel

Tu trouvera le lien youtube sur le discord. Je laisse le lien en publication réduite comme je n'ai pas assez sourcé les images que j'ai piqué.

Rappel, c'est cet aprem 🙂

Rendez vous Samedi 17h->19h pour une petite présentation docker/kubernetes (principalement kubernetes, docker sera assez rapide) sur le discord NXi. Présentation des principes généraux, un peu de détail sans aller trop en profondeur)

"potentiellement" tout comme potentiellement tu arrive à t'échapper d'un noyaux. Tu peux chercher les CVE y'en a dans les 2 cas (https://github.com/firecracker-microvm/firecracker/issues/1462 ) Idem pour kata vs runc qui a aussi son lot de soucis pour l'orchestration avec firecracker https://github.com/kata-containers/runtime/issues/2700 Je fais tourner des clusters partagés/mutualisés multiprojets/multienvs avec plusieurs milliers de conteneurs, tout cela n'empêche pas de fonctionner en commun. Il y a par contre en effet un intérêt sécurité d'une meilleur isolation kernel mais ce n'est pas non plus actuellement le drama cataclysmique. Ce n'est pas un "versus" c'est juste un process de runtime différent qu'il reste intéressant à suivre.

Hello, la news https://www.nextinpact.com/blog/43360/next-inpact-v7-est-la-ce-qui-change-des-aujourdhui indique l'endroit où signaler les anomalies (lien github) 🙂

La WTFPL bien sur ! https://choosealicense.com/licenses/wtfpl/

Je n'avais pas vu ta contribution. J'ai également demandé à un modo de séparer du sujet de capitalisation car le débat est tout autre. Je dirait au contraire que les éléments de conteneurisation apportent plus de réponses aux problématiques de sécurité. Si tu peux détailler ton propos, je suis intéressé. Comme souvent les problème de sécurité sont lié aux équipes qui l'utilisent et je ne vois pas en quoi docker empirerai le sujet. Bien au contraire le fait que le conteneur embarque le moins d'outil possible réduit les surfaces d'attaque. La conteneurisation avec ses couches d'images & dockerfiles permet d'accélérer les cycles de mise à jours et éviter le retard trop souvent constaté de mise à jours des socles/libs. J'aimerai bien avoir plus de précisions du lien indiqué sur le fait annoncé que LXC est moins sécurisé à cause de "relaxed isolation levels" sachant que les "priviledged containers" sont à proscrire et même interdit en général. J'attend encore de voir le "technology killer" que l'on nous annonce toujours depuis de nombreuses années. Les paris sont difficiles (et quand je vois que l'article parle de l'implémentation d'Intel dans openstack qui est un socle qui est tombé en disgrâce). Pour l'article en lui même, je trouve de nombreux faux arguments et même éronnés. Exemple parmi tant d'autre : l'aspect démarrage de conteneurs présenté ici comme "lent" ... je dois avouer ne pas comprendre et ne pas le constater au quotidien (quel est l'ordre de comparaison?). Les seuls éléments en compétition avec docker sont les approches serverless qui sont plus un complément qu'une concurrence directe car ne répondent pas aux même enjeux. Edit: Ah firecracker est un framework pour le serverless. L'article d'AWS confirme ma vision que c'est un complément (ici via containers kata) et que kubernetes restera probablement un hyperviseur transverse https://aws.amazon.com/fr/blogs/france/kata-containers-1-5-pour-firecracker/

Ce sujet porte sur l'analyse de https://insights.stackoverflow.com/survey/2020 qui est le sondage annuel de stackoverflow pour identifier les tendances et attentes de la communauté (65.000 réponse). Note: Aucune relecture, de nombreuses réécritures partielles de phrases. Certains passages peuvent donc être un carnage. Les pourcentages sont à considérer avec une réponse à choix multiple (la somme ne fait donc pas 100%). Pourquoi une analyse spécifique à docker/kubernetes et pas le reste ? Tout simplement parce que ces 2 domaines apparaissent dans le top 3 et que c'est mon domaine et donc je peut essayer de contextualiser les chiffres. 1. Popularité des plateformes de déploiement 1.1 (plateforme appréciée) https://insights.stackoverflow.com/survey/2020#technology-most-loved-dreaded-and-wanted-platforms-loved5 1 - Linux 76.9% 2 - Docker 73.6% 3 - Kubernetes 71.1% 4 - AWS 66.4% Nous retrouvons Linux en top 1 car son succès global (Android, serveur) n'est plus à prouver. Nous pouvons cependant souligner le lien très étroit entre les images docker et les socles Linux. Jusqu'à il y a encore peut de temps les conteneurs Windows étaient à l'étude. et les déploiements .net passaient par des conteneurs .net core Tout les conteneurs reposaient donc sur des socles Linux avec comme toujours la bataille des différentes distributions (Ubuntu puis Alpine et autres). Ubuntu était devenu (et est toujours) le standard mais désormais ce sont les distribution Alpine qui tendant à passer devant par leur rapidité de démarrage et la taille des images (ainsi que la réduction des surfaces d'attaque en réduisant le nombre d'outils inclus de base). A noter cependant qu'avec Alpine de nombreux soucis ont été rencontrés pour le portage de nombreuses libs (exemple OpenJDK) car la bibliothèque glibc qui sert à de nombreux process a été remplacée par musl libc qui a des comportements différents selon les situations. Lors du passage à la conteneurisation des connaissances/compétences avancées en socle Linux sont devenus parfois nécessaires. Docker et Kubernetes suivent en tant que technologies les plus appréciées. Succès s'explique par plusieurs points: La maturité des fondamentaux système (LXC, namespace) et outils ( compose, helm, registry entre autres) Les nombreux retours d'expériences (articles) Les nombreuses communautés (une technologie quelle que soit sa bonne conception ne percera qu'avec des communautés actives). Même docker(l'entreprise) a perdu sa propre bataille d'hyperviseur de conteneurs : "Swarm VS kubernetes" (alors que Swarm apportaient de trés bonnes réponse à certaines problématiques). L'adoption et contributions par de nombreux acteurs majeurs (Google, Amazon, Microsoft, IBM etc... ) et la portabilité entre ces différents hébergeurs cloud. Exemple d'ouverture publique des problématiques de la solution AKS d'Azure https://github.com/Azure/AKS La liberté système que permet l'approche (permettant à docker de répondre à de nombreux cas d'usage). et surtout le fait que les conteneurs (tels que vu par docker) a été libéré par docker (à l'origine Kubernetes a percé car a su répondre aux problématique d'industrialisation du déploiement et d'exploitation (avec notamment de nombreuses métriques) en production dans un écosystème multi-service et multi-host en capitalisant et introduisant (pour docker) des concepts simples permettant non seulement d'organiser les relations au sein d'une application mais également de s'intéresser aux éléments extérieurs (ingress gérant le provisionnement automatique d'équilibreurs de charge externes et des DNS) et surtout de laisser le choix de l'implémentation à différentes solution évitant de forcer l'utilisation d'une technologie en particulier. Exemple: liberté de choix du reverse-proxy (nginx, traefik), du composant de CNI (la couche réseau: https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) et aussi du runtime engine ( docker ou CRI-O ou containerd) https://kubernetes.io/docs/setup/production-environment/container-runtimes/). Kubernetes a su répondre également aux enjeux de l'auto-hébergement en démontrant qu'il pouvait s'installer sur les serveurs locaux d'entreprise ("on-premise") A noter cependant que Kubernetes ne représente qu'une petite partie des sujets docker (https://trends.google.fr/trends/explore?date=all&geo=FR&q=docker,kubernetes ). La problématique kubernetes reste limitée à des projets d'une certaine taille et ayant les moyens pour y consacrer du temps (retour d'expérience: 40 clusters (gérants 150 VM) vs 5000 VM docker). C'est cependant un élément vital pour les applications nécessitant de la haute disponibilité. Nous pourrons également souligner l'organisation très ouverte mais bien structurée des contributeurs en SIG : Special Interest Group https://github.com/kubernetes/community/blob/master/governance.md permetant aux différents contributeur de retrouver des communautés dédiées à chaque problématique (voir la liste: https://github.com/kubernetes/community/blob/master/sig-list.md ). Pourquoi retenir AWS dans l'extrait du top ? Tout simplement qu'à l'heure actuelle l'écosystème AWS pour kubernetes est (avis personnel d'utilisateur multi-cloud) le plus avancé (en terme d'offre de services) et le plus mature (stabilité et autres). 1.2 (plateforme désirée) https://insights.stackoverflow.com/survey/2020#technology-most-loved-dreaded-and-wanted-platforms-wanted5 1 - Docker 24.5% 2 - AWS 20.2% 3 - Kubernetes 18.5% 4 - Linux 16.6% La conteneurisation avec Docker et Kubernetes retient l'attention car c'est en effet la technologie en vogue pour de nombreuses entreprises et projets (retour d'expérience personnel : il nous arrive même de conseiller un projet à ne pas basculer sur la conteneurisation car non adapté au projet principalement "trop couteux pour cause de coût de transition (formations/niveau de maturité des équipes)"). Les offres d'emplois continuent pour l'instant d'évoluer en ce sens https://www.beseen.com/blog/talent/kubernetes-career-trends/ ou https://www.itjobswatch.co.uk/jobs/uk/kubernetes.do que ce soit au niveau projet ou chez les cloudeurs (à noter OVH, Scaleway pour parler des français). Cependant de nos jours les virages technologiques sont parfois assez violent (retour d'expérience personnel: kubernetes enterrant openstack https://trends.google.fr/trends/explore?date=all&geo=FR&q=kubernetes,openstack ). Nous pourrons noter une très forte affinité de kubernetes avec les déploiement en agile/devops; la technologie impliquant un travail étroit entre les équipes de développement et celles en charge du déploiement/exploitation. (A titre personnel je n'ai rencontré que de très rares projet kubernetes qui ne soit pas sur ce modèle). 1.3 (plateforme détestée) https://insights.stackoverflow.com/survey/2020#technology-most-loved-dreaded-and-wanted-platforms-dreaded5 Nous ne commenterons pas la présence de WordPress au top1 😛 14 - AWS 33.6% 15 - Kubernetes 28.9% 16 - Docker 26.4% Pour autant, bien que les précédents points glorifient ces technologies il n'y a pas de lumière sans ombre. Kubernetes sont en bas de ce classement (donc c'est positif) cependant les pourcentages sont quand même notable. Sans plus de détails sur les causes de ces votes je vais extrapoler à partir de mon expérience. Principale cause, à mon sens, les développeurs doivent désormais s'occuper de l'aspect packaging et parfois avec des problématiques système ce qu'un développeur n'apprécie pas toujours (souhaitant se concentrer sur les problématique fonctionnelles/code). L'organisations en service/microservice impose de penser les applications d'une nouvelle manière ce qui n'est pas toujours simple. Il est même parfois plus simple de faire "à l'ancienne", c'est parfois la raison d'un échec projet : avoir voulu utiliser les technologies tendances alors qu'elles n'avaient pas forcément de plus value et on entrainer un "enfer de nouveauté" (transition technologique, problème de maturité etc...). Notons également le changement des habitudes des développeurs sur l'écosystème avec par exemple la disparition des fichiers de logs en tant que tels et l'utilisation de commandes/outils pour consulter les journaux. Cela a été dans mon cas de nombreuses sources de conflit ("Les logs sont sur la sortie standard! Pas dans des fichiers!") . Egalement, lorsqu'il y a des "bugs" lié à la plateforme ceux ci sont parfois très complexe dépassant complètement les développeurs et peuvent parfois prendre un certain temps à être identifiés et corrigés (par Kubernetes ou par le cloudeur qui réalise une implémentation spécifique à son socle). Les cloudeurs tardent parfois à proposer les dernières versions kubernetes entrainant un gap pour avoir un correctif de certains problèmes. En point final, de très fortes différences entre le niveau d'expérience d' équipes sachant déjà faire du docker et les débutantes. Si nous pouvons déjà le voir entre 2 équipes "Java" (simple exemple) on rajoute à nouveau une surcouche de compétence en docker/Kubernetes pouvant encore creuser la différence. Nous pouvons aussi le voir sur la qualité des différentes images présentes sur le hub docker: il faut souvent savoir faire le trie. N'hésitez pas à commenter vos problématiques. 2. Technologies liées https://insights.stackoverflow.com/survey/2020#correlated-technologies Intéressons nous maintenant aux technologies liées avec un focus sur celles autour de la conteneurisation. Comme indiqué précédemment, Docker est très lié à Linux (et donc en complément à la pratique de bash pour étudier les problématiques système). Nous pouvons remarquer que les technologies qui gravitent autour de la conteneurisation sont surtout des bases PostgreSQL et des outils tels que Elasticsearch (c'est l'outil préféré pour le stockage des logs). Le succès de postgreSQL s'explique principalement par l'attrait des développeurs (et pour les mêmes raisons qu'évoqué au point 1 de kubernetes). Par contre son lien avec docker & kubernetes s'explique par sa très bonne conteneurisation (permetant un travail en local), sa flexibilité et sa capacité de mise à l'échelle avec notamment des implémentations cloudeur qui permettent une offre haute disponibilité (exemple: AWS RDS). Si redis est lié à Docker, nous pouvons voir qu'il est aussi lié à Kubernetes. Il s'agit tout simplement de la technologie retenue lors de besoin du passage en services qui permet de synchroniser simplement des états entre les conteneurs d'un même périmètre. Nous retrouvons AWS comme cloudeur principal des offres de conteneurisation mais je trouve étrange qu'Azure ne soit pas plus présent. Go est lié à kubernetes car les modules sont écrit en Go 🙂 Terraform et Ansible sont des outils classiques des approches Devops et s'intègrent très bien (bien que le besoin de terraform pour kubernetes soit, à mon sens, assez réduit étant donné sa capacité à décommissioner dynamiquement les ressources provisionnées) . Plus proche de kubernetes je rajouterai HELM et pour docker Compose. J'inclurai également Prometheus comme outil de consolidation des métriques qui est le couple recommandé (avec Graphana) bien que des outils propriétaires tels que datadog ont une progression notable ces 2 dernières années par leur intégration globale unifiée (un outil pour les gouverner tous). En terme de langages, j'ai surtout vu au niveau projets du nodeJS et du Java, mais cela ne semble pas se refléter sur ce sondage. 3. Le mot de la fin En espérant que la lecture vous a intéressé 🙂 Cet article est amené à évoluer selon vos retours ! Peut être le proposer en article/news Nxi ? (nécessite probablement une réécriture/adaptation)

Perte de perf, ce n'est pas le contexte de la demande. En effet soit LXC soit (quelques recherches) il y a pas mal d'articles/repo sur le sujet genre https://github.com/wozhub/nvidia-steam et pour le reste du partage usb tu rajoute dans le run un --device=/dev/ttyUSB0