Thomas Labarussias

Le FinOps

Thu, 17 Jun 2021 00:00:00 +0000

Avant-propos

Durant mon expérience professionnelle précédente, j’ai exercé pendant 3 ans en tant qu’expert FinOps sur AWS. La fonction ayant été créée avec moi, j’ai eu toute liberté pour mettre en place le modèle que je souhaitais, avec sa méthodologie et ses outils. Avant d’oublier ce que je sais, je me suis dit qu’il serait peut-être intéressant pour certains que je mette ce qui me reste en tête par écrit, la littérature en français se faisant rare d’autant plus (si l’article plaît, je ferai peut-être une traduction en anglais).

Il m’était également apparu, en discutant avec mes clients et d’autres experts, souvent issus d’entreprises de conseils, que ma vision pouvait différer de la leur et de ce qu’on trouve généralement dans les articles traitant du sujet. Je pense que cela vient du fait que je suis avant tout un OPS, gérant une production et les contraintes inhérentes. Mes recommandations et conseils ont toujours eu pour trame de fond une vraie exploitation des plateformes, de leurs performances et disponibilités (travaillant pour un infogérant, si la plateforme tombait, c’étaient mes collègues et moi qui réglons les problèmes, possiblement en astreinte 😉 ).

N’ayant de connaissances avancées et n’ayant effectué des audits uniquement pour AWS, j’utiliserai dans cet article beaucoup de termes et conseils liés à ce Cloud Provider, mais je pense que les éléments généraux sont facilement transposables à GCP et Azure.

Définition

La première des tâches est bien entendu de définir le terme de FinOps lui-même. Il apparaît évidemment qu’il est la contraction de deux termes (comme tous ces TrucOps à la mode 😛). Dans notre cas: Financial + Operations. Pas très parlant au demeurant, on s’attend plus à de la comptabilité qu’à de l’architecture Cloud.

Voilà donc ma définition, avec des morceaux en gras et ce, à dessein:

Le FinOps analyse les architectures Cloud et leurs facturations associées, afin de dégager des axes de limitations des coûts et/ou d’économie, en assurant un niveau de risque faible et en prenant en compte les enjeux de l’entreprise.

Reprenons chacune des parties mises en exergue:

analyse les architectures: Le travail de FinOps est un travail d’ingénierie avant tout, si on se contente de pointer des lignes dans une feuille Excel pour trouver les services coûtant trop chers dans lesquels il faudrait tailler, cela ne marchera pas.
facturations associées: On enfonce une porte ouverte, mais il va de soit que pour cibler les axes d’améliorations, il faut savoir quels sont les services qui sont facturés et dans quelles mesures (réduire de 10% le coût d’un service à $100 reste moins intéressant avant que 2% d’un service à $1000, par exemple).
axes de limitations des coûts et/ou d’économie: La distinction est très importante à mon sens. On cherche souvent à seulement diminuer les coûts, mais il faut aussi penser à faire en sorte de contrôler leurs évolutions. J’ai souvent expliqué qu’une facture de Cloud Provider qui augmente, ce n’est pas forcément anormal ou gênant, cela peut juste être la conséquence logique de l’augmentation de l’activité. Vous avez plus de trafic, et donc plus de consommation mais surtout plus de chiffre d’affaires, ce qui est attendu. Là où ça coince c’est quand la facture augmente alors que le CA baisse, ou bien que les deux croissent tous deux mais dans des ordres de grandeur très différents (coûts qui explosent par rapport aux revenus).
un niveau de risque faible: Quand on met en place des actions FinOps, on pense souvent à changer les types des Instances (VM), ou à ré-architecturer des portions de la plateforme. Il est alors très important de garder à l’esprit que la plateforme doit assurer un service de même qualité (voire plus), et il faut donc être très prudent dans les choix et leurs mises en place.
enjeux de l’entreprise: Une plateforme Cloud n’est après-tout qu’un outil, un moyen de délivrer un service, elle s’inscrit dans un cadre beaucoup plus vaste à prendre en compte. Je pense par exemple à la maturité de l’entreprise avec les technologies, ou bien aux contraintes légales (PCI-DSS, HADS, etc).

Trouver le bon dosage entre HA, Perfs et Coûts

Fort de cette définition, il convient désormais d’expliciter ce qu’on vise en faisant du FinOps, ce qui va guider nos choix.

Il s’agit de trouver le bon dosage entre 3 critères:

Haute-disponibilité
Performances
Coûts

Les 3 s’influencent bien évidemment mutuellement.

Par exemples:

Si la HA est un critère dominante, les coûts vont forcément grimper et les performances peuvent baisser (multi-régions, multi-cloud).
Si on privilégie les performances, des machines plus grosses seront à payer mais la HA pourra être sacrifiée également (j’ai eu un client qui faisait tout tourner sur une seule AZ AWS car les latences entre les datacenters AWS avaient un impact sur sa grille de calcul).
Si on cherche absolument à baisser les coûts, on sacrifiera les performances et/ou la haute-disponibilité.

Un autre critère à prendre en compte: la Sécurité

J’ai volontairement omis de rajouter ce 4ème critère dans la liste précédente, car il est particulier et à toute son importance. Il impacte potentiellement les 3 autres critères et s’inscrit dans un cadre plus important très souvent impossible à négliger (PCI-DSS, HADS, etc). Il faut donc veiller à ce que les recommandations s’inscrivent dans les bonnes pratiques de sécurité, voire dans le cadre de la loi.

Ajuster ses critères

Il ressort de tout cela une bonne nouvelle, c’est que nous sommes dans le cadre d’une plateforme Cloud, qui vient avec ses contraintes mais aussi ses avantages, avec en tête de la liste la flexibilité.

J’ai mentionné précédemment que tout l’art du FinOps était de trouver le bon dosage entre les perfs, la HA et les coûts, et ce qu’il y a de magique avec le Cloud, c’est que ce dosage n’est pas voué à être immuable et universel. La souplesse des Cloud Providers permet d’ajuster la balance comme on le souhaite et quand on le souhaite.

Voici une liste d’éléments pouvant amener à adapter notre choix du ou des critères dominants, avec quelques exemples pour les expliciter:

Environnement: On accorde souvent plus d’importance à la disponibilité de l’environnement de production qu’à celui de staging.
Période: En e-commerce, on mettra le paquet en période de soldes. Une application de facturation n’a besoin d’être gonflée aux stéroïdes qu’en début ou fin de mois, etc.
Criticité des données: On peut parfois se permettre de perdre du cache, mais pas des données métier.
Criticité de l’application: Un SSO sera central, alors qu’un worker qui tombe ne crée que du délai et sa tâche sera censée être reprise ensuite.
Enjeux Business: Respect des SLA de disponibilité ou de performance.
Budget: Une levée de fond permet souvent d’apporter les modifications voulues ou à l’inverse, un trou dans la trésorerie imposera de sacrifier tel ou tel critère.

Coûts et modèles de facturation

Il est extrêmement important d’avoir à l’esprit de quoi sont composées les factures mais aussi le contexte global dans lesquelles elles s’inscrivent.

Je dégage donc 2 axes, les coûts Directs et les coûts Indirects.

On ne pourra pas jouer sur les deux de la même façon, voire pas du tout pour certains éléments. Et il est très important de tous les prendre en compte dans les choix des actions à mener.

Les coûts Directs

Je classe parmi les coûts Directs tout ce qui est directement dans la facture du Cloud Provider, en séparant en 2 catégories:

Ressources: Ce sont les coûts dans les factures les plus simples à comprendre et estimer, généralement facturés à la seconde ou heure, ils caractérisent les éléments “immobilisés” pour composer l’infrastructure (Instances, Volumes, etc). La règle est simple, plus on prend gros, plus on paye cher, et inversement. On peut donc facilement estimer les économies possibles quand on agit sur elles.
Consommations: Ce sont tous les coûts dans les factures plus difficiles à estimer car indépendant de nos propres choix et variant du tout ou tout entre les périodes. On y classe la bande passante, les snapshots, le nombre total de requêtes, etc. Les estimations d’économies sont souvent moins précises mais en connaissant bien son activité et en prenant quelques marges, on y arrive.

