Les meilleures conférences du WeShare de mai

Sur la Route 53 au pays du DNS

Chris fait peu d’histoire d’Internet à la manière de Père Castor, en ratissant de TCP/IP à DNS. On fait le tour des notions importantes de serveur d’autorité, de résolveur, de TTL et des différents types d’enregistrements (A, AA, CNAME, MX…) jusqu’à DNSSec et GeoDNS.
Chris nous rappelle les pièges à éviter, les boucles DNS… Un exemple concret sur le blog de Stéphane Bortzmeyer.
À coups d’outils tels que dig (l’assemblée propose drill également), ping, nslookup, on expérimente DNS, en jouant aussi avec /ect/hosts, avant de parler d’outils plus haut niveau tels que intodns (pour les recommandations), zonemaster (vérifié par l’afnil), dnsviz (visu), dnschecker (vérifier la propagation). Il est important de vérifier au travers de plusieurs sources.
Enfin, on parle du service AWS Route 53 et de ses nombreuses fonctionnalités qu’il a fallu bidouiller à la main dans un passé lointain comme l’application recovery controller (round robin dynamique)…

L’Infra-as-Code débarque au pays du clic-clic

Mathieu nous fait un excellent retour d’expérience plein d’humour sur une DSI assez débutante en Infrastructure as Code et dont les équipes n’avaient pas forcément entendu parler de Git.
De son intervention chez ce client, il retient que le couple VSphere / Terraform fonctionne très bien, parfois même mieux que dans l’interface VSphere. Au contraire, faire fonctionner Terraform avec AD DS (Active Directory DNS) était compliqué, notamment au niveau de l’authentification avec Kerberos. Au travers d’une gestion de secrets pilotée par Ansible et Vault (ça fonctionne toujours bien), et quelques orages pour faire fonctionner Rancher correctement derrière le proxy HTTP et des certificats auto-signés, le seul vrai mur rencontré aura été de faire fonctionner Zabbix sur Rancher dans cet environnement. Mathieu nous partage son expérience avec le controller Kubernetes fourni par Citrix pour NetScaler qui est closed source mais bien documenté.
Enfin, il nous partage l’expérience humaine que cela a été, l’écart entre la théorie et la pratique relevé, la résistance au changement, le fait de devoir faire des compromis, savoir dire non et rester de bon conseil, même quand les idées ne sont pas les meilleures.

Quarkus - Ou comment développer des application Java adaptées à Kubernetes

Présenté par Katia Aresti de la team Infinispan chez RedHat, nous faisons un tour d’horizon de Java version Cloud Native en passant par GraalVM jusqu’à Quarkus. Katia nous explique que le couple Graal + Quarkus apporte un vrai gain de temps au démarrage, qu’il a une empreinte mémoire faible et que la phase d’augmentation pendant le build fait une énorme différence par rapport à la stack standard ou un OpenJDK. Après un tour des extensions disponibles, nous assistons à une démo de déploiement sur un Minikube avec la mise en place d’un healthcheck et d’un readiness check.

Pourquoi DevOps ne tient pas ses promesses ?

Dans un talk répétition pour leur slot à Devoxx (si vous les avez raté, sachez qu’ils seront également au Voxxed Days Luxembourg très prochainement mais vous pouvez aussi voir le replay de Devoxx)

Guillaume et Gérôme nous expliquent pourquoi faire du DevOps (obviously), comment s’y prendre, tant niveau humain qu’au niveau d’une organisation d’entreprise.
Sous une forme humoristique et avec des quizzs, concrètement, on parle d’objectifs communs, d’implication des Devs dans le monitoring, de faciliter les changements pour les Ops, un peu d’outillage, de confiance établie dans un cadre de travail grâce à de l’objectivité, des interactions et de la communication… On aborde également cela dans un cadre présentiel et à distance.
Beaucoup de retours d’expérience sur les pratiques habituelles du DevOps viennent accompagner cette présentation. On souligne en conclusion l’importance des relations humaines, le temps nécessaire à un changement de culture et la nécessité d’un parrainage fort mais surtout d’une envie partagée par les équipes, même si un monsieur DevOps est présent.

Tools in Action - Atlas Ripe: Pourquoi, que peut on en faire ?

Dans un slot complètement exotique, Lilian nous explique ce qu’est le réseau Atlas de RIPE. L’objectif principal est de fournir un moyen de surveillance des interconnexions globales, ainsi que la surveillance de services critiques tels que les DNS racines. Il se base sur des appliances matérielles mais des versions logicielles sont également disponibles. On fait le tour des types d’appliance disponible; Les Anchors et de Probes qui sont les différents matériels servant d’outils de mesure. Ce réseau global d’outils de mesure permet de rendre publique des données sur la connectivité d’Internet au global.
Vous avez la possibilité de mettre en place vous même des tests perso sur ce réseau mais attention, chaque test vous coûtera un certain crédit, virtuel et propre à ce réseau, et vos tests et leurs résultats doivent être rendus publiques. Vous devez trouver un sponsor par candidature pour entrer sur le réseau et il n’est pas possible d’acheter du crédit. Cependant, la publication de vos résultats vous rapportera du crédit.
Avec les devices les plus simples et abordables, vous pouvez donc mettre en place des tests de type ping, traceroute, DNS, HTTP, SSL, NP… vers des endpoints un peu n’importe où sur la planète.

