kumo : un émulateur de services AWS léger en Go
Un émulateur de service AWS léger écrit en Go. Fonctionne à la fois comme un outil de test CI/CD et comme un serveur de développement local avec persistance des données en option.
En bref
- De quoi s’agit-il ?
- Un émulateur AWS en mémoire avec 82 services, persistance optionnelle et prise en charge de Docker.
- À qui s’adresse-t-il ?
- kumo est un émulateur AWS autonome qui couvre 82 services, prend en charge le déploiement Docker et binaire, et offre une persistance optionnelle. Ses points de terminaison de test personnalisés pour SES et Pinpoint SMS sont une caractéristique distinctive.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 1 jour.
- En quel langage est-il écrit ?
- Principalement Go, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Un émulateur AWS basé sur Go pour CI/CD et développement local
kumo est un émulateur de services AWS léger écrit en Go, positionné par le README à la fois comme outil de test CI/CD et comme serveur de développement local. Les métadonnées du dépôt indiquent le langage Go et la description correspond. Le README met en évidence plusieurs fonctionnalités : aucune authentification n'est requise, ce qui convient aux environnements CI ; il est distribué sous forme de binaire unique ; il prend en charge Docker ; il est léger avec un démarrage rapide et une utilisation minimale des ressources ; il est compatible avec le SDK AWS v2 pour Go ; et il peut éventuellement persister les données lorsque KUMO_DATA_DIR est défini. Ces fonctionnalités font de kumo un émulateur autonome pour tester les API AWS sans compte AWS.
Le catalogue de services couvre 82 API AWS par catégorie
Le README revendique 82 services pris en charge et fournit un tableau qui les organise en catégories. Le stockage inclut DynamoDB, DynamoDB Streams, EBS, ElastiCache, Glacier, MemoryDB, S3, S3 Control et S3 Tables. Le calcul inclut Batch, EC2, Elastic Beanstalk et Lambda. Les services de conteneurs sont ECR, ECS et EKS. Les services de base de données sont DocumentDB, Neptune, RDS et Redshift. La messagerie et l'intégration couvrent EventBridge, Firehose, Kinesis, MQ, MSK, Pipes, SNS et SQS. La sécurité et l'identité incluent ACM, Cognito, IAM, KMS, Macie, STS, Secrets Manager et Security Lake. La liste complète continue avec la surveillance, la mise en réseau, l'intégration d'applications, la gestion, l'analyse et les outils de développement. Le README ne précise pas quelles opérations API sont implémentées dans chaque service, donc la couverture exacte de chaque service reste non vérifiée.
Démarrer kumo avec Docker, un binaire ou Compose
La section de démarrage rapide montre trois façons d'exécuter kumo. La première est Docker : `docker run -p 4566:4566 ghcr.io/sivchari/kumo:latest` démarre l'émulateur sur le port 4566. Pour la persistance, le README ajoute `-e KUMO_DATA_DIR=/data` et monte un volume nommé. La deuxième consiste à compiler à partir des sources avec `make build` puis à exécuter `./bin/kumo`, en définissant éventuellement `KUMO_DATA_DIR=./data`. La troisième est Docker Compose, avec un exemple YAML minimal qui mappe le port 4566 et un exemple étendu qui ajoute la variable d'environnement et le volume pour la persistance. Le port par défaut est 4566, utilisé dans tous les exemples d'utilisation.
Pointer les clients AWS SDK v2 vers localhost
Les exemples d'utilisation dans le README montrent comment configurer les clients AWS SDK v2 pour pointer vers kumo. Pour S3, le code crée une configuration avec la région `us-east-1` et des identifiants statiques `test`/`test`, puis définit `o.BaseEndpoint` sur `http://localhost:4566` et utilise l'adressage de style chemin. Il crée ensuite un bucket et y place un objet. Des exemples similaires pour SQS, DynamoDB et Secrets Manager suivent le même schéma : charger la configuration par défaut, remplacer le point de terminaison de base et appeler les opérations pertinentes. Les exemples utilisent `contexte Go temporaire` et ignorent les erreurs, ce qui indique qu'il s'agit d'illustrations minimales plutôt que de code de production. Comme kumo ne nécessite pas d'authentification, n'importe quels identifiants statiques fonctionnent.
Variables d'environnement et journalisation structurée
La configuration de kumo est contrôlée par quatre variables d'environnement documentées dans un tableau. `KUMO_HOST` définit l'adresse de liaison et a pour valeur par défaut `0.0.0.0`. `KUMO_PORT` définit le port et a pour valeur par défaut `4566`. `KUMO_LOG_LEVEL` accepte debug, info, warn ou error, avec info par défaut. `KUMO_DATA_DIR` n'est pas défini par défaut ; lorsqu'il est défini, il active la persistance. La journalisation est structurée avec des champs tels que method, path, status, duration et request ID. Au niveau INFO, chaque requête est journalisée avec soit un champ `target` pour les services de protocole JSON/Query comme Secrets Manager, DynamoDB et SQS, soit un champ `action` pour les services de protocole Query comme EC2 et SNS lorsque l'action est dans l'URL. Au niveau DEBUG, le corps complet de la requête est inclus dans la sortie du journal.
En mémoire par défaut, persistant sur demande
La persistance des données est optionnelle. Sans `KUMO_DATA_DIR`, kumo fonctionne entièrement en mémoire et toutes les données sont perdues à la sortie du processus ; le README qualifie cela d'idéal pour les pipelines CI/CD qui nécessitent un état propre à chaque exécution de test. Lorsque `KUMO_DATA_DIR` est défini, chaque service charge son état précédent depuis `$KUMO_DATA_DIR/{service}.json` au démarrage et enregistre son état actuel lors d'un arrêt gracieux déclenché par SIGTERM ou SIGINT. Le répertoire est créé automatiquement s'il n'existe pas. Les écritures sont atomiques : le README mentionne un modèle de fichier temporaire et de renommage pour éviter la corruption en cas de crash. L'état éphémère, comme les messages SQS en vol et les téléversements multipart S3, n'est pas persisté. Cette conception offre au développement local un moyen de conserver les données entre les redémarrages sans compliquer l'utilisation CI.
Points de terminaison réservés aux tests sous /kumo/
kumo expose deux points de terminaison personnalisés sous le préfixe `/kumo/` qui ne font partie d'aucune API AWS. `GET /kumo/ses/v2/sent-emails` renvoie une liste d'e-mails envoyés via l'API SES v2 `SendEmail`, et `GET /kumo/pinpointsmsvoicev2/sent-messages` renvoie les messages SMS envoyés via l'API Pinpoint SMS Voice v2 `SendTextMessage`. Le README inclut des exemples de commandes curl et de réponses JSON montrant des champs comme `MessageId`, `FromEmailAddress`, `Destination`, `Subject`, `Body` et `SentAt` pour les e-mails, et des champs correspondants pour les messages SMS. Ces points de terminaison sont destinés à vérifier le comportement de l'application dans les tests, par exemple pour vérifier qu'un e-mail a été envoyé avec le contenu attendu.
Conclusion éditoriale
kumo est un émulateur AWS autonome qui couvre 82 services, prend en charge le déploiement Docker et binaire, et offre une persistance optionnelle. Ses points de terminaison de test personnalisés pour SES et Pinpoint SMS sont une caractéristique distinctive. Le projet est publié sous la licence MIT, qui accorde la permission d'utiliser, copier, modifier, fusionner, publier, distribuer, sous-licencier et vendre des copies, mais fournit le logiciel « tel quel » sans garantie d'aucune sorte. Le README ne décrit aucune utilisation en production ni garanties de sécurité.
Notes de la communauté