Les coûts Indirects

Quand on pense à réduire sa facture Cloud on oublie bien souvent les coûts annexes qui n’apparaissent pas à proprement parlé sur la facture mais qui sont pourtant bien là quand on veut mettre en place des actions:

Coûts de migration: Si vous prévoyez de remplacer des morceaux ou de partir sur une nouvelle architecture, il sera nécessaire de passer un grand nombre de JH (jour-homme) sur le sujet, et cela aura un coût pour votre organisation, tant financier qu’humain. Le retour sur investissements se doit donc d’être intéressant.
Coûts de développement: Dans la même idée, moins OPS et plus DEV, si vous changez de technologie, il y aura sûrement du code à écrire et donc du JH à passer, sur des fonctionnalités qui n’apportent pas forcément une plus-value pour le client final.
Formation: Un point à ne jamais négliger, tout changement sera mieux vécu s’il est accompagné par une formation, qu’elle soit interne ou non (c’est souvent plus cher avec des consultants extérieurs, bien entendu).
Infogérance: Si vous ne gérez pas vous-même votre plateforme, ou si vous avez souscrit un contrat pour avoir du 24/7, le périmètre financier peut être impacté.
Licences: C’est un point surtout valable pour les migrations d’On-Premise vers du Cloud, les modèles de facturation des licences éditeurs pouvant beaucoup changer, et pas forcément à la baisse.

Ces coûts Indirects sont bien souvent plus difficiles à évaluer, voire quasi impossibles quand vous êtes un auditeur externe, mais il est important de prendre en compte le fait qu’ils existent et peuvent drastiquement changer le choix des actions à mener.

FinOps, un processus

Maintenant que nous avons la destination, voyons le chemin. A mon sens, le FinOps est un processus qui se déroulera toute la vie de la plateforme et débute à sa conception. Il apparaît bien souvent que réfléchir à une architecture en intégrant les aspects FinOps dès le début, amène à créer des conceptions plus proches des bonnes pratiques.

Ce processus à plusieurs caractéristiques, il est:

Continue
Itératif (une action après l’autre)
A complexité croissante (voire exponentielle)

Ce processus, peut varier d’une entreprise à l’autre, mais on retrouve généralement 3 étapes clés, se répétant:

Analyse > Recommandations > Mise en place > Analyse > …

Un processus continue

Les architectures Cloud étant élastiques, les facturations associées le sont tout autant. A cela s’ajoute que le tout virtualisé, payé à la consommation, rend les architectures mutables (changement de types de machines, remplacement de briques par d’autres services, etc). Il apparaît alors évident que mener des actions FinOps une fois tous les trimestres, par exemple, sera moins pertinent, et pire, à la traîne vis-à-vis des dépenses.

Il est important d’intégrer le FinOps parmi tous les autres processus permettant de gérer correctement une plateforme, voire même d’intégrer des points de contrôle au même titre que nous mettons en place du monitoring pour les systèmes eux-mêmes. Les Cloud Providers ne s’y sont pas trompés et fournissent des moyens de vérifier le respect d’un budget (sans jamais bloquer les possibles dépenses, on parle juste d’alertes). Cela rentre dans la partie de ma définition: limiter les coûts.

Cela n’écarte pas les audits plus profonds pouvant être menés, non pas au jour le jour, mais tout de même régulièrement, et qui eux servent souvent à dégager les axes d’économies plus importantes.

Un processus itératif

Une fois qu’une analyse FinOps a été menée à bien et que des préconisations ont été établies, la tentation de réduire la facture immédiatement peut être forte en menant toutes les actions d’un coup. C’est rarement une bonne chose. En menant plusieurs actions en parallèle, il devient plus difficile de déterminer quelles sont celles qui ont eu l’effet escompté, et pire, certaines peuvent entrer en contradiction sans qu’il ne soit possible de déterminer comment. En itérant, action par action, il devient aisé de déterminer celles qui ont bien fonctionné et donc de les répéter dans le temps ou sur d’autres environnements.

Un processus à complexité croissante

La première action (cf suite de l’article) est généralement de traquer les dépenses inutiles, les gâchis. C’est une action relativement simple, qu’on peut faire manuellement dans un premier temps puis automatisée. Une fois que c’est en place, d’autres actions peuvent être menées, forcément plus compliquées que les précédentes, et ainsi de suite. Il apparaît rapidement que le rapport économies possibles sur investissement (temps + argent) s’amenuise avec le temps, plus on avance dans les solutions trouvées pour limiter les coûts ou économiser, plus celles-ci deviennent complexes à mettre en oeuvre. Je pense même que la tendance suivie est exponentielle. L’ordre de grandeur de l’investissement n’est pas du tout le même entre une automatisation de la suppression des volumes détachés et la refonte d’une partie de l’infrastructure pour utiliser du Serverless.

Outillage

Avec quoi pouvons-nous mener une analyse FinOps?

Il s’agit bien entendu d’une liste non exhaustive, mais c’est une demande qui m’a souvent été faîte donc la voici.

Les Factures

Les factures sont, bien entendu, les premières pièces à étudier, elles sont souvent simplifiées et permettent d’avoir un aperçu global ainsi que les tendances. C’est aussi ce que reçoit votre service comptabilité (ça aidera pour communiquer avec eux, pour lui expliquer les possibles pics ou autres quand c’est nécessaire).

AWS Cost Explorer/Trusted Advisor

AWS fournit 2 outils:

Cost Explorer: Cela va être votre nouvel meilleur ami. L’outil s’améliore d’année en année et vous permet d’analyser et de mettre en graphique tout votre historique de dépenses, de filtrer par tags, service, région, etc. C’est vraiment un indispensable et il faut vraiment apprendre à s’en servir. La difficulté est de comprendre ce qu’on lit, car contrairement aux factures, les détails se basent sur l’API AWS et non une simplification des termes comme dans les factures reçues en fin de mois.
Trusted Advisor: Lorsque vous souscrivez au support de niveau Business, en plus de donner de bonnes informations liées à la sécurité de votre plateforme, l’outil vous donne des informations sur les gâchis financiers présents dans le compte. La nécessité d’avoir un haut niveau de support pour que ce soit actif peut être contraignant mais heureusement, les éléments donnés sont relativement simples à obtenir à la main ou via script.

Les Scripts

Il existe une pléthore de scripts voire d’applications complètes sur le web pour aider à analyser ses coûts et trouver les axes d’amélioration. Vous pouvez également écrire vos propres scripts pour mettre en avant des points précis liés à votre infrastructure. L’avantage de l’automatisation est bien entendu de vous faire gagner du temps mais surtout de pouvoir avoir des résultats réguliers et donc de suivre les résultats de vos modifications.

Voici quelques exemples (les deux premiers sont de moi):

Et une recherche sur Github avec quelques autres outils: Résultats

SaaS

L’engouement pour le FinOps vient forcément avec son lot de services en ligne pour aider dans la tâche, en voici deux que j’ai testés (je ne ferai pas de comparatif, n’y ayant pas touché depuis longtemps maintenant):

Ces outils font plus que du FinOps, mais comme leurs coûts rentrent dans ce que j’appelle les coûts Indirects, il faut donc les prendre en compte dans vos calculs pour estimer les économies.

Websites

Le web fourmille de documentations et d’articles comme celui-ci, il ne faudra pas hésiter à chercher des heures durant pour apprendre les techniques en vogue pour limiter les coûts ou même décoder la documentation AWS parfois absconde.

Voici un exemple d’outils que l’on peut trouver et utiliser fréquemment:

https://Instances.vantage.sh
https://calculator.aws/#/ (calculateur officiel fourni par AWS)
https://observablehq.com/@rustyconover/aws-ec2-spot-Instance-simulator

Schémas

Le FinOps est un travail technique, même si on épluche bien les factures, il est intéressant d’avoir la vision de la plateforme en terme d’architecture. Comprendre comment les choses sont pensées, de l’Instance aux services managés. Le nec plus ultra étant d’avoir également les flux réels et pas juste un schéma de principe, les flux étant souvent très difficiles à catégoriser et encore plus à comprendre niveau facturation.

