Toute l'actualité devOps

🚗 Les données de localisation des voitures de 2 millions de clients exposées pendant dix ans. ➡️ Extrait d'Actus DevOps de Mai 2023 L'épisode complet : https://youtu.be/Rp8hNqgGdl0 - https://www.bleepingcomputer.com/news/security/toyota-car-location-data-of-2-million-customers-exposed-for-ten-years/ 📩 Si tu n'es pas déjà abonné, alors **abonne-toi** pour ne pas rater les prochaines vidéos. 💬 Rejoins la communauté : https://www.compagnons-devops.fr 💖 Tu peux soutenir mon travail et la communauté sur : https://soutenir.compagnons-devops.fr 🔗 Tous mes liens : https://i.mtr.bio/compagnons-devops ### Mon Jobboard 💼 Trouve ton job de rêve : https://vu.fr/jobboard-DevOps 👔 Recrute avec moi : https://vu.fr/jobboard-DevOps-recrute ### Mes antisèches 🎁 git : https://bref.lydra.fr/antisechegit 🐳 Docker : https://bref.lydra.fr/antisechedocker 🔀 Ma RoadMap DevOps : https://vu.fr/RoadmapDevOps ### Mes formations 🎓 Forge toi un état d'esprit DevOps : https://vu.fr/devops-mindset --- ### Crédits Les podcasteurs : - Christophe Chaudier : consultant indépendant au sein du collectif Lydra. Animateur du podcast de la communauté des Compagnons du DevOps. professeur vacataire à Télécom Saint-Étienne et au CFAI Loire. Découvre le : https://lydra.fr/ea-3-le-podcasteur-christophe | LinkedIn : https://www.linkedin.com/in/cchaudier | Froggit : https://froggit.fr/ - René Ribaud : Software Engineer chez RedHat. J'aime apprendre et transmettre des connaissances sur le logiciel libre et le DevOps. Découvre le : https://lydra.fr/ea-6-le-podcasteur-rene/ | Linkedin : https://www.linkedin.com/in/ren%C3%A9-ribaud-44145137/ | Twitter : https://twitter.com/Uggla_ | Github : https://github.com/uggla | Sa présentation : https://forum.compagnons-devops.fr/t/uggla-floss-addict-architecte-si/ L'intro et la fin sont de : - Baptiste Gaillet : FullStack développeur avec une tendance DevOps au Centre Scientifique et Technique du Bâtiment, Fondateur et développeur de l'application BedFoodCoffee pour aider les personnes en difficultés. Après des études dans le son et différents métiers, il a effectué une reconversion professionnelle en 2015 pour devenir développeur (Formation diplômante dans le cadre d'un CIF). LinkedIn : https://www.linkedin.com/in/baptiste-gaillet-223832b4 | Twitter : https://twitter.com/bat79a - La musique d'intro est *"Tupac Lives"* de John Bartmann : https://pixabay.com/fr/music - La musique de fin est *"Passport"* de Purple planet : https://www.purple-planet.com/passport L'image est de starline : https://www.freepik.com/free-vector/matrix-style-binary-code-digital-background-with-falling-numbers_8289995.htm Le montage est de Louna HO : https://www.linkedin.com/in/louna-ho-0656801b1/ 📜 Ce contenu est sous licence libre : CC BY-SA : https://creativecommons.org/licenses/by-sa/4.0/deed.fr Si tu utilises ces contenus dans une publication, merci de nous le notifier dans les commentaires. 🌐 Les Compagnons du DevOps est une initiative de Lydra : https://www.lydra.fr #DevOps #Actualités #cloud #ovhcloud #fuite #innondation

Le salon Vivatech est un grand événement pour les passionnés de tech, d’innovation et d’entrepreneuriat ! Si vous me suivez…

