Le gaspillage du cloud, c'est un peu le secret de polichinelle du devops. Tout le monde sait qu'il y a des volumes EBS détachés qui traînent, des snapshots vieux de 6 mois, des Elastic IP à 3,65 $/mois qui servent à rien... mais bon, on nettoie pas. Parce qu'on a trop les miquettes de casser un truc en prod. Mais entre le volume de 500 Go "temporaire" créé en 2024 et le NAT Gateway qui facture 32 $/mois dans le vide, ça chiffre assez vite.
CleanCloud
va vous permettre de remédier à ça. Il s'agit d'un petit CLI Python compatible Linux, macOS et Windows (dispo via pip ou pipx) qui va scanner vos comptes AWS et Azure pour débusquer toutes ces ressources orphelines. Le truc, c'est qu'il tourne uniquement en lecture seule, donc pas de mutation, pas de suppression, et zéro modification de tags. Lui se contente de regarder, de prendre des notes, et de vous sortir un bon vieux report.json ou CSV avec tout le détail.
Du coup, côté permissions IAM, c'est le strict minimum... 14 permissions en lecture seule type ec2:Describe*, s3:List* ou rds:DescribeDBInstances. C'est d'ailleurs bien fichu puisque le code vérifie statiquement via AST qu'aucun appel en écriture ne passe. Donc pas besoin de filer vos clés IAM à un outil tiers, et ça c'est plutôt rassurant pour les équipes sécu qui flippent (à juste titre) dès qu'on parle d'accès cloud.
L'outil embarque 20 règles de détection. 10 pour AWS, 10 pour Azure. Côté AWS, ça scanne comme vous l'aurez deviné les volumes EBS non attachés, les vieux snapshots, les logs CloudWatch en rétention infinie, les Elastic IP orphelines, les ENI détachées, les AMI créées en 2022 qui traînent, les NAT Gateways au repos, les instances RDS à l'arrêt...etc.
Côté Azure, même combat avec les disques managés, les IP publiques inutilisées, les VMs stoppées qui continuent de bouffer du stockage Premium SSD.
Pour chaque trouvaille, vous avez un score de confiance (LOW, MEDIUM, HIGH) et une estimation du coût mensuel gaspillé en dollars. En fait c'est assez bien foutu, le rapport vous donne le type de ressource, la région, l'âge du truc et combien ça vous coûte.
Hop, un pipx install cleancloud et c'est parti :
Connexioncleancloud scan --provider aws --all-regions
Y'a même un mode démo sans aucun credential requis, histoire de voir la tête du rapport JSON avant de brancher vos vrais comptes. Perso, je trouve ça bien pour voir à quoi ça ressemble :
cleancloud demo
Et pour ceux qui veulent aller plus loin, le scanner s'intègre dans vos pipelines CI/CD. GitHub Actions, Azure DevOps, Docker CI, peu importe. Vous collez un --fail-on-cost 100 (exit code 2 si le gaspillage dépasse 100 $/mois) ou un --fail-on-confidence HIGH et hop, le build pète si y'a du déchet. De quoi automatiser le ménage. Vous mettez juste cette commande dans votre CI et c'est plié.
D'ailleurs, la config supporte aussi le filtrage par tags. Vous créez ce fichier cleancloud.yaml à la racine de votre projet, vous excluez vos ressources de prod tagguées env:production, et le scan ignore ce qui doit l'être. Attention par contre, si vos ressources sont mal tagguées (et on sait tous que c'est souvent le cas...), le filtre ne servira à rien.
Côté sécurité, l'outil ne fait aucun appel vers des serveurs tiers et cause uniquement avec les API AWS et Azure de vos propres comptes, et supporte aussi l'auth OIDC avec des credentials temporaires. Voilà même si c'est un projet super jeune encore, c'est plutôt bien pensé pour les environnements corporate. C'est sous licence MIT et le code Python est sur GitHub donc tout est vérifiable.
Bref, si votre facture cloud vous pique les yeux, un pip install cleancloud et comme ça, vous en saurez plus... C'est gratuit, c'est open source, et surtout ça ne casse rien !
Ansible, c'est bien. Mais du YAML à perte de vue pour configurer trois serveurs c'est pas non plus l'idéal. Hé bien ça tombe bien car y'a maintenant pyinfra , qui fait tout pareil sauf qu'on écrit du Python. En gros, votre script de déploiement c'est juste du code Python normal avec des imports, des boucles, des conditions... tout ça, tout ça...
Ce projet existe depuis 2014, il est sous licence MIT et côté perfs, c'est de ce que j'ai lu, jusqu'à 10 fois plus rapide qu'Ansible sur des déploiements massifs (genre plusieurs milliers de machines). Bon, sur le papier c'est bien, mais en fait ça dépend surtout de votre infra SSH et de la latence réseau.
Alors ça marche comment ?
Hé bien vous installez le bazar avec uv tool install pyinfra et hop, vous pouvez déjà lancer des commandes sur vos serveurs comme ceci :
pyinfra mon-serveur.net exec -- echo "hello world"
Ça fonctionne en SSH sur le port 22, sur des conteneurs Docker, ou même en local. Le truc est complètement agentless, du coup pas besoin d'installer quoi que ce soit sur les machines cibles. Suffit d'un accès shell POSIX tout ce qu'il y a de plus classique et c'est réglé.
Bon, ça c'est pour l'ad-hoc mais en fait le vrai kiff, ce sont les opérations déclaratives. Je vous montre... Vous créez un fichier deploy.py et dedans, vous mettez ça :
from pyinfra.operations import apt, systemd
apt.packages(
name="Install nginx",
packages=["nginx"],
)
systemd.service(
name="Ensure nginx is running",
service="nginx.service",
running=True,
enabled=True,
)
C'est du bon vieux Python sans DSL bizarre (Domain-Specific Language), pas d'indentation YAML qui vous pète entre les doigts à 3h du mat parce qu'il manque un espace. Et si vous voulez une boucle ? bah for. Une condition ? bah if. Ou encore importer
boto3 pour causer avec AWS
depuis votre Debian 12 ? No problemo !
Et pour cibler vos machines, suffit de créer un fichier inventory.py comme ceci :
targets = ["@docker/ubuntu", "mon-serveur.net", "autre-serveur.net"]
Puis ensuite un petit : pyinfra inventory.py deploy.py et c'est parti mon kiki. L'outil gère le parallélisme sur 50 serveurs, les diffs (pour voir ce qui va changer AVANT d'appliquer), et le mode dry-run pour les plus prudents.
Côté intégrations, ça cause avec Terraform, Docker, Vagrant... et comme c'est du Python, vous avez accès à tout l'écosystème. Genre, vous voulez checker l'état d'une API avant de déployer ? Un import requests et c'est plié. La doc sur
docs.pyinfra.com
est plutôt complète, et y'a même la gestion des secrets intégrée avec variables d'environnement, fichiers chiffrés, HashiCorp Vault ou AWS Secrets Manager.
Ça tourne depuis Linux et macOS (et Windows via WSL), mais les cibles doivent être des systèmes POSIX donc pas de déploiement natif sur Windows. Et si votre inventaire contient 3 000 machines avec des configs SSH différentes... bon courage pour le debug en cas de souci (le mode -vvv aide, mais bon...).
Bref, si vous en avez marre du YAML et que Python c'est votre truc, allez jeter un oeil.
Merci à Letsar pour la découverte !
À l’heure où les infrastructures deviennent de plus en plus éphémères et complexes, les méthodes de monitoring traditionnelles atteignent leurs limites. De l’émergence de l’eBPF, qui permet une visibilité profonde et sans agent au cœur du noyau Linux, à l’adaptation de l’observabilité pour le Serverless, les entreprises basculent vers un modèle « as-Code ».
Cette convergence technologique ne se contente plus de surveiller la disponibilité des services ; elle intègre la donnée de performance dès la conception logicielle (Observability-as-Code), transformant l’infrastructure invisible en un système transparent, automatisé et hautement résilient.
Cet article sur l’eBPF (Extended Berkeley Packet Filter) explique comment cette technologie révolutionne le DevOps. Traditionnellement, pour surveiller un système, il fallait modifier le code de l’application ou charger des modules noyau risqués.
> Le concept : eBPF permet d’exécuter des programmes directement dans le noyau Linux de manière sécurisée, sans changer une seule ligne de code applicatif.
> L’avantage DevOps : Une visibilité totale sur le réseau, la sécurité et les performances avec un impact quasi nul sur les ressources. C’est la fin des agents « lourds » qui ralentissent les serveurs.
A lire : https://www.silicon.fr/cloud-1370/ebpf-devops-225348
Cet article traite de la complexité du Serverless (comme AWS Lambda). Puisque vous ne gérez plus le serveur, vous perdez l’accès aux métriques matérielles classiques.
> Le problème : Les fonctions sont éphémères (elles apparaissent et disparaissent en quelques millisecondes). Les outils de monitoring classiques sont souvent trop lents pour les capturer.
> La solution : Le traçage distribué. L’accent est mis sur le suivi de la requête à travers tous les services plutôt que sur la santé d’un serveur spécifique.
A lire : https://www.silicon.fr/cloud-1370/observabilite-serverless-225361
Cet article prône l’intégration de l’observabilité directement dans le cycle de développement, au même titre que l’Infrastructure-as-Code (Terraform, CloudFormation).
> L’idée : Au lieu de configurer manuellement des alertes et des tableaux de bord après le déploiement, vous les définissez dans votre code YAML ou JSON.
> L’objectif : Garantir que chaque nouveau microservice est « né » avec ses propres outils de mesure, évitant ainsi les angles morts lors des mises en production rapides.
A lire : https://www.silicon.fr/cloud-1370/observability-as-code-225520
The post Observabilité native : la nouvelle frontière du Cloud et du DevOps appeared first on Silicon.fr.