Voici un schéma de quelques flux avec les sens pour lesquels AWS vous facture:

La Métrologie

Tous les Cloud Providers fournissent leurs propres solutions de métrologie, plus ou moins avancées. Dans le cas d’AWS, la solution s’appelle Cloudwatch. Bien que pratiques, il est nécessaire, pour évaluer le bon usage des ressources, d’avoir son propre système de métrologie, avec une granularité plus fine, mais surtout plus de métriques. Prenons le cas de l’utilisation CPU, qui est certes rarement un facteur limitant sur des services Web, l’utilisation de la mémoire ou les IO étant plus à suivre. Vous n’avez aucune information sur les contextes d’exécution (user, system, steal, iowait, …). Dans le cas de la RAM, votre Cloud Provider ne vous fournira pas de détails sur son utilisation, difficile de juger en l’état de la pertinence de sa taille pour vos besoins.

Beaucoup d’actions possibles

La liste suivante d’actions catégorisées FinOps ne se veut absolument pas complète, chaque service ayant ses spécificités et les modèles de facturation évoluant aussi dans le temps. Encore une fois, même si très orienté AWS, elles sont tout ou en partie transposables à d’autres Cloud Providers.

Catégoriser les actions à entreprendre

Afin de pouvoir mieux évaluer les pertinences des actions préconisées mais aussi de pouvoir les prioriser, j’ai pris l’habitude de les catégoriser selon 3 critères:

Complexité: C’est souvent un bon moyen pour aider à estimer le temps qui sera nécessaire pour la mise en oeuvre.
Risque: Notre but, comme explicité dans ma définition, est de ne pas dégrader la production, mais toute action à sa part de risque, surtout lors d’une bascule d’un morceau d’architecture à une autre, ou bien lors de la réduction du type d’une Instance.
Economies attendues: En valeur absolue bien souvent, et à mettre en perspective avec les deux autres critères. Il peut être pertinent de faire une action simple, sans risque qui fait économiser $100 plutôt qu’une refonte compliquée qui fera gagner $200 mais demandera 10JH par ailleurs (rappelez-vous, les coûts Indirects).

Lorsque l’audit FinOps est pour un client tiers, cela sera d’autant plus important de lui permettre d’évaluer les actions qu’il voudra mener ou faire mener, lui seul ayant les cordons de sa bourse.

Identifier et supprimer les gâchis

La première action à laquelle on pense, est bien évidemment de réduire les gâchis. La flexibilité du Cloud amenant souvent à créer puis laisser traîner des ressources dans un coin.

Voici une liste de quelques gâchis communs:

Snapshots anciens: Plusieurs cas de figures, soit ce sont des Snapshots pour des AMI obsolètes, soit de volumes EBS n’existant plus. Il se peut que ce soit de vieux Snapshots d’EBS encore en fonctionnement, dans ce cas, comme ils sont sauvegardés de manière incrémentale, leurs suppressions entraîneront un gain moins important sur la facture, les plus récents ayant toujours besoin d’une référence.
AMI Anciennes: Sauf si cela s’avère vraiment nécessaire, il n’est pas utile de garder de vieilles AMI, avec des systèmes et des paquets obsolètes. Leurs suppressions ne font rien gagner à proprement parlé, mais libèrent des Snapshots qui eux peuvent ensuite être supprimés.
EIP détachées: Le gain est minime, mais si vraiment elles ne servent à rien, autant les libérer.
EBS détachés: Cela vient souvent de la suppression d’Instances sans suppression des volumes qui les utilisaient. Si en plus il y avait de l’AutoScaling d’actif, les volumes peuvent vite monter.
EBS attachés mais sans IO: Le coup classique du volume monté sur /logs mais où aucune application n’écrit dedans.
ELB/ALB/NLB sans Instance ou sans requête: Il arrivent que des xLB ne pointent vers rien, ou bien que les Instances derrières soient Unhealthy depuis très longtemps, sans aucun impact par ailleurs.
EC2/RDS dans des anciens types: A chaque nouvelle famille sortie par AWS, les prix sont plus faibles, pour parfois de meilleures performances ou options.
EC2 stoppées depuis longtemps: Le compute n’est pas payé dans ce cas, seul le stockage, cela peut être légitime ou non. A vous de voir.
Buckets S3 avec des objets de type Reduced Redundancy Storage Class: AWS a déprécié ce type d’objet, en le rendant légèrement plus chère d’un millième que le type Standard, sur des Po voire To, cela vite (histoire vécue avec une plateforme de streaming de musique)
Buckets S3 Buckets qui sont Publics mais pas derrière une distribution CloudFront: Rien que le fait de sortir sur Internet à travers une distribution Cloudfront réduit les coûts de bande passante, cache activé ou non. Ceci est valable dans tous les cas, devant xLB ou EC2.
RDS sans connexion depuis longtemps: Si la base ne sert que de temps en temps, il est toujours possible de l’éteindre (pour 7j maximum, ensuite il faudra éteindre de nouveau).
RDS utilisant du PIOPS inutile: Pour chaque GB de GP2/3, AWS assure un plancher de 3 IOPS, ce qui implique qu’avec 350GB, vous avez plus (1050 IOPS) que les 1000 IOPS demandés à être payés en minimum pour le stockage PIOPS, et ce pour beaucoup moins cher.

Pour vous aider à identifier ces éléments, l’API et les métriques en votre possession seront très utiles.

Utiliser correctement les ressources

Les ressources managées

Avec l’avènement du Cloud, sa souplesse et sa rapidité pour obtenir des ressources, on en vient presque à oublier les réflexes de nos prédécesseurs, contraints à tirer jusqu’à la dernière goutte de sève des machines achetées pour plusieurs années. Je crois fermement, qu’avant d’entamer des changements de type, surtout lors de Scale Up (augmentation du type), il faut travailler au niveau de l’OS et des applications pour obtenir le maximum. Tout résoudre par de l’infra n’a jamais été pertinent (le fameux plus de RAM, toujours plus de RAM, au lieu de traiter la fuite mémoire).

L’OS et les Applications

Dans le cas des ressources managées, surtout RDS, de très nombreux réglages sont à disposition pour paramétrer les moteurs (taille des buffers, allocation de tables temporaires, nombre max de connexions, etc). Les ajuster au réel besoin métier peut parfois changer du tout au tout les performances.

Pour les EC2, c’est encore plus vrai, car on peut jouer sur bien plus de réglages comme:

les paramètres sysctl: Tous les OS Unix-Like permettent de régler des paramètres du kernel, dont beaucoup de limites. En ajustant ces valeurs, on peut souvent repousser les capacités utilisables.
les configurations des applications: La majorité des applications, surtout dans le monde du Web OpenSource, permettent d’être configurées jusqu’au plus petit détails pour assurer leurs charges (worker_processes ou keepalives pour Nginx par exemple).

Compiler ses binaires

Une autre option, bien moins répandue, car plus difficile à mettre en oeuvre, est le fait d’utiliser des binaires compilés pour l’architecture CPU de l’EC2 utilisée. Cela peut paraître farfelu, surtout que cela apporte une grande complexité et sort totalement du cadre des gestionnaires de paquets si pratiques. Mais après tout, utiliser des binaires compilés en dehors de toute arborescence, c’est une chose très répandue, et cela s’appelle un Container 😉. AWS fournit pour chaque type d’Instance le modèle de CPU associé, à votre charge de trouver les bons flags à utiliser pour la compilation, et de penser à les modifier à chaque changement de type (par un exemple, un rendu Blender via le CPU peut gagner jusqu’à 30% de temps [du vécu], imaginez pour la capacité de traitements de requêtes par un Apache ou Nginx/PHP-FPM).

Utiliser les services managés

Utiliser des services managés a un coût, c’est indéniable, mais ils sont à relativiser et à mettre en perspective avec les coûts Indirects. Entre un PostgreSQL managé et un PostgreSQL installé à la main sur un serveur loué, il se peut que la solution du Cloud Provider soit plus chère, mais si vous rajoutez dans votre solution maison les coûts financiers et humains pour la gestion des backups, des possibles restaurations, de la haute disponibilité, etc, sans avoir en plus forcément la capacité de changer la taille de la machine ou agrandir son stockage, la balance ne penche plus du même côté. Encore une fois, s’arrêter uniquement aux coûts matériels (qui se rattachent aux coûts Directs) et ne pas prendre l’ensemble du périmètre financier, peut s’avérer contre-productif.