🦊 GitLab 16 vient de sortir, et certain GitLab heroes francophone avaient envie d'en parler. Tu cherche un #GitLab souverain ? Simplifie toi le code ! ➡️ https://froggit.fr/ Au programme : 00:00 Introduction 04:29 C'est quoi les GitLab heroes ? Le programme GitLab Heroes : https://bref.lydra.fr/gitlab-heroes 07:33 Table ronde autour de GitLab 16 La release : https://about.gitlab.com/releases/2023/05/22/gitlab-16-0-released/ 58:44 L'évènement de GitLab sur la v16 L'évènement de GitLab autour de la v16 https://about.gitlab.com/sixteen/ 💖 Tu peux soutenir mon travail et la communauté sur : https://soutenir.compagnons-devops.fr --- 📩 Si tu n'es pas déjà abonné, alors abonne-toi pour ne pas rater les prochaines vidéos. 💬 Rejoins les Compagnons du DevOps, c'est gratuit : https://www.compagnons-devops.fr 🔗 Tous mes liens : https://i.mtr.bio/compagnons-devops ## Mon Jobboard 💼 Trouve ton job de rêve : https://vu.fr/jobboard-DevOps 👔 Recrute avec moi : https://vu.fr/jobboard-DevOps-recrute ## Mes antisèches 🎁 git : https://bref.lydra.fr/antisechegit 🐳 Docker : https://bref.lydra.fr/antisechedocker 🔀 Ma RoadMap DevOps : https://vu.fr/RoadmapDevOps ## Mes formations 🎓 Forge toi un état d'esprit DevOps : https://vu.fr/devops-mindset --- **Crédits** - Christophe Chaudier : consultant indépendant au sein du collectif Lydra. Animateur du podcast de la communauté des Compagnons du DevOps. Découvre le : https://lydra.fr/ea-3-le-podcasteur-christophe | LinkedIn : https://www.linkedin.com/in/cchaudier - Philippe Charrière est Senior Technical Account Manager EMEA chez GitLab | LinkedIn : https://www.linkedin.com/in/phcharriere | Twitter : https://twitter.com/k33g_org - Jean-Philippe Baconnais est Consultant chez Zenika Nantes et #GitLabHeroes | LinkedIn : https://www.linkedin.com/in/jean-philippe-baconnais-931544116 | Twitter : https://twitter.com/JPhi_Baconnais - Kevin Davin est Backend Engineer chez Gradle et #GitLabHeroes | LinkedIn : https://www.linkedin.com/in/davinkevin/ | Twitter : https://twitter.com/davinkevin - Matthieu Vincent est DevOps platform Product Manager chez Sopra Steria et #GitLabHeroes | LinkedIn : https://www.linkedin.com/in/matthieu-vincent-ab25064 | Twitter : https://twitter.com/yodamad03 - L'image est de GitLab - Ce contenu est sous licence libre : CC BY-SA : https://creativecommons.org/licenses/by-sa/4.0/deed.fr - Si tu utilises ce contenu dans une publication, merci de le notifier dans les commentaires. 🌐 Les Compagnons du DevOps est une initiative de Lydra : https://www.lydra.fr #DevOps #Live #GitLab #MeetUp Vidéos similaires : https://youtu.be/K4MkrJHREnU https://youtu.be/WnC_I-u2Vww https://youtu.be/aQl-IKLm_9A https://youtu.be/gOCOai6wX_w https://youtu.be/UkUF827CGJY https://youtu.be/RSXmQMceyzs https://youtu.be/YX_8oAL6EcY https://youtu.be/TfKAx9jqsHk Chaînes similaires : https://www.youtube.com/channel/UCs_AZuYXi6NA9tkdbhjItHQ https://www.youtube.com/channel/UCVRJ6D343dX-x730MRP8tNw https://www.youtube.com/channel/UCM0mnsNbecIi_IAPXtHb-TA

🗼 Un incident majeur a touché le Data Center Google Cloud Plateforme à Paris. ➡️ Extrait d'Actus DevOps de Mai 2023 L'épisode complet : https://youtu.be/Rp8hNqgGdl0 - https://www.lemondeinformatique.fr/actualites/lire-google-cloud-sous-l-eau-suite-a-un-incendie-chez-global-switch-clichy-90281.html - https://www.lebigdata.fr/data-center-brule-google-panne - https://www.lebigdata.fr/data-center-panne 📩 Si tu n'es pas déjà abonné, alors **abonne-toi** pour ne pas rater les prochaines vidéos. 💬 Rejoins la communauté : https://www.compagnons-devops.fr 💖 Tu peux soutenir mon travail et la communauté sur : https://soutenir.compagnons-devops.fr 🔗 Tous mes liens : https://i.mtr.bio/compagnons-devops ### Mon Jobboard 💼 Trouve ton job de rêve : https://vu.fr/jobboard-DevOps 👔 Recrute avec moi : https://vu.fr/jobboard-DevOps-recrute ### Mes antisèches 🎁 git : https://bref.lydra.fr/antisechegit 🐳 Docker : https://bref.lydra.fr/antisechedocker 🔀 Ma RoadMap DevOps : https://vu.fr/RoadmapDevOps ### Mes formations 🎓 Forge toi un état d'esprit DevOps : https://vu.fr/devops-mindset --- ### Crédits Les podcasteurs : - Christophe Chaudier : consultant indépendant au sein du collectif Lydra. Animateur du podcast de la communauté des Compagnons du DevOps. professeur vacataire à Télécom Saint-Étienne et au CFAI Loire. Découvre le : https://lydra.fr/ea-3-le-podcasteur-christophe | LinkedIn : https://www.linkedin.com/in/cchaudier | Froggit : https://froggit.fr/ - René Ribaud : Software Engineer chez RedHat. J'aime apprendre et transmettre des connaissances sur le logiciel libre et le DevOps. Découvre le : https://lydra.fr/ea-6-le-podcasteur-rene/ | Linkedin : https://www.linkedin.com/in/ren%C3%A9-ribaud-44145137/ | Twitter : https://twitter.com/Uggla_ | Github : https://github.com/uggla | Sa présentation : https://forum.compagnons-devops.fr/t/uggla-floss-addict-architecte-si/ L'intro et la fin sont de : - Baptiste Gaillet : FullStack développeur avec une tendance DevOps au Centre Scientifique et Technique du Bâtiment, Fondateur et développeur de l'application BedFoodCoffee pour aider les personnes en difficultés. Après des études dans le son et différents métiers, il a effectué une reconversion professionnelle en 2015 pour devenir développeur (Formation diplômante dans le cadre d'un CIF). LinkedIn : https://www.linkedin.com/in/baptiste-gaillet-223832b4 | Twitter : https://twitter.com/bat79a - La musique d'intro est *"Tupac Lives"* de John Bartmann : https://pixabay.com/fr/music - La musique de fin est *"Passport"* de Purple planet : https://www.purple-planet.com/passport L'image est de vecstock : https://www.freepik.com/free-ai-image/computer-servers-row-network-generated-by-ai_41667230.htm Le montage est de Louna HO : https://www.linkedin.com/in/louna-ho-0656801b1/ 📜 Ce contenu est sous licence libre : CC BY-SA : https://creativecommons.org/licenses/by-sa/4.0/deed.fr Si tu utilises ces contenus dans une publication, merci de nous le notifier dans les commentaires. 🌐 Les Compagnons du DevOps est une initiative de Lydra : https://www.lydra.fr #DevOps #Actualités #cloud #ovhcloud #fuite #innondation