Hands-on Argo

Pablo s'attèle à animer un hands-on sur Argo dans le but de réaliser une architecture full Kubernetes, outillage inclus. Le but affiché est de ne plus jamais avoir à passer une seule commande kubectl. Dans un tutoriel riche et détaillé, en utilisant la suite Argo, on gère notre CI avec Argo Workflows, la CD avec Argo CD, mais aussi des déploiements complexes, avec Argo Rollout, et même une architecture orientée évènements avec Argo Events. En combinant ces quatre outils, on automatise tout, de A à Z.

Hands-on : Comment gérer ses environnements de travail avec Nix

Dans un atelier, présenté par Romain et Stéphane, et là aussi en répétition avant Devoxx France, on s’attaque à un hands-on sur Nix, un outil permettant de gérer efficacement son poste de travail mais aussi les projets sur lesquels on intervient.

Entre théorie et pratique, ce slot aborde différents sujets autour de Nix:

• Présentation de l’outil et de son écosystème
• Comment bien débuter avec Nix
• Gérer ses environnements projets avec Nix shell
• Comment utiliser Nix pour construire son application
• Nix dans un pipeline de CI, ça donne quoi ?

A l'issue de ce lab, on a un aperçu de ce qu’est capable de faire Nix et à quels besoin il répond. Plus de raisons de se demander quelle version de Go, Python ou Terraform utiliser pour vos différents projets, Nix est là pour vous aider !

Pour les plus curieux d’entre vous, retrouvez une réédition de cette session au cours de l’édition 2022 du Breizhcamp ce mercredi 29 juin.

Faire du FaaS en architecture hexagonale

Les architectures FaaS sont des modèles extrêmement intéressants pour déployer certaines applications : modularité, scalabilité, coûts et opérations… Mais ce type d’architecture amène de nouvelles problématiques. Comment construire des applications sur ce modèle ?
David et Jean Pascal nous expliquent qu’il est possible de construire des applications sur une architecture FaaS en appliquant une architecture hexagonale. L’architecture hexagonale se concentre sur un découpage entre la logique du domaine métier et celle des systèmes extérieurs. En définissant un modèle de port/adapter, elle apporte des gros avantages architecturaux en réduisant le couplage du métier vis-à-vis de ces systèmes externes permettant d’augmenter ainsi la testabilité et la maintenabilité du code de l’application. Mais attention, cela n’aura aucun intérêt par exemple dans le cadre de développement de fonctions pures infrastructure où le métier n’est pas présent par exemple. KISS (Keep It Simple Stupid) est encore et toujours le maître mot.
Jean-Pascal et David nous font la démo sur une petite application de gestion des anniversaires des employés d’une entreprise avant d’apporter un peu de perspective avec un retour d’expérience sur le développement d’une appli de calcul de taux de dispo dans un environnement métier compliqué.

Père Castor, raconte nous tes ateliers les plus marquants

Gérôme nous fait un retour d’expérience sur trois situations où il a réussi à débloquer des situations à l’aide d’ateliers collaboratifs.

Les trois situations qu’il nous raconte sont les suivantes :

• Le facilitateur : faire avancer un sujet qui patine en structurant la réflexion et en enchaînant des cycles de réflexion en petits groupes et mise en commun ;
• Le stratège : faire prendre conscience à un chef de département que sa solution de fusionner les équipes ne lui permettra pas de résoudre ses problèmes en se basant sur des solutions de design thinking ;
• Le réconciliateur : face à un fossé entre le chef de projet et une équipe, faire prendre conscience à chaque partie des difficultés et bonnes intentions de l’autre partie pour combler ce fossé.

En conclusion, Gérôme nous rappelle l’importance de garder en tête ce que l’on souhaite en sortie d’atelier et de se baser ensuite sur son bon sens pour définir le plan. Un avantage indéniable de ce genre d’atelier est qu’il permet aux participants de lever la tête du guidon et de se concentrer sur la résolution de problèmes.

Packer sur AWS