Mettre en place des outils, des procédures, des formations

Je conseille généralement de commencer par tout faire manuellement, que ce soit l’analyse des coûts dans le Cost Explorer, la recherche des gâchis ou l’estimation des économies possibles. Cela dans le but de vraiment comprendre comment les choses fonctionnent et de pouvoir repérer d’un coup d’oeil des axes d’améliorations une fois que l’habitude est faîte. Une fois rodé, il est temps de mettre en place des procédures, et si possible des outils automatisés pour limiter les dérives dans le temps. L’automatisation des procédures de nettoyage et d’extinction des environnements en dehors des heures ouvrées sont des grands classiques, on trouve de nombreux exemples sur le net. Comme évoqué plus haut, c’est à ce niveau que les alertes de Budget peuvent aussi apporter leurs aides, même si elles peuvent souvent s’avérer trop rigides (une période de soldes peut exploser les compteurs par rapport au mois d’avant, sans que cela soit inquiétant, bien au contraire). Un volet à ne pas négliger à cette étape (à toutes en fait), est de former les équipes (chez soi ou chez son client), à ce qu’est le FinOps, ce qu’il apporte et sur les procédures en cours dans l’entreprise qui font partie de son processus.

Architecturer pour réduire les coûts

C’est la méthode la plus complexe, mais souvent la plus efficace et gratifiante, la refonte. Les Cloud Providers sortent en permanence de nouvelles fonctionnalités et nouveaux services, ce qui est impossible aujourd’hui ne le sera possiblement plus dans 1 ou 2 ans. Intégrer le FinOps lors de la conception d’une plateforme est important pour être efficient, mais cela l’est encore plus lors des refontes, qui peuvent souvent être dictées pour des raisons de rationalisation et/ou d’économies. Cela est d’autant plus pertinent que vous avez alors une vraie expérience du comportement de votre plateforme, de ses besoins et contraintes.

On peut envisager dans le cas d’une refonte de:

migrer certaines fonctions dans Lambda
utiliser DynamoDB en base NoSQL
utiliser des ALB devant les Lambda et non des API Gateway

Il faut garder à l’esprit encore une fois, que toutes les actions ont des coûts Indirects (JH pour migrer le code d’une solution technique à une autre, formations, etc), et peuvent vous “verrouiller” chez un Cloud Provider, on touche là, à la politique de l’entreprise.

Politiqes de Scale In/Out

La capacité d’adapter la flotte de machines à la charge est une fonctionnalité de base, c’est presque la raison première de l’existence du Cloud. Avec le temps, que ce soit en natif ou via des fonctions externes, on peut piloter les groupes d’AutoScaling pour faire beaucoup de choses comme:

Retirer tout ou partie des machines en dehors des heures ouvrées
Changer la taille des Instances en fonction des périodes
Scale In/Out (ajouter/retirer) en fonction de métriques métiers et non juste le CPU (qui est rarement une métrique pertinente, je le rappelle)

Réservations / Saving Plans

Si vous êtes prêt à vous engager sur du long terme (1 ou 3 ans), réserver des ressources est le moyen le plus direct d’obtenir au moins 30% d’économie (avec versement d’un account ou non) sur des services tels que:

EC2
RDS
Elasticache
DynamoDB

Les cas de DynamoDB et Elasticache sont un peu particulier, le premier demandant de réserver des capacités en Read/Write et non des ressources “matérielles” et le second imposant un acompte dans tous les cas.

Pour rappel, les réservations fonctionnent avec des unités de temps, il ne s’agit pas de machines avec une étiquette à son nom dans le datacenter AWS.

Prenons un exemple pour expliciter les choses.

Imaginons que vous réserviez pour 1 an, pour de l’EC2, 1 “Instance” m5.xlarge. Vous obtenez donc, 4 unités (cf ce tableau) par mois dans la famille m5. En prenant qu’un mois fait en moyenne 732h, vous aurez donc le droit au prix réduit pour:

732h de m5.xlarge
1464h de m5.large (soit 2 Instances)
366h de m5.2xlarge (soit 1 Instance allumée la moitié du mois)

Les unités sont circonscrites à une famille, c’est exactement le même cas pour les Saving Plans de type EC2 Instance (les économies sont à la virgule près les mêmes que pour les Réservations). Si vous voulez ne pas être contraint, et ne raisonner qu’en termes d’unités de calcul et non de “famille”, les Saving Plans de type Compute, sont la nouvelle méthode pour procéder à des réservations chez AWS, peu importe la famille ou le type. Les réductions sur le Compute s’appliquant peu importe le type, cela vous permet de changer de famille quand vous le souhaitez. Cela vient cependant avec une économie moindre.

Spot Instances

AWS met à disposition son stock d’invendus (en quelque sorte) à prix cassé (jusqu’à -70%), ce qu’ils appellent des Spot Instances. Le principe est simple, vous définissez un prix maximal pour lequel vous êtes prêt à payer, et tant que le prix courant est inférieur et qu’AWS a du stock, vous êtes susceptible d’avoir votre Instance. Si un des critères n’est plus respecté, AWS vous prévient 2min avant de vous retirer l’Instance. Pour mitiger les risques, vous avez la possibilité de vous faire des flottes, c’est-à-dire des groupes d’Instances de différents types.

C’est un moyen extrêmement puissant pour faire des économies, à condition que l’usage que vous en faîtes tolère de perdre des noeuds, c’est donc très souvent utilisé pour faire des tests au sein d’une CI, par exemple.

Un autre aspect à prendre en compte et qui permet de limiter encore plus les risques, c’est de mixer des Instances On-Demand (payées au prix public annoncé) et des Instances Spot. C’est désormais possible avec les Launch Templates qui définissent comment doivent être les Instances d’un groupe d’Auto-Scaling. Vous définissez le nombre d’Instances On-Demand qui constitueront votre base, puis le pourcentage d’On-Demand au dessus cette base par rapport aux Instances Spot. Si votre base On-Demand correspond à vos réservations, l’économie est encore plus importante avec un risque contrôlé.

Organisation des comptes

La bonne pratique est d’isoler les environnements (prod, staging, etc) dans des comptes AWS différents. Isoler les comptes les uns des autres permet, entre autres:

d’assurer l’étanchéité pour la sécurité
de bien séparer les coûts, ce qui facilite les analyses (un flux sortant est un flux sortant, AWS ne vous dira pas de quelle VPC précisément il vient, difficile de refacturer entre cost centers dans ce cas)

A côté de cela il est très intéressant de regrouper tous ces comptes au sein d’une seule organisation, avec un compte payeur identifié (appelé compte consolidant) et ne possédant aucune ressource (pour simplifier les analyses, de cette manière il n’apparaîtra pas 2 fois, en tant que compte et compte consolidant).

Il y a plusieurs avantages à faire cela, le compte payeur agrégeant la totalité de la facture:

les réservations sont remontées au niveau du compte consolidant (sauf paramétrage volontaire), ce qui implique que les unités non utilisées d’un côté peuvent l’être de l’autre, vous ne payez pas pour rien
vous bénéficiez des tarifs sur les volumes (au sens de quantité), ce qu’on appelle les Blended Costs.
AWS fournit une facture récapitulative de l’ensemble des frais, ce qui fera plaisir au service comptable qui n’aura pas à gérer N pdf.

Les Blended Costs sont une manière d’agréger tous les volumes de certains services et de bénéficier ainsi des tranches de prix inférieures.

Prenons comme exemple S3 pour expliciter la chose.

Imaginons deux comptes liés A et B à un compte consolidant Z. Les usages S3 sont respectivement:

50To en eu-west-3 pour le compte A

30To en eu-west-3 pour le compte B

Si les comptes étaient facturés séparément, il devraient:

compte A: 40To x 0,024$/GB = $960

compte B: 30To x 0,024$/GB = $720