Table des matières Introduction Fonctionnalités de Podman Desktop Installation de Podman Desktop Installation de Podman Desktop sur linux Installation de Podman Desktop sur Windows Installation de kind Prise en main de Podman Desktop Builder des images de Containers Lancer un container avec une image existante Créer un cluster kubernetes avec Kind Plus loin Introduction Sponsorisé par Redhat, le projet open source Podman Desktop vient de passer récemment en version stable 1.

Le déploiement de nos applications sur un provider Cloud ne devrait pas être une étape compliquée. C'est dans ce sens que les équipes d'incubation de GitLab ont initié un nouveau projet : Cloud Seed. Cette expérimentation basée sur des templates de GitLab CI vous permet de déployer, pour le moment, vos applications rapidement avec Cloud Run. Dans ce talk, Jean-Philippe vous présente cette nouvelle expérimentation et vous fait un état des lieux des fonctionnalités à venir.

Je travaille depuis un moment sur un service SaaS de monitoring: Appclacks. Je détaillerai dans cet article l’architecture complète de la plateforme, du dev à la prod. Le produit On m’a avec raison fait remarquer que les articles mi-sérieux mi-troll devenaient redondants, donc repartons sur un article un peu plus technique. Appclacks est une solution SaaS de monitoring de type "blackbox", permettant d’exécuter des health checks sur vos services web (requêtes HTTP(s), TLS, DNS, TCP, vérification d’expiration de certificats…​). Les health checks sont réalisés depuis plusieurs endroits dans le monde (2 actuellement, 3 prochainement). J’essaye toujours de créer des produits dont moi même je serai utilisateur, souvent car je suis frustré par les solutions existantes. Construire un SaaS complet d’une qualité professionel en solo est aussi un bon challenge et me permet également d’expérimenter. Appclacks a plusieurs avantages par rapport à la concurrence: Outillage "state of the art": API, CLI, Provider Terraform, un opérateur Kubernetes (avec CRD maison) est en préparation (déjà fonctionnel mais le dépôt est encore privé). Pas de clickodrome. Compatible Prometheus pour récupérer les métriques des health checks: configurez votre Prometheus pour scrape l’API d’Appclacks ! Un accent fort sur l’open source. L’outil exécutant les health checks, Cabourotte, est open source. D’autres suivront. Fonctionne on premise ! Déployez Cabourotte chez vous et venez faire du service discovery via Appclacks pour monitorer vos endpoints internes, eux même gérés via CLI/Terraform/…​ ! Tout n’est pas encore finalisé, le produit n’est pas totalement "prod ready" mais on en est pas loin. N’hésitez pas à tester en vous inscrivant à l’alpha (lien dispo en fin de page ici). Mais comment faire tout ça de manière fiable quand on travaille sur le produit en mode "side project" ? L’architecture On voit qu’on a besoin ici de plusieurs choses: Une API comme point d’entrée à toutes les actions sur la plateforme et une base de données pour stocker les informations. Un composants pour stocker les métriques des health checks côté Appclacks et les rendre disponibles aux clients. Ce sera ici Prometheus. Pouvoir déployer des instances de Cabourotte, servant à exécuter des health checks, un peu partout dans le monde si besoin. Chaque instance doit également savoir quel sous ensemble de health check à exécuter pour pouvoir scale la plateforme horizontalement. J’utilise aujourd’hui exclusivement Scaleway (la partie Cloud) pour l’hébergement. Voici un schema d’architecture global: Je vais maintenant expliquer l’architecture en détail. L’infrastructure Provisioning Toute l’infrastructure Scaleway est déployée via Terraform. Le provider Scaleway est de qualité, je n’ai pas eu de problèmes avec. L’API, Prometheus, et Cabourotte sont déployés sur des machines virtuelles dédiées. Pour Cabourotte, le déploiement se fait en France et en Pologne pour, comme dit précédemment, avoir des health checks exécutés depuis différents endroits (chaque health check configuré sur Appclacks sera exécuté de ces deux localisations). Quoi ? mcorbin n’utilise pas Kubernetes malgré sa propagande importante sur le sujet ? On en reparlera en fin d’article. J’utilise ici beaucoup les offres managés de Scaleway. Pour PostgreSQL, pour envoyer des emails, et le nouveau service cockpit qui me sert de stockage long terme pour Prometheus et pour pouvoir consulter mes métriques (et les métriques Scaleway) via Grafana. Rien à redire sur ces services managés pour le moment, j’en suis satisfait. Cockpit avait quelques instabilités pendant la beta mais maintenant ça a l’air de marcher beaucoup mieux. C’est très agréable d’avoir accès à toutes les métriques internes de Scaleway via Grafana, ceux qui ont déjà utilisé AWS Cloudwatch comprennent la douleur qu’est la gestion des métriques chez certains cloud providers. Bravo Scaleway pour ce produit. Scaleway a par contre plusieurs limitations persistantes pénibles, comme le fait que les instances dans un réseau privé avec DHCP puissent changer d’IP (incroyable sur le cloud) ou sur la gestion des security groups (pas possible d’utiliser un autre security group en source/target par exemple). Mais je fais avec. Déploiement La configuration des différentes machines virtuelles et softwares (que ce soit ceux cités précédemment ou des outils comme node_exporter) se fait avec Ansible, lancé depuis mon poste^^. Aucun rôle, just des playbooks par composants pour simplifier la maintenance à l’extrême. Par contre Ansible c’est lent sans la fibre ;'( L’API L’API, le coeur du réacteur, est codée en Go (avec Echo comme framework HTTP) et reçoit toutes les requêtes vers Appclacks. C’est aussi elle qui gère l’authentification. Elle est stateless et peut donc scale horizontalement. D’ailleurs, concernant l’authentification, j’ai fait au plus simple: elle se fait par token (sauf quelques endpoints d’administrations comme changer son mot de passe, ou bien créer un token ^^) et il est possible d’attacher à un token la liste des appels à autoriser. Cela permet par exemple, si vous utilisez comme décrit précédemment Prometheus en interne pour scrape les métriques fournies par Appclacks, de ne permettre que l’appel GetHealthchecksMetrics sur le token fourni à Prometheus. Bref, l’API reçoit des requêtes et intéragit avec PostgreSQL pour la gestion des données. Lorsque vous créez un health check, récupérez les résultats des health checks, listez vos tokens…​ on passe par l’API et par PostgreSQL. J’ai choisi dès le début d’extraire tous les types (struct Golang) utilisés par l’API public dans un dépôt Github à part (go-types) ce qui me permet de les réutiliser directement dans le client Golang (utilisé notamment par la CLI, le provider Terraform, l’operator Kubernetes). Vous pouvez remarquer sur les types de l’API les différents tags json, query…​ utilisés ensuite par Echo pour désérialiser les requêtes, et les tags validate utilisés pour la vérification des données (via la lib Go validator). J’aime cette approche avec les types publics. Le prochain chantier est d’ailleurs de générer la spec OpenAPI depuis ces types, mais l’écosystème Golang sur le sujet laisse à désirer. Le code est organisé dans dans les grandes lignes en mode "DDD", ce qui facilite grandement son organisation et l’écriture de tests (me permettant de mock facilement mes repositories si nécessaire par exemple). Les migrations de base de données sont exécutées au démarrage de l’application via une lib Go. L’application log dans stdout en JSON (avec le logger zap) et expose un certain nombre de métriques (latency/rate/error des requêtes et réponses http, de certains clients…​) au format Prometheus. Je n’ai pas encore de traces car aucun endroit pour les stockers, mais j’espère en avoir à terme. Emails Le service transactional email de Scaleway est top. J’ai configuré une clé d’API avec leur nouveau système d’IAM n’autorisant que l’envoi d’email. L’API utilise ensuite la lib net/smtp de Golang avec les creds de Scaleway et tout fonctionne comme prévu. Peut être que je ferai un article sur le sujet à l’occasion. Cabourotte Un défi était ensuite de configurer les différentes instances de Cabourotte exécutant les health checks des utilisateurs. J’avais un cahier des charges assez strict: Lorsqu’un utilisateur crée un health check, il devait commencer à s’exécuter très rapidement Cabourotte doit pouvoir scale horizontalement: je veux pouvoir faire exécuter les health checks des clients depuis plusieurs instances au sein d’une même région. Par exemple, mais en gardant la garantie qu’un health check n’est exécuté qu’une fois par région. Que la solution puisse fonctionner ensuite sur du multi région pour le support de multiples PoP, sur plusieurs cloud providers si besoin. Voici la solution retenue. Prober ID Chaque instance de Cabourotte dans une région donnée (France par exemple) se voit attribuer un ID (un peu comme un statefulset Kubernetes): 0, 1, 2…​ L’API connait ensuite le nombre total d’instances de Cabourotte par région: 3 par exemple. Détail important: bien qu’utilisant des UUID comme clés primaires, chaque health check créé sur Appclacks se voit attribuer un autre ID aléatoire au format integer. C’est important pour la suite. Si nous avons 1000 health checks à exécuter dans une région, nous voulons une répartition à peu près stable entre instances, proche de 333.. Cabourotte supporte déjà du service discovery, c’est ce qui permet de le faire tourner chez vous mais branché sur Appclacks. J’ai donc réutilisé ce système pour assigner les health checks aux instances de Cabourotte gérées par le SaaS. Chaque instance est configurée pour récupérer via un endpoint API interne (path/credentials spécifiques) les probes à exécuter. Le endpoint est de type /probers/discovery?prober-id=1, on voit que le prober ID décrit précédemment est passé en paramètre. Que fait donc l’API à partir de ça ? Une simple requête SQL similaire à "SELECT * FROM healthcheck WHERE random_id%<nombre_total_prober>=<prober_id> AND enabled=true": On sélectionne les health checks Mais seulement ceux où le résultat du modulo entre le nombre total d’instances Cabourotte dans la région et l’entier aléatoire assigné à chaque health check est égal à l’ID du prober (= de Cabourotte) demandant sa liste de health check à exécuter. On ne garde que les health checks qui sont été activés par l’utilisateur (Appclacks supporte la désactivation d’un health check sans le supprimer si nécessaire). Prenons un exemple avec 3 health checks ayant comme ID aléatoire 46, 190, 27. Si nous n’avons qu’une seule instance Cabourotte par région, voici ce que ça donne: Healthcheck random ID Prober ID Placement 46 0 46 mod 1 = 0 ? Vrai 190 0 190 mod 1 = 0 ? Vrai 27 0 27 mod 1 = 0 ? Vrai Si l’instance Cabourotte 0 demande à l’API donne moi mes health checks à exécuter, tous les health checks seront retournés. Normal, on a qu’une instance de Cabourotte qui tourne. Voyons maintenant le comportement si nous avons deux instances de Cabourotte. On s’attend à ce que les health checks soient répartis entre ces instances. Rappelez vous du calcul effectué (WHERE random_id%<nombre_total_prober>=<prober_id>). Ici le nombre de total de prober est 2. Healthcheck random ID Prober ID Placement 46 0 46 mod 2 = 0 ? Vrai 46 1 46 mod 2 = 1 ? Faux 190 0 190 mod 2 = 0 ? Vrai 190 1 190 mod 2 = 1 ? Faux 27 0 27 mod 2 = 1 ? Faux 27 1 27 mod 2 = 1 ? Vrai Ici, le prober 0 gèrera les health checks 46 et 190, le prober 1 le health check 27. On voit que grâce au modulo chaque instance récupère seulement un sous ensemble de health checks à exécuter. Si un nouveau health check est créé, celui ci sera automatiquement démarré au prochain "refresh" du service discovery de l’instance Cabourotte correspondante. Scale les probers est donc facile: il me suffit de rajouter des instances et de modifeir le nombre total d’instance dans l’API pour que les health checks se reconfigurent de manière équitable entre ces instances, et surtout la solution a le mérite d’être très simple. Elle est sûrement améliorable notamment pour éviter un déplacement important de health checks en cas d’ajout d’une instance Cabourotte (consistent hashing) mais c’est vraiment de l’optimisation prématurée surtout vu ma volumétrie actuelle. Je n’ai également aucune idée de la scalabilité de faire du modulo directement dans postgreSQL mais j’ai le temps de voir venir. Cabourotte pousse ensuite le résultat des health checks dans l’API, qui sont ensuites récupérables par les utilisateurs. Métriques Comme dit en début d’article, une instance Prometheus peut directement scrape l’API d’Appclacks pour récupérer les métriques des health checks exécutés par le SaaS. Il faut donc stocker ces métriques et les rendre récupérable. Prometheus récupère directement les métriques de Cabourotte sur le endpoint /metrics des prober. Lorsque les instances Prometheus des utilisateurs (ou quand appclacks healthcheck metrics get est exécuté) ciblent l’API d’Appclacks, cette dernière se contente de récupérer dans Prometheus les métriques de l’organisation les demandant. Oui, une simple query Prom du type (sum by (name, name, le, zone, id) (healthcheck_duration_seconds_bucket{owner="%s"})) or (sum by (name, name, status, zone, id) (healthcheck_total{owner="%s"})), où owner est un label indiquant l’organisation envoyant la requête (déduite depuis le token d’authentification). Les données sont ensuites renvoyées au format texte de Prometheus en réponse. Je n’ai aujourd’hui qu’une instance de Prometheus mais je prévois d’en mettre rapidement une deuxième, en actif/actif et avec un load balancing pas trop bête côté client, dans le but d’avoir une forte tolérance aux pannes sur ce composant. Comme dit précédemment, tout part également en remote write dans Scaleway Cockpit (métriques systèmes et applicatives incluses). Service discovery Une des propriétés intéressantes lorsqu’on branche Cabourotte installé on premise au service discovery d’Appclacks est la possibilité de passer des labels pour sélectionner les health checks à récupérer (et donc à exécuter) par Cabourotte. En effet, comme la majorité des ressources d’Appclacks, il est possible d’attacher à leurs créations des labels (de simples clés/valeurs). Elles sont stockées dans PostgreSQL au format jsonb (labels jsonb dans la table SQL). Ici pas de magie malheureusement, pour l’instant je me contente d’itérer de manière un peu degueulasse dans le code pour ne retourner que les "match" pour des labels donnés. Site vitrine J’utilise Dorik pour le site vitrine appclacks.com[appclacks.com]. Pour les pas doués du CSS comme moi c’est très bien et j’en suis content. Evolutions futures Résultats sur S3 Tous les résultats des health checks sont stockés pour l’instant dans PostgreSQL dans une table nommée healthcheck_result. Ca prend un max de place. Prenons des chiffres fictifs: 1000 healthchecks 3 régions Exécutés toutes les 30 secondes. 1000*3*2 = 6000 insertions par minute, donc 8640000 par jour. Alors bien sûr ça passe, Postgres n’a aucun soucis à gérer ça. Mais je prévois à moyen terme d’historiser les résultats dans S3 et de ne garder en base que quelques semaines maximum (voir moins) de rétention pour économiser du stockage et éviter que cette table devienne trop grosse. Du sharding serait également une possibilité Kubernetes Gérer des machines virtuelles est pénible. J’aimerai migrer toute l’infrastructure (sauf les instances de Cabourotte déployées de manière autonomes) sur Kubernetes. Je n’utilise aujourd’hui pas l’offre Kapsule de Scaleway car elle ne répond pas à mes exigences pour de la production (pas de réseau privé, pas de support des security groups ce qui la rend de facto inutilisable dans un contexte d’infra as code, kubelet exposé sur internet). Quand Scaleway aura amélioré son produit je basculerai dessus: cela me permettra de gérer beaucoup plus simplement qu’aujourd’hui l’infrastructure, et de manière plus fiable. Release de l’operator Kubernetes Il est prêt, plus qu’à faire la CI et la documentation :) Kube builder a été utilisé pour générer tout le boilerplate. Browser monitoring J’aimerai rajouter à moyen terme du monitoring via démarrage d’un vrai navigateur web (type Selenium) pour etoffer l’offre. C’est aussi pour ça que je veux basculer sur Kubernetes: cela me donnerait une plate-forme de base pour gérer des cronjobs Selenium de manière très simple par exemple. Interface web Je suis une quiche en HTML/CSS/Javascript et je prévois de le rester. Je préfère me focus sur du tooling "state of the art" comme dit précédemment. Conclusion Monter tout ça était (et est toujours) bien fun, on verra où ça va dans les années à venir :)

