kumo: Ein leichter AWS-Dienstemulator in Go
Ein leichter AWS-Service-Emulator, geschrieben in Go. Funktioniert sowohl als CI/CD-Testtool als auch als lokaler Entwicklungsserver mit optionaler Datenpersistenz.
Auf einen Blick
- Was ist das?
- Ein In-Memory-AWS-Emulator mit 82 Diensten, optionaler Persistenz und Docker-Unterstützung.
- Für wen ist es gedacht?
- kumo ist ein eigenständiger AWS-Emulator, der 82 Dienste abdeckt, Docker- und Binärbereitstellung unterstützt und optionale Persistenz bietet. Seine benutzerdefinierten Testendpunkte für SES und Pinpoint SMS sind ein Unterscheidungsmerkmal.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Go, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Ein Go-basierter AWS-Emulator für CI/CD und lokale Entwicklung
kumo ist ein leichter AWS-Dienstemulator, der in Go geschrieben ist und laut README sowohl als CI/CD-Testwerkzeug als auch als lokaler Entwicklungsserver dient. Die Die Repository-Metadaten nennen die Sprache als Go auf, und die Beschreibung stimmt überein. Das README hebt mehrere Funktionen hervor: Es ist keine Authentifizierung erforderlich, was für CI-Umgebungen geeignet ist; es wird als einzelne Binärdatei geliefert; es unterstützt Docker; es ist leichtgewichtig mit schnellem Start und minimalem Ressourcenverbrauch; es ist mit dem Go AWS SDK v2 kompatibel; und es kann optional Daten persistieren, wenn KUMO_DATA_DIR gesetzt ist. Diese Funktionen machen kumo zu einem eigenständigen Emulator zum Testen von AWS-APIs ohne AWS-Konto.
Der Dienstekatalog umfasst 82 AWS-APIs nach Kategorie
Das README beansprucht 82 unterstützte Dienste und bietet eine Tabelle, die sie in Kategorien organisiert. Speicher umfasst DynamoDB, DynamoDB Streams, EBS, ElastiCache, Glacier, MemoryDB, S3, S3 Control und S3 Tables. Compute umfasst Batch, EC2, Elastic Beanstalk und Lambda. Containerdienste sind ECR, ECS und EKS. Datenbankdienste sind DocumentDB, Neptune, RDS und Redshift. Messaging und Integration deckt EventBridge, Firehose, Kinesis, MQ, MSK, Pipes, SNS und SQS ab. Sicherheit und Identität umfasst ACM, Cognito, IAM, KMS, Macie, STS, Secrets Manager und Security Lake. Die vollständige Liste setzt sich über Überwachung, Netzwerk, Anwendungsintegration, Verwaltung, Analytik und Entwicklerwerkzeuge fort. Das README gibt nicht an, welche API-Operationen innerhalb jedes Dienstes implementiert sind, daher bleibt die genaue Abdeckung jedes Dienstes unverifiziert.
kumo mit Docker, Binärdatei oder Compose starten
Der Schnellstartabschnitt zeigt drei Möglichkeiten, kumo auszuführen. Die erste ist Docker: `docker run -p 4566:4566 ghcr.io/sivchari/kumo:latest` startet den Emulator auf Port 4566. Für Persistenz fügt das README `-e KUMO_DATA_DIR=/data` hinzu und mountet ein benanntes Volume. Die zweite ist das Erstellen aus dem Quellcode mit `make build` und dann das Ausführen von `./bin/kumo`, optional mit `KUMO_DATA_DIR=./data`. Die dritte ist Docker Compose, mit einem minimalen YAML-Beispiel, das Port 4566 zuordnet, und einem erweiterten Beispiel, das die Umgebungsvariable und das Volume für Persistenz hinzufügt. Der Standardport ist 4566, der in allen Verwendungsbeispielen verwendet wird.
AWS SDK v2-Clients auf localhost ausrichten
Die Verwendungsbeispiele im README zeigen, wie AWS SDK v2-Clients auf kumo ausgerichtet werden. Für S3 erstellt der Code eine Konfiguration mit Region `us-east-1` und statischen Anmeldeinformationen `test`/`test`, setzt dann `o.BaseEndpoint` auf `http://localhost:4566` und verwendet Pfadstil-Adressierung. Anschließend erstellt er einen Bucket und legt ein Objekt ab. Ähnliche Beispiele für SQS, DynamoDB und Secrets Manager folgen demselben Muster: Standardkonfiguration laden, Basis-Endpunkt überschreiben und die relevanten Operationen aufrufen. Die Beispiele verwenden `der konkrete SDK-Aufruf` und ignorieren Fehler, was darauf hindeutet, dass sie minimale Illustrationen und kein Produktionscode sind. Da kumo keine Authentifizierung erfordert, funktionieren beliebige statische Anmeldeinformationen.
Umgebungsvariablen und strukturierte Protokollierung
Die Konfiguration von kumo wird durch vier Umgebungsvariablen gesteuert, die in einer Tabelle dokumentiert sind. `KUMO_HOST` setzt die Bindungsadresse und standardmäßig auf `0.0.0.0`. `KUMO_PORT` setzt den Port und standardmäßig auf `4566`. `KUMO_LOG_LEVEL` akzeptiert debug, info, warn oder error, mit info als Standard. `KUMO_DATA_DIR` ist standardmäßig nicht gesetzt; wenn gesetzt, aktiviert es Persistenz. Die Protokollierung ist strukturiert mit Feldern wie Methode, Pfad, Status, Dauer und Anforderungs-ID. Auf INFO-Ebene wird jede Anforderung entweder mit einem `target`-Feld für JSON/Query-Protokolldienste wie Secrets Manager, DynamoDB und SQS oder mit einem `action`-Feld für Query-Protokolldienste wie EC2 und SNS protokolliert, wenn die Aktion in der URL steht. Auf DEBUG-Ebene wird der vollständige Anforderungstext in die Protokollausgabe aufgenommen.
Standardmäßig im Speicher, auf Wunsch persistent
Datenpersistenz ist optional. Ohne `KUMO_DATA_DIR` läuft kumo vollständig im Speicher und alle Daten gehen beim Beenden des Prozesses verloren; das README bezeichnet dies als ideal für CI/CD-Pipelines, die bei jedem Testlauf einen sauberen Zustand benötigen. Wenn `KUMO_DATA_DIR` gesetzt ist, lädt jeder Dienst beim Start seinen vorherigen Zustand aus `$KUMO_DATA_DIR/{service}.json` und speichert seinen aktuellen Zustand beim ordnungsgemäßen Herunterfahren, das durch SIGTERM oder SIGINT ausgelöst wird. Das Verzeichnis wird automatisch erstellt, falls es nicht existiert. Schreibvorgänge sind atomar: Das README erwähnt ein Muster aus temporärer Datei und Umbenennung, um Beschädigungen bei Abstürzen zu verhindern. Flüchtiger Zustand wie SQS-In-Flight-Nachrichten und S3-Multipart-Uploads wird nicht persistiert. Dieses Design gibt der lokalen Entwicklung eine Möglichkeit, Daten über Neustarts hinweg zu behalten, ohne die CI-Nutzung zu erschweren.
Nur für Tests gedachte Endpunkte unter /kumo/
kumo stellt unter dem Präfix `/kumo/` zwei benutzerdefinierte Endpunkte bereit, die nicht Teil einer AWS-API sind. `GET /kumo/ses/v2/sent-emails` gibt eine Liste von E-Mails zurück, die über die SES v2 `SendEmail`-API gesendet wurden, und `GET /kumo/pinpointsmsvoicev2/sent-messages` gibt SMS-Nachrichten zurück, die über die Pinpoint SMS Voice v2 `SendTextMessage`-API gesendet wurden. Das README enthält Beispiel-curl-Befehle und JSON-Antworten, die Felder wie `MessageId`, `FromEmailAddress`, `Destination`, `Subject`, `Body` und `SentAt` für E-Mails sowie entsprechende Felder für SMS-Nachrichten zeigen. Diese Endpunkte dienen dazu, das Anwendungsverhalten in Tests zu überprüfen, z. B. um festzustellen, ob eine E-Mail mit dem erwarteten Inhalt gesendet wurde.
Redaktionelles Fazit
kumo ist ein eigenständiger AWS-Emulator, der 82 Dienste abdeckt, Docker- und Binärbereitstellung unterstützt und optionale Persistenz bietet. Seine benutzerdefinierten Testendpunkte für SES und Pinpoint SMS sind ein Unterscheidungsmerkmal. Das Projekt wird unter der MIT-Lizenz veröffentlicht, die die Erlaubnis zur Nutzung, Vervielfältigung, Änderung, Zusammenführung, Veröffentlichung, Verteilung, Unterlizenzierung und zum Verkauf von Kopien erteilt, die Software jedoch ohne jegliche Gewährleistung bereitstellt. Das README beschreibt keine Produktionsnutzung oder Sicherheitsgarantien.
Community-Notizen