total: $1680

Avec les Blended Costs, le compte Z consolidant le tout paiera en fait:

50To x 0,024$/GB + 20To x 0,023$/GB = $1620

Le principe sous-jacent étant que pour S3, en eu-west-3, les 50 premiers To valent 0,024$/GB et 0,023$/GB au delà.

On a donc une économie de $60, sans aucune action autre qu’avoir lié les comptes A et B à Z.

(voir ICI pour les tarifs de S3)

Conclusion

Cet article n’est finalement qu’une ébauche de tout ce qu’on peut faire sans vraiment rentrer dans les détails de comment on le fait. Il ne représente qu’une synthèse de mes réflexions, dont les conclusions sont sûrement discutables (et peut-être obsolètes maintenant, le monde du Cloud bougeant tellement vite). Vous avez sûrement remarqué qu’il y a un grand absent dans cet article, quid du FinOps quand on utilise Kubernetes? A l’époque où je faisais encore des audits FinOps, bien qu’utilisant K8S en production, je n’avais jamais eu à creuser sérieusement la question. Je pense cependant que les principes généraux que j’ai mentionnés peuvent s’appliquer en partie, dans le cas d’un environnement avec des ressources mutualisées comme l’est Kubernetes.

Merci d’avoir lu jusqu’au bout ce long article, et j’espère qu’il aura été utile à quelqu’un, il m’a au moins permis de sortir de ma tête quelque chose qui y traînait depuis longtemps.

Enjoy

Falco: Détection et réaction aux menaces dans Kubernetes

Tue, 06 Apr 2021 00:00:00 +0000

J’ai enregistré il y a quelques jours une présentation traitant de falco et falcosidekick pour un Meetup CNCF Paris. J’y aborde ce que sont falco et falcosidekick et je montre comment on peut se servir des outputs de falcosidekick pour réagir en cas de détection de comportements suspects.

Enjoy

Monitorer son application Go en local

Sat, 27 Jun 2020 00:00:00 +0000

Récemment, après plusieurs jours en production, nous avons détecté au boulot que notre pod Cercat semblait avoir une memory leak.

Rien de complexe dans notre cas (ouf), cela a facilement été réglé à coup de profiles Go mais une question s’est posée : “Aurais-je pu le détecter avant d’envoyer en prod en sachant que l’évolution de la consommation mémoire était relativement lente?”

Je me suis donc mis en tête d’avoir une solution clé en main pour monitorer en local une application Go lors de son développement.

L’idée, très simple au final, est d’utiliser une instance de Netdata dans un Docker qui appelle l’endpoint expvar de mon application Go.

Micro tuto pour comprendre le principe :

Préparer notre application

Un micro code pour l’exemple :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


package main

import (
 "expvar" // package pour exposer les métriques Go par défaut et notre métrique custom
 "math/rand"
 "net/http"
 "time"
)

func main() {
 fake := expvar.NewFloat("custom.fake") // une métrique custom complètement fausse 
 go http.ListenAndServe(":1111", nil) // on démarre un serveur http sur le port 1111
 for { // une boucle qui met à jour aléatoirement notre métrique custom
 fake.Set((rand.Float64() * 10) - 5)
 time.Sleep(time.Duration(rand.Intn(3)) * time.Second)
 }
}

Le code est commenté pour comprendre à quoi sert chaque ligne.

On prépare la configuration de Netdata

go_expvar.conf

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


'golang-app':
 name : 'golang-app' # le nom de notre app Go dans Netdata
 url : 'http://golang-app:1111/debug/vars' # le port est à adapter en fonction de l'application
 collect_memstats: true # on active la collecte des métriques mémoires
 extra_charts: # la collecte de notre métrique custom
 - id: "custom"
 options:
 name: fake
 title: "custom"
 units: no-unit
 family: custom
 context: expvar.custom.fake
 chart_type: line
 lines:
 - {expvar_key: 'custom.fake', expvar_type: float, id: custom_fake}

python.d.conf

1

go_expvar: yes # active le monitoring des applications Go

On démarre le tout via docker-compose

docker-compose.yaml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


---
version: "3"
services:
netdata:
 image: netdata/netdata:latest
 container_name: netdata
 ports:
 - "19999:19999"
 volumes:
 - "${PWD}/python.d.conf:/etc/netdata/python.d.conf:ro" # pour activer le monitoring des applications GO
 - "${PWD}/go_expvar.conf:/etc/netdata/python.d/go_expvar.conf:ro" # pour configurer la collecte des métriques des applications Go
 - "/etc/passwd:/host/etc/passwd:ro"
 - "/etc/group:/host/etc/group:ro"
 - "/proc:/host/proc:ro"
 - "/sys:/host/sys:ro"
 - "/var/run/docker.sock:/var/run/docker.sock:ro" # pour moniter le Docker Go
 cap_add:
 - SYS_PTRACE
 security_opt:
 - apparmor:unconfined
golang-app:
 image: golang:alpine
 container_name: golang-app
 ports:
 - "1111:1111" # le port d'écoute de notre application, à adapter
 volumes:
 - "${PWD}:/app"
 working_dir: /app
 command: go run main.go  # la commande pour lancer l'application, à adapter

Le plus important est d’adapter le port d’écoute et la commande de démarrage en fonction de votre application.

On démarre tout :

1

docker-compose -f docker-compose.yaml up -d

On vérifie que tout est bien démarré :

1
2
3
4
5


$ docker ps

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
5f9a07fa2e1f netdata/netdata:latest "/usr/sbin/run.sh" About a minute ago Up About a minute (healthy) 0.0.0.0:19999->19999/tcp netdata
4e9d30d12bec golang:alpine "go run main.go" 5 days ago Up About a minute 0.0.0.0:1111->1111/tcp golang-app

L’instance Netdata est accessible via http://localhost:19999.

Après quelques secondes on obtient nos métriques.

Les métriques du container de notre application :

Les métriques expvar de notre application :

Notre métrique custom :

Mettre à jour notre application

C’est très simple, il suffit de redémarrer le container Go :
1

$ docker restart 4e9d30d12bec

Enjoy

Cercat

Fri, 17 Apr 2020 00:00:00 +0000

En cette période de confinement, les phishers s’en donnent à coeur joie. La question qui se pose alors est : Comment les détecter le plus tôt possible?

Comme les sites de phishing servent souvent à récupérer des données confidentielles (n° de carte, mots de passe, etc), ils profitent de toutes les méthodes récentes pour récupérer des certificats gratuits afin de se donner une belle image avec un joli cadenas dans la barre d’URL.

Quelques recherches sur ce sujet m’a fait découvrir un superbe projet de chez Calidog : CertStream. Ils mettent à disposition un flux donnant en temps réel les certificats émis par Let’s Encrypt, Cloudflare, AWS, …

Il ne reste plus qu’à s’y connecter, faire une correspondance des domaines avec une regexp pour avoir en temps réel, les possibles sites de phishing.

D’autres ont eu la même idée : CertStreamMonitor mais les performances m’ont déçu (100% d’utilisation permanente d’un CORE) et j’ai trouvé intéressant de le faire moi-même.

Je vous présente donc Cercat aka Certificate Catcher.

Le principe est simple, le service se connecte via websocket au stream de Certstream, compare le domaine certifié à une regexp et si il y a correspondance, un message est posté sur Slack :

et dans les logs :

1
2


2020/04/14 17:29:40 [INFO] : A certificate for 'www.XXXX.fr' has been issued : {"domain":"www.XXXX.fr","SAN":["www.XXXX.fr"],"issuer":"Let's Encrypt","Addresses":["XX.XX.XX.183","XX.XX.XX.182"]}
2020/04/14 17:29:41 [INFO] : A certificate for 'XXXX.fr' has been issued : {"domain":"XXXX.fr","SAN":["mail.XXXX.fr","XXXX.fr","www.XXXX.fr"],"issuer":"Let's Encrypt","Addresses":["XX.XX.XX.108"]}

La configuration est dans le README et des binaires pré-compilés sont fournis ICI parce que je suis gentil.

En faisant des tests sur les domaines en .fr je suis d’ailleurs tombé sur ça, un bel exemple de phishing :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