Durant cette présentation, nous avons le droit à une thématique Pokémon. Élodie nous présente la solution Hashicorp Packer pour construire des images machine, tout en se focalisant sur la manière dont elle a implémenté son utilisation dans sa mission.
Elle passe en revue les différents éléments de configuration d’un fichier Packer, les variables sensibles, les images de base, l’utilisation d’un provisioner Ansible, la distinction entre l’ancien format JSON et le HCL2 et nous montre comment migrer…
Élodie passe en revue l’usine CI/CD Gitlab qu’elle a mise en place s’appuyant notamment sur Packer pour construire des AMIs puis les déployer. Le contexte permet également d’apprécier la mise en place d’un build matricielle qui lui permet de construire ses images pour plusieurs cibles et plusieurs environnements en parallèle.
Retrouvez l’article d’Elodie sur le sujet sur le blog.

YASAF : AWS Chalice, Yet Another Serverless API

Tanguy nous présente la problématique d’une de ses missions précédentes : la réécriture d’une solution d’alerting en utilisant des services serverless dans AWS.
AWS Chalice est un des frameworks disponibles pour ce genre de cas d’utilisation et Tanguy nous a présenté son fonctionnement, les avantages de son focus très important sur le code comme moyen de décrire, via des décorations dans le code, l’infrastructure autour des fonctions. Son repository d’exemples présente plusieurs démonstrations illustrant le fonctionnement du framework. De la création simple de fonctions/API, intégration d’un authorizer custom, middleware de logging, à la possibilité d’utiliser des blueprints pour structurer son application en packages de routes composables. Pour aller plus loin, Tanguy a présenté plusieurs cas d’intégrations du framework.

Tools in action: AWS et les profils, dedans, dehors, partout

Benoît nous présente le modèle d’authentification dans AWS, l’utilisation de profils AWS s’appuyant sur différentes options: soit un couple Access Key / Secret Key, soit au travers d’AWS SSO. Il fait un focus sur le fichier config qui permet notamment de configurer un assume-role pour chaîner des profils, de configurer l’utilisation d’un MFA, d’utiliser AWS SSO ou encore de faire exécuter des applications tierces qui vont produire les identifiants d’un profil. Il fait évidemment le lien avec les champs de profil correspondants dans le fichier credentials. Il a aussi montré la commande aws configure list qui permet d’afficher le profil évalué dans le contexte actuel, pour débugger.
Benoît nous fait ensuite la démonstration de la configuration et l’activation d’AWS SSO (attention, awscli v2.X ou SDK compatible nécessaire) puis du credential_process pour l’exécution d’un processus au moment de l’évaluation du profil.
Retenez les conseils du pro, le format de configuration de profil est identique à tous les SDK ou pour la CLI, les variables d’environnement ont toujours le dernier mot, faites attention à vos fichiers credentials en clair. Grâce à ce modèle d’évaluation, il est possible d’utiliser le même code applicatif en environnement local comme en automatisation, en changeant simplement la configuration des profils AWS.

Mon cloud à moi, il est écolo, d'abord !

Édouard exploite les approximations du rapport d’impact d’un Cloud provider pour vulgariser un certain nombre de concepts utiles à la conception responsable des services numériques.

Après avoir pris soin de prévenir l’auditoire que le fond du rapport montre une réelle volonté de bien faire, Édouard utilise les faiblesses du rapport d’impact pour expliquer la différence entre énergie et électricité, évoquer le principe de l’analyse de cycle de vie, disséquer le système des garanties d’origine renouvelable de l’électricité, montrer où trouver l’intensité carbone de la production électrique des différents pays ou rappeler le principe des “4R” (Réduire, Réutiliser, Réparer, Recycler).

En guise de conclusion, Édouard invite les participants à s’intéresser aux biais cognitifs et arguments fallacieux, sources intarissables d’erreurs de raisonnement : nous avons besoin d’agir vite mais surtout bien.

Présentation de Loki, la centralisation de logs dans Kubernetes branchée à Grafana

Au travers d’une présentation technique, Alexandre nous parle de Loki, le Prometheus pour les logs. Parmi les éléments différenciant avancés, Loki n’effectue pas d’indexation sur le texte intégral des logs, il est particulièrement adapté au stockage des logs sur Kube et il est maintenant natif à Grafana.
Ainsi, l’indexation est minimale, Loki peut traiter de nombreux formats, il est peu coûteux en ressources, simple, rapide à requêter (comme avec du PromQL), de l’alerting via les logs couplé à des métriques peut être mis en place et enfin il supporte tous les stockages objet (S3, GCP, MinIO…)…
Alexandre fait la démonstration d’une architecture Loki / Grafana / Collecteurs (Promtail, Fluentd, Fluent Bit…), il nous présente le format des logs avec les labels avant de passer au collecteur de logs Promtail. Cependant, compte tenu de sa jeunesse, il nous recommande plutôt d’utiliser Fluentd et le logging operator Fluent Bit pour de la production.
Dans sa démo sur GKE du déploiement de Loki, des agents, d’une application et de Grafana, on parcourt l’interface Promtail qui est semblable à celle de Prometheus et qui s’ajoute aisément comme datasource dans Grafana.

Rendez-vous le mois prochain pour un autre résumé de cette journée dédiée au partage de connaissance !