Quelles sont les technologies en vogue ou à éviter en 2023 ? Infrastructure management, cloud provider, langages de prog, Observability…​ Nos experts vous donnent leurs avis dans cet article écrit à la va vite ! Le radar Lien direct Infra management ADOPT Terraform est forcément indispensable en 2023. Bon, en réalité l’outil ne scale pas, il vaut mieux juste l’utiliser pour bootstrap vos clusters Kubernetes mais c’est le meilleur outil pour faire cela. Cloud init fait toujours le café pour faire 2-3 trucs dégueulasses (qu’on sait généralement pas trop où mettre) au boot d’une machine, un indispensable aujourd’hui. Ansible, à réserver pour les rares choses qui ne tournent pas sur Kubernetes (type certains VPN) et où une machine virtuelle est nécessaire. Faites des CLI internes, c’est cool TRIAL Nix: la hype du moment, c’est bien cool pour gérer des machines de manière déclarative, par contre ne pas utiliser si vous n’avez pas la fibre chez vous (ou alors faut pas avoir à installer un paquet en urgence à 3H du matin parce que l’astreinte a sonnée). HOLD Puppet: c’est fait en Ruby, tout est dit. Shell scripts: l’interdiction du shell pour l’administration système est en bonne voie, ne pariez pas là dessus. Procedures in PDFs: un classique de nos grands groupes, on évite également. Cloud providers ADOPT AWS: Nobody Ever Got Fired for Buying AWS: un classique. Pas forcément le cloud le plus user friendly (IAM, VPC peering…​) mais ça marche bien, c’est très stable, et le catalogue de produit vous permettra de faire tourner les prods les plus modernes dessus. Exoscale: le meilleur cloud provider européen, what else ? Netlify: super choix pour du site statique, avec un peu de FaaS autour si besoin. Cloudflare: Le king du CDN/Anti DDoS et qui innove en permanence (cloudflare workers, R2…​) TRIAL Scaleway: encore pas mal de produits moyens (par exemple l’offre Kubernetes) mais ça vaut dans le bon sens. Leurs dernières sorties (Observability, Transactional email…​) sont top. On y croit. Scalingo: le PaaS qui monte. On attend maintenant quelques features avancées autour du réseau et la fameuse certification SecNumCloud, à suivre de près. Openstack: le boss du cloud privé. HOLD OVH: pour du bare metal avec le vrack, ça passe. Pour la partie cloud on oublie (offre disparate, outillage terrible…​). Clever Cloud: beaucoup trop limité en fonctionnalité pour le moment pour pouvoir être utilisé pour de nombreux projets. No Cloud: aucune excuse pour ne plus faire du cloud en 2023 (j’inclus le cloud privé). CI & CD ADOPT ArgoCD: le meilleur outil de l’écosystème Kubernetes, un indispensable qui fait le café. Vos développeurs adoreront redémarrer leurs applications via l’interface quand ça mem leak ! Github actions: simple et efficace go race -race ./… && golangci-lint run && docker build && docker push: en réalité, est ce qu’on a vraiment besoin de plus dans une CI ? Arrêtons avec la complexité accidentelle. TRIAL Jenkins: les papys font de la résistance ! Avec du job DSL et du Jenkins pipeline partout ça fait le boulot. Flux: je le mets pour faire plaisir aux copains mais l’UI d’ArgoCD est trop bonne pour que Flux puisse tenir la comparaison, désolé ! HOLD Gitlab CI: qui s’est dit que c’était une bonne idée de faire un système de CI turing complet avec du YAML qui embarque du bash inline ? Pour lancer du one-liner, pourquoi pas, mais forcez vous à l’utilisez aucune autre fonctionnalités. Programming languages ADOPT Clojure: fonctionnel, persistent & immutable data structure, super écosystème (merci la JVM): coder en Clojure augmente votre productivité, c’est prouvé ! Golang: le langage des dégueulasse mais l’outillage, la stdlib, l’écosystème, les perfs et le fait que ça build en binaire statique fait de lui un très bon choix pour votre prochain projet. Java: je l’ai déjà dit, la JVM est probablement la meilleure plateforme pour écrire des apps en 2023 (et bientôt loom !). Les dernières évolutions de Java en font un super langage. Faites juste attention à ne pas utiliser les bloatwares comme Spring, Hibernate etc…​. TRIAL Kotlin: Java avec quelques features en plus, indispensable pour le dev mobile. Python: franchement il était pas loin de passer dans la catégorie suivante rien qu’à cause des systèmes de build qui changent tous les deux jours. Mais si vous arrivez à build votre projet, ça fait le job, surtout en ajoutant des type hints. Zig: pas stable mais prometteur. Rust: difficile d’ignorer Rust en ce moment même si j’ai jamais vu un langage aussi usine à gaz/compliqué/si difficile à lire. A garder pour remplacer C mais c’est tout. NUKE IT FROM ORBIT (only way to be sure) Une catégorie spéciale ici ! Bash: la section Shell scripts a tout dit, à faire disparaître en urgence de votre production. Ruby: un langage où le moindre serveur web recevant 3 requêtes par secondes vous demandera une quantité astronomique de ressource, le tout propulsé par un framework (rails) inventé par le malin ! Perl: on a tous cru dans perl 6 (ou pas). C/C++: même les experts mondiaux qui en font depuis 40 ans arrivent à faire des use after free, heap overflow…​ dans des codes type sudo/openssl. Donc inaccessible pour les moldus comme nous. k8s infrastructure ADOPT KEDA: indispensable pour l’autoscaling depuis de nombreuses sources, comme par exemple des métriques Prometheus. Cluster autoscaler: la base pour autoscale les noeuds des clusters kube. Horizontal pod autoscaler: la base pour scale les pods, à coupler avec KEDA. Karpenter: le futur d’AWS EKS, qui simplifiera grandement la gestion de vos noeuds Kubernetes. TRIAL Cluster API: a regarder si vous devez vous diriger si vous devez gérer de nombreux clusters kubernetes chez vous. Kubevirt: gérer ses machines virtuelles de manière déclarative via Kubernetes, pourquoi pas ? HOLD Crossplane: l’idée est bonne mais au final ça fait un peu usine à gaz. Installer le provider AWS avec ses > 900 CRDs causera également quelques soucis à vos clusters. Service Mesh: une complexité démentielle pour un gain qu’on cherche encore. On oublie pour le moment sauf cas particuliers. MAPE K: peut être le futur de la gestion d’infrastructure mais on peine à trouver des implémentations. Load balancers ADOPT Traefik: la star pour faire de l’ingress sur Kubernetes. Stable même avec des milliers d’ingress, bonnes perfs, des métriques sympa par défaut…​ à utiliser. HAproxy: le choix par défaut pour du load balancing hors Kubernetes. TRIAL Envoy: le challenger, tout le monde en parle mais par contre personne ne l’a jamais vu en production. Caddy: parfait pour servir des fichiers statiques. HOLD nginx: qui comprend vraiment le format de configuration de l’outil ? F5: $$$ Observability ADOPT Opentelemetry: surtout pour les traces, c’est le futur ! Mettez en partout, remplacez vos logs par des events attachés aux spans ! Prometheus: J’ai jamais aimé le pull mais faut se rendre à l’évidence, ça marche et l’écosystème est là. Loki: Parfait pour vos logs surtout si vous voulez pas payer trop cher vu que tout part sur s3. Elasticsearch: le gestionnaire de logs historique, ça marche toujours bien surtout on premise. Tempo: Probablement l’outil le plus intéressant pour stocker vos traces. Grafana: L’outil de base (le seul ?) pour vos dashboards. Thanos: Simple et à installer et vous permettra de stocker vos métriques Prometheus sur le long terme. TRIAL Victoria metrics: Prometheus mais avec de meilleures performances, à tester ! Timescale: stocker vos métriques dans postgresql, pourquoi pas ? A voir selon la volumétrie que vous avez. Mimir: Comme Thanos, à tester notamment en cas de forte volumétrie. Appclacks: le futur du blackbox monitoring il parait. HOLD statsd: plus d’actualité cloudwatch: UX terrible à tous les niveaux Nagios & fork: le paradigme du monitoring a complètement changé depuis cette époque. Databases ADOPT Postgres: ça fait tout (SQL, json, full text search, timeseries comme montré précédemment…​), le projet évolue à toute vitesse, un très bon choix ! MariaDB: marche très bien, rien à redire. MongoDB: une base au format document, ça peut servir. MongoDB Atlas est pour moi la meilleure offre DB cloud du marché actuellement en terme d’UX/fonctionnalités. Cassandra: la meilleure base orientée colonne, super notamment pour faire du multi data center facilement. Aurora: Propriétaire mais ça scale ! S3: Utiliser S3 comme base de données, de plus en plus fréquent pour les logs, métriques…​ peut être bientôt pour le reste également ? TRIAL MySQL: Toujours très présent donc doit être cité RocksDB: Ca a de grosses perfs et c’est fun ! HOLD Oracle: vous savez pourquoi Microservices ADOPT Pizza teams: On aime quand les équipes ont un ownership fort sur leurs services et domaines. Contract testing: obligatoire quand on fait du microservice ? Feature flags: Release early, release often: les features flags sont l’outil de base pour réaliser cela. TRIAL Keep the good old monolith: et pourquoi pas si le code est bien conçu ? DDD: permet d’éviter le couplage, facilite les tests…​ un bon outil. HOLD Distributed monolith: un classique on-demand environments: une mauvaise idée même si certains essayent de vous convaincre du contraire :D Bus and queues ADOPT Kafka: meilleur outil depuis des années pour faire des architectures orientées événements, du stream processing, faire buffer pour vos logs/métriques…​ Il s’opère également très bien et est dispo partout en mode SaaS. SQS: simple d’utilisation et fait le job quand on a juste besoin d’une queue de message. TRIAL NATS: Le streaming "cloud native", à voir où ça va. RabbitMQ: Bien mais pénible à opérer surtout si vous ne savez pas lire les stacktraces Erlang. HOLD Sidekiq: c’est du Ruby donc ça partage ses caractéristiques. Lean ADOPT Lean: on ne peut plus s’en passer. Des tonnes de pratiques utiles au quotidien. Self service/product approach: On fournit des services internes de qualité en écoutant nos utilisateurs et en les rendant autonomes au quotidien. J’en parle ici. Dev oncall on production: you build it, you run it. La qualité augmente bizarrement très vite quand on reçoit les alertes de ses propres services. Blameless incidents: Les incidents c’est de la faute de tout le monde et on ensemble bosse pour que ça se ne reproduire plus. No backlog: Un backlog, pourquoi faire ? De toute façon au bout de 3 mois votre backlog ne sera plus valide. Autant ne plus en avoir. TRIAL http://programming-motherfucker.com/: tout est sur le lien. HOLD Certifications: ça sert à quoi ? ITIL & SAFE: bien mais seulement pour les consultants spécialisés. Agile & Scrum: on veut du Lean. Security ADOPT IAM: la base de la base, notamment sur le cloud. Dommage que ce soit pas dispo sur ce nombreux acteurs Français. RBAC: si vous faites du Kubernetes, vous allez y passer. Kyverno: parfait pour valider vos manifests Kubernetes, faire de l’audit, et ajouter une couche supplémentaire de sécurité. TRIAL OPA: On préfère Kyverno ici mais ça fait aussi le job, notamment si vous maitrisez Rego. HOLD Databases exposed on internet: mauvaise idée il y a 15 ans, mauvaise idée aujourd’hui. Conclusion A vous de faire vos choix !