{
 "domain":"google-france.fr",
 "SAN":[
 "eset.fr.nf",
 "google-france.fr",
 "page-accueil.info",
 "www.eset.fr.nf",
 "www.google-france.fr",
 "www.page-accueil.info"
 ],
 "issuer":"Let's Encrypt",
 "Addresses":[
 "X.X.X.24"
 ]
}

En espérant que ça serve à d’autres.

Enjoy

Falcosidekick 100k Pulls

Tue, 18 Feb 2020 00:00:00 +0000

Un petit post d’auto-promo (après des mois d’absences…).

J’ai noté récemment que mon petit falcosidekick a dépassé les 100000 pulls sur le DockerHub. Je suis bluffé, surtout que je sais que des entités grosses et connues l’utilisent (je ne sais pas si je peux dire qui, donc je me tais, sorry).

Un petit graphe pour montrer l’historique (la légende est illisible, mais les dates sont obtenables en survolant) :

Merci à tous ceux qui l’utilisent et bien sûr à toute l’équipe derrière falco. J’ai d’autres idées en réserve pour améliorer, j’espère avoir le temps de m’y atteler.

Enjoy

Falcosidekick 2.9.0 : nouvelle intégration et nouvel avatar

Sat, 05 Oct 2019 00:00:00 +0000

Je viens de sortir la version 2.9.0 de falcosidekick et en outre un nouvel output, Opsgenie, j’ai également refait l’avatar du projet. Il est désormais en couleurs et a une forme globale carrée, pour faciliter l’utilisation en icône (Slack, Teams, …).

Voilà le résultat :

Ce qui donne ceci dans Slack :

En ce qui concerne Opsgenie, voilà le résultat :

Le repo Github et l’image sur le DockerHub.

Enjoy

Falco Probes

Mon, 23 Sep 2019 00:00:00 +0000

Je traîne pas mal sur le slack de sysdig, où on parle bien entendu de falco. Un problème très récurrent des utilisateurs est l’existence ou non de modules kernel précompilés pour leurs versions de kernel.

Quand le module n’est pas présent sur la machine hôte, l’installeur tente de le télécharger depuis un bucket S3, c’est pratique, mais étant donné l’immense variété d’architectures et de versions de kernel dans la nature, impossible de tous les avoir tout prêts au chaud sur S3. Jusqu’à présent, la seule manière pour savoir si la version du module pour son kernel est présente ou non sur le bucket est d’aller sur la page indigeste qui est celle-ci : https://s3.amazonaws.com/download.draios.com/stable/sysdig-probe-binaries/index.html

Pas très pratique (ça oblige à faire du ctrl+F pour recherhcer) et surtout la page est de plus en plus volumineuse.

J’ai donc codé un petit machin qui parse cet index et ressort le tout sous forme de tableaux dans lequels on peut chercher et également transmettre les diens vers les modules.

Le domaine est temporaire jusqu’à nouvel ordre : https://thomas.labarussias.fr/falco-probes/?falcoversion=0.17.0

En espérant que ça serve à quelqu’un d’autre que moi, en tout cas c’est très pratique pour vérifier si les soucis d’installation de falco d’une personne viennent de l’absence du module ou non.

Enjoy

Chart XKCD

Thu, 12 Sep 2019 00:00:00 +0000

Je suis tombé chart.xkcd parmi les flux RSS que je suis. J’ai trouvé l’idée amusante et le rendu agréable, j’en ai donc fait un micro shortcode pour Hugo :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


<div>
<svg class='{{ .Get "name" }}'></svg>
<script src="https://cdn.jsdelivr.net/npm/chart.xkcd@1/dist/chart.xkcd.min.js"></script>
<script>
 const svg{{ .Get "name" | safeJS }} = document.querySelector('.{{ .Get "name" }}');
 new chartXkcd.{{ .Get "type" | safeJS }}(svg{{ .Get "name" | safeJS }}, {
 {{ .Inner | safeJS }}
 });
</script>
</div>

A caler dans layout/shortcodes/chart-xkcd.html.

Trois types de diagrammes sont dispos pour le moment : Line, Pie, Bar, XY, Radar.

Les options de chaque diagramme sont trouvables dans la doc.

Exemples

Line

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


{{< chart-xkcd name="line" type="Line" >}}
 title: 'A vs B',
 xLabel: 'Abscisse',
 yLabel: 'Ordonnee',
 data: {
 labels:['1', '2', '3', '4', '5', '6','7', '8', '9', '10'],
 datasets: [{
 label: 'A',
 data: [30, 2500, 200, 300, 250 ,800, 1500, 2900, 5000, 800],
 }, {
 label: 'B',
 data: [0, 1, 30, 70, 80, 100, 50, 80, 40, 150],
 }]
 },
 options: { // optional
 yTickCount: 10,
 }
{{< /chart-xkcd >}}

Pie

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


{{< chart-xkcd name="pie" type="Pie" >}}
 title: 'A B C D E',
 data: {
 labels:[ 'A', 'B', 'C', 'D', 'E'],
 datasets: [{
 data: [200, 122, 60, 130, 44,],
 }]
 },
 options: {
 innerRadius: 0.5, // mettre à 0 pour obtenir un diagramme camembert (pie chart)
 legendPosition: chartXkcd.config.positionType.upRight,
 }
{{< /chart-xkcd >}}

Bar

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


{{< chart-xkcd name="bar" type="Bar" >}}
 title: "A B C D",
 data: {
 labels:['A', 'B', 'C', 'D'],
 datasets: [{
 data: [20, 33, 5, 12],
 }]
 },
 options: { // optional
 yTickCount: 8,
 }
{{< /chart-xkcd >}}

XY

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


{{< chart-xkcd name="xy" type="XY" >}}
 title: 'A vs B',
 xLabel: 'Abscisse',
 yLabel: 'Ordonnee',
 data: {
 datasets: [{
 label: 'A',
 data: [{ x: 1, y: 30 }, { x: 3, y: 8 }, { x: 5, y: 45 }, { x: 7, y: 22 }, { x: 9, y: -4 }],
 }, {
 label: 'B',
 data: [{ x: -2, y: 12 }, { x: 4, y: -20 }, { x: 6, y: 53 }, { x: 8, y: 12 }, { x: 10, y: 20 }],
 }],
 },
 options: {
 xTickCount: 10,
 yTickCount: 10,
 showLine: false,
 dotSize: 1,
 }
{{< /chart-xkcd >}}

Avec options: {showLine: true} :

Radar

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


{{< chart-xkcd name="radar" type="Radar" >}}
 title: 'A vs B',
 data: {
 labels: ['a', 'b', 'c', 'd', 'e'],
 datasets: [{
 label: 'A',
 data: [4, 1, 3, 3, 2],
 }, {
 label: 'B',
 data: [1, 4, 2, 3, 1],
 }],
 },
 options: {
 showLegend: true,
 dotSize: .7,
 showLabels: true,
 },
{{< /chart-xkcd >}}

Falcosidekick 2.8.0

Wed, 11 Sep 2019 00:00:00 +0000

Nouvelle release, la 2.8.0, de mon proxy pour falco.

La grosse feature étant l’ajout de NATS (une message queue en Go) comme sortie.

Le repo Github et l’image sur le DockerHub.

Enjoy

Utiliser k3d pour avoir un cluster k8s en local

Thu, 05 Sep 2019 00:00:00 +0000

Afin de parfaire mes connaissances sur kubernetes, aka k8s pour les intimes, j’avais envie de monter un cluster sur mon laptop, pas juste un noeud tout seul. Jusqu’à présent je n’avais testé que des solutions pour avoir des k8s mono-noeud, c’est sympa, mais trop éloigné de la réalité, surtout si on veut tester des méthodes de résilience, d’auto-scaling de pods, de deployments, de daemonset, etc.

Et là, la révélation ! Je connaissais déjà k3s, le k8s ultra allégé de chez rancher et il s’avère qu’ils ont développé un petit utilitaire pour monter un cluster dans des containeurs docker avec, le bien nommé k3d.

Après plusieurs heures de tests, je suis emballé, c’est ultra rapide, ultra light et ça fonctionne avec tous les outils classiques. Un ingress controller basé sur traefik est directement déployé, donc on a de base un environnement fonctionnel. Simple. Efficace.

Installation de k3d

Rien de compliqué pour l’installer, plusieurs méthodes sont fournies sur le repo Github officiel. Comme c’est du go, aucune dépendance. Easy.

Créer son premier cluster

1

~ $ k3d create -n mon-cluster-test --publish 80 --publish 8080 --publish 443 -w 2

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


2019/09/05 23:16:34 Created cluster network with ID cae80bddca7cf614494b9d97f7d6edf2b14d45864ef1aa0b1a899a93122ecc1b
2019/09/05 23:16:34 Created docker volume k3d-mon-cluster-test-images
2019/09/05 23:16:34 Creating cluster [mon-cluster-test]
2019/09/05 23:16:34 Creating server using docker.io/rancher/k3s:v0.7.0...
2019/09/05 23:16:34 Pulling image docker.io/rancher/k3s:v0.7.0...
2019/09/05 23:16:47 Booting 2 workers for cluster mon-cluster-test
2019/09/05 23:16:48 Created worker with ID b0c019c001376c9aa07f8fb65b52da1b2d52fbe61f25cb24c7198c5b122a2a09
2019/09/05 23:16:49 Created worker with ID a9d959899a2119606248bf8dd5d681f05efb7232d19c5f8206ffb5025f10885b
2019/09/05 23:16:49 SUCCESS: created cluster [mon-cluster-test]
2019/09/05 23:16:49 You can now use the cluster with:

export KUBECONFIG="$(k3d get-kubeconfig --name='mon-cluster-test')"
kubectl cluster-info

Sur ma machine, l’exécution a pris environ 20s, en sachant que 95% du temps est lié la récupération de l’image k3s. Impressionnant.

Une petite explication des arguments :

-n : le nom de notre cluster k8s
--publish 80 --publish 8080 --publish 443 : les ports qu’on va exposer, comme c’est fait avec la commande docker run
-w 2 : le nombre de workers qu’on veut

On peut lister nos clusters :

1
2
3
4
5
6


~ $ k3d ls
+------------------+------------------------------+---------+---------+
| NAME | IMAGE | STATUS | WORKERS |
+------------------+------------------------------+---------+---------+
| mon-cluster-test | docker.io/rancher/k3s:v0.7.0 | running | 2/2 |
+------------------+------------------------------+---------+---------+

L’image est effectivement de taille réduite (proportionnellement aux autres solutions) :

1
2


REPOSITORY TAG IMAGE ID CREATED SIZE
rancher/k3s v0.7.0 f1ec9d3fbf66 6 weeks ago 119MB

Se connecter au cluster

Comme précisé dans les logs de création, on peut récupérer le kubeconfig associé pour utiliser les outils classiques (kubectl, k9s, helm, etc) :

1

~ $ export KUBECONFIG="$(k3d get-kubeconfig --name='mon-cluster-test')"

1
2
3
4
5


~ $ kubectl get nodes
NAME STATUS ROLES AGE VERSION
k3d-mon-cluster-test-server Ready master 2m v1.14.4-k3s.1
k3d-mon-cluster-test-worker-0 Ready worker 2m v1.14.4-k3s.1
k3d-mon-cluster-test-worker-1 Ready worker 2m v1.14.4-k3s.1

Premier déploiement

Afin de tester tout cela, nous allons appliquer un premier deployment et tenter d’y accéder. Cela sera un simple micro-service qui nous répondra quelques infos sur lui-même (sur quel noeud il tourne, son nom, le contenu de la requête HTTP qu’il a reçue, etc). Le container qui sera utilisé est fourni par ailleurs par ceux derrière traefik : containous/whoami.

Création d’un namespace dédié

1

~ $ kubectl create namespace whoami

C’est juste histoire de bien segmenter les choses.

Application du deployment

1

~ $ kubectl create deployment whoami --image=containous/whoami -n whoami

Scaling du replicaSet

Nous avons un cluster à 2 noeuds, ça serait dommage de n’avoir qu’un seul pod, augmentons à 2 le replicaSet associé :

1

~ $ kubectl scale --replicas 2 deployment/whoami -n whoami

1
2
3


~ $ kubectl get rs -n whoami
NAME DESIRED CURRENT READY AGE
whoami-756586b9ff 2 2 2 4m33s

Création du service

Nous avons 2 pods, nous allons créer un service pour avoir une répartition de charge :

1

~ $ kubectl create service clusterip whoami --tcp=80:80 -n whoami

Création de l’ingress

Tout est prêt au sein de notre cluster, il est temps de nous permettre d’accéder à notre micro-service, on va utiliser une ressource de type ingress :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


~ $ cat <<EOF | kubectl apply -n whoami -f -
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
 name: whoami
 annotations:
 ingress.kubernetes.io/ssl-redirect: "false"
spec:
 rules:
 - http:
 paths:
 - path: /
 backend:
 serviceName: whoami
 servicePort: 80
EOF

Testons le micro-service

A la création du cluster, nous avons publier le port 80 au niveau de l’host, il est temps de trouver le port qui a été associé (bind) :

1

~ $ docker inspect --format='{{range $p, $conf := .NetworkSettings.Ports}} {{$p}} -> {{(index $conf 0).HostPort}} {{end}}' $(docker ps --filter "name=k3d-mon-cluster-test-server" -q)

1

443/tcp -> 32810 6443/tcp -> 6443 80/tcp -> 32811 8080/tcp -> 32809

L’ingress écoute sur le port 80, le port associé est donc le 32811 dans mon cas. Faisons plusieurs appels et vérifions :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37


~ $ curl http://localhost:32811
Hostname: whoami-756586b9ff-4mqb6
IP: 127.0.0.1
IP: ::1
IP: 10.42.2.4
IP: fe80::a89f:5eff:fef5:d426
RemoteAddr: 10.42.1.3:36824
GET / HTTP/1.1
Host: localhost:32811
User-Agent: curl/7.47.0
Accept: */*
Accept-Encoding: gzip
X-Forwarded-For: 10.42.1.1
X-Forwarded-Host: localhost:32811
X-Forwarded-Port: 32811
X-Forwarded-Proto: http
X-Forwarded-Server: traefik-56688c4464-wlk2r
X-Real-Ip: 10.42.1.1

~ $ curl http://localhost:32811
Hostname: whoami-756586b9ff-6wn52
IP: 127.0.0.1
IP: ::1
IP: 10.42.0.4
IP: fe80::7c0f:1fff:fe2b:bcb2
RemoteAddr: 10.42.1.3:41180
GET / HTTP/1.1
Host: localhost:32811
User-Agent: curl/7.47.0
Accept: */*
Accept-Encoding: gzip
X-Forwarded-For: 10.42.1.1
X-Forwarded-Host: localhost:32811
X-Forwarded-Port: 32811
X-Forwarded-Proto: http
X-Forwarded-Server: traefik-56688c4464-wlk2r
X-Real-Ip: 10.42.1.1

Nous avons bien 2 réponses différentes :

1
2
3
4
5


Hostname: whoami-756586b9ff-4mqb6
IP: 10.42.2.4

Hostname: whoami-756586b9ff-6wn52
IP: 10.42.0.4

Qui correspondent à nos 2 pods :

1
2
3
4


~ $ kubectl get pods -n whoami
NAME READY STATUS RESTARTS AGE
whoami-756586b9ff-4mqb6 1/1 Running 0 24m
whoami-756586b9ff-6wn52 1/1 Running 0 20m

Enjoy

Falcosidekick fait désormais partie de l'organisation Falcosecurity

Wed, 28 Aug 2019 00:00:00 +0000

Les mainteneurs de falco m’ont proposé de migrer falcosidekick au sein de l’organisation officielle falcosecurity. Il devient donc un projet officiel 🎉😍.

Le repo Github et l’image sur le DockerHub.

Au passage, j’ai sorti la 2.7.1 qui met à jour la version de Go utilisée (1.12).

Enjoy

Falcosidekick 2.7.0