De retour sur les certifications AWS... Après plusieurs certifications sur Google Cloud, je souhaitais obtenir la certification réseau sur AWS que je voulais passer juste après la sécurité en juillet dernier. Néanmoins, l'examen venait d'ê

Vous n'êtes pas sans savoir que la sauvegarde de vos données est une chose à prendre très au sérieux. Perso,…

Caché sous le terme Container as a Service (CaaS), des plateformes Kubernetes sont parfois mises en place par les Ops sans prendre en compte la manière dont elles vont être consommées, en particulier sans s'interroger sur la manière dont les développeurs vont s'y intégrer. Il existe alors un écart important entre leurs besoins et le service proposé. Les développeurs rêvent d'une plateforme qui transforme leur code source en une url. Or ils se retrouvent à devoir construire une image de container et à produire des centaines de lignes de fichiers de déploiement. Nous vous proposons durant cette session d'améliorer l'expérience développeur en nous appuyant sur des projets CNCF additionnels : Backstage, Cloud Native Buildpacks, KNative, Cartographer. Cela permettra à nos développeurs de déployer leurs applications dans un Cluster Kubernetes sans avoir à regarder 50 heures de vidéos avant de se lancer !

I'm proudly honored to be a speaker at KubeHuddle Toronto 2023: https://kubehuddle.com/2023/toronto/ Spoiler alert: no the impostor syndrome is not a fatality. Use it to improve yourself.