Tue, 27 Aug 2019 00:00:00 +0000

Nouvelle release, la 2.7.0, de mon proxy pour falco.

La grosse feature étant l’ajout de Loki comme sortie :

Le repo Github et l’image sur le DockerHub.

Enjoy

Falcosidekick 2.6.0

Mon, 26 Aug 2019 00:00:00 +0000

Nouvelle release, la 2.6.0, de mon proxy pour falco.

La grosse feature étant l’ajout du SMTP (envoi d’email) comme sortie :

Afin de respecter les standards, la version html contient également la version plaintext. Il est aussi possible d’envoyer uniquement la version plaintext, utile pour certains systèmes de ticketing qui utilisent l’email pour la création.

Le repo Github et l’image sur le DockerHub.

Enjoy

Proxifier Traefik par Traefik

Mon, 26 Aug 2019 00:00:00 +0000

Traefik possède une UI basique qui est par défaut exposée sur un port différent. Il est possible de faire en sorte que Traefik serve lui même de proxy, cela permet :

ne plus avoir à utiliser un port différent pour accéder l’UI, mais un domaine classique ("traefik.mondomaine.net" par ex.)
forcer l’accès en https avec en prime un certificat Let’s Encrypt automatique et gratuit
permettre de rajouter une authentification, par défaut, l’UI est ouverte à tout une fois activée

Dans mon cas, je fais tourner Traefik dans un container, mais ça marchera pareil si vous le faîtes tourner directement sur l’host, prenez juste soin de filtrer le port de l’UI (8080 par défaut) pour qu’il n’accepte que les connexions de la boucle local (127.0.0.1).

Voilà ce qu’il faut avoir à minima dans sa configuration config.toml :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61


################################################################
# Configuration globale
################################################################

defaultEntryPoints = ["http", "https"]

[entryPoints]
 [entryPoints.http]
 address = ":80" # traefik ecoute sur le port 80
 [entryPoints.http.redirect]
 entryPoint = "https" # redirection http > https
 [entryPoints.https]
 address = ":443" # traefik ecoute sur le port 443
 [entryPoints.https.tls]
 minVersion = "VersionTLS12" # version minimum de TLS acceptee
 [entryPoints.ui]
 address="127.0.0.1:8080" # on ecoute uniquement sur la boucle locale pour ce port
 [entryPoints.ui.auth]
 [entryPoints.ui.auth.basic]
 users = ["XXXX:YYYY"] # les identifiants au format htpasswd

################################################################
# Configuration pour let's encrypt
################################################################

[acme]
email = "xxx@yyy.zzz" # votre mail pour lets encrypt
storage = "/certs/acme.json"
entryPoint = "https"
onDemand = true # demande automatique de certificat
acmeLogging = true
 [acme.httpChallenge]
 entryPoint = "http"

################################################################
# Configuration de l'API de Traefik
################################################################

[api]
entryPoint = "ui" # l API ecoutera sur cet entrypoint
dashboard = true
 [api.statistics]
 recentErrors = 50

################################################################
# Configuration pour l'UI de Traefik
################################################################

[file]

[frontends]
 [frontends.ui]
 backend = "ui"
 passHostHeader = true
 [frontends.ui.routes.default]
 rule = "Host:ui.mondomaine.net" # votre domaine a configurer

[backends]
 [backends.ui]
 [backends.ui.servers.default]
 url = "http://127.0.0.1:8080" # le backend a utiliser qui s avere etre l entrypoint de l API

Enjoy

Conversion de Types en Go

Wed, 21 Aug 2019 00:00:00 +0000

int64 🠮 string

FormatInt

1

strconv.FormatInt(i int64, base int)

Itoa

1
2


strconv.Itoa(i int)
// Itoa is equivalent to FormatInt(int64(i), 10). 

string 🠮 int64

ParseInt

1

strconv.ParseInt(s string, base int, bitSize int)

Atoi

1
2


strconv.Atoi(s string)
// Atoi is equivalent to ParseInt(s, 10, 0), converted to type int. 

string 🠮 Time

Pour le layout.
Pour la location.

Parse

1

time.Parse(layout, value string)

ParseInLocation

1

time.ParseInLocation(layout, value string, loc *Location)

Time 🠮 string

Pour le layout.

Time.Format

1
2


var t time.Time
t.Format(layout string)

Décoder du base64 en Go

Mon, 19 Aug 2019 00:00:00 +0000

Je tentais de décoder la partie payload d’un token JWT (https://scotch.io/tutorials/the-anatomy-of-a-json-web-token) quand j’ai eu l’erreur suivante :

1

panic: illegal base64 data at input byte 349

Ma façon de faire était pourtant classique et a toujours fonctionné auparavant :

1

base64.StdEncoding.DecodeString(s)

Et le décodage du string via un autre outil ne posait pas de souci. 😧

La solution se trouvait une fois de plus dans la documentation de Go : https://golang.org/pkg/encoding/base64/#pkg-variables

Il existe plusieurs fonctions de décodage qui prennent ou non en compte les caractères de padding, en changeant pour :

1

base64.RawStdEncoding.DecodeString(s)

Mon payload était décodé.

👍

A propos

Mon, 01 Jan 0001 00:00:00 +0000

Mon profil Linkedin

TL;DR:

Ingénieur diplômé des Arts & Métiers en conception mécanique et gestion de production industrielle
Utilisateur de GNU/Linux depuis 2 décennies
Passionné de métrologie/monitoring
Fondamentalement un OPS (DevOPS/SRE)
7 ans d’astreinte
FinOps
Go developer
OSS contributor
DevRel
Speaker

Search

Mon, 01 Jan 0001 00:00:00 +0000

Talks

Mon, 01 Jan 0001 00:00:00 +0000

A titres personnel et professionnel, j’ai eu le privilège au cours des années de donner de nombreuses conférences et de participer à des podcasts en tant qu’invité.

Vous trouverez ci-dessous une liste (non exhaustive) de ces conférences et podcasts dont les captations sont en ligne.

2025

2024

2023

2022

2021

2020

🇫🇷 La sécurité dans tous ses états — détection de comportements indésirables grâce à Falco (Electro Monkeys)

Thomas Labarussias

Le FinOps

Avant-propos

Définition

Trouver le bon dosage entre HA, Perfs et Coûts

Un autre critère à prendre en compte: la Sécurité

Ajuster ses critères

Coûts et modèles de facturation

Les coûts Directs

Les coûts Indirects

FinOps, un processus

Un processus continue

Un processus itératif

Un processus à complexité croissante

Outillage

Les Factures

AWS Cost Explorer/Trusted Advisor

Les Scripts

SaaS

Websites

Schémas

La Métrologie

Beaucoup d’actions possibles

Catégoriser les actions à entreprendre

Identifier et supprimer les gâchis

Utiliser correctement les ressources

Les ressources managées

L’OS et les Applications

Compiler ses binaires

Utiliser les services managés

Mettre en place des outils, des procédures, des formations

Architecturer pour réduire les coûts

Politiqes de Scale In/Out

Réservations / Saving Plans

Spot Instances

Organisation des comptes

Tags

Conclusion

Falco: Détection et réaction aux menaces dans Kubernetes

Monitorer son application Go en local

Cercat

Falcosidekick 100k Pulls

Falcosidekick 2.9.0 : nouvelle intégration et nouvel avatar

Falco Probes

Chart XKCD

Exemples

Line

Pie

Bar

XY

Radar

Falcosidekick 2.8.0

Utiliser k3d pour avoir un cluster k8s en local

Installation de k3d

Créer son premier cluster

Se connecter au cluster

Premier déploiement

Création d’un namespace dédié

Application du deployment

Scaling du replicaSet

Création du service

Création de l’ingress

Testons le micro-service

Falcosidekick fait désormais partie de l'organisation Falcosecurity

Falcosidekick 2.7.0

Falcosidekick 2.6.0

Proxifier Traefik par Traefik

Conversion de Types en Go

int64 🠮 string

FormatInt

Itoa

string 🠮 int64

ParseInt

Atoi

string 🠮 Time

Parse

ParseInLocation

Time 🠮 string

Time.Format

Décoder du base64 en Go