Как поднять 70+ сервисов AWS на ноутбуке без боли и лишних затрат

Представьте ситуацию: вы пишете код для работы с S3 или DynamoDB, и вам нужно его протестировать. Вариантов обычно немного. Можно использовать реальное облако AWS, но тогда придется возиться с IAM-ролями, следить за тем, чтобы не вылететь за пределы Free Tier, и мириться с задержками сети. Можно взять LocalStack, который стал стандартом индустрии, но он с каждым годом становится все тяжелее, а многие полезные фичи теперь спрятаны за платной подпиской.

Недавно я наткнулся на проект kumo. Это легковесный эмулятор сервисов AWS, написанный на Go. Он не пытается заменить собой полноценное облако, но отлично справляется с ролью локального сервера для разработки и прогона тестов в CI/CD.

kumo logo

Что умеет этот эмулятор

Автор kumo заявляет поддержку 74 сервисов. Список впечатляет: от базовых S3, SQS и DynamoDB до более специфических вещей вроде Rekognition для анализа изображений или Step Functions для оркестрации воркфлоу.

Главная фишка проекта — простота. Это один бинарный файл, который запускается мгновенно. Ему не нужна аутентификация, так что в конфигах вашего приложения можно прописать любые фейковые ключи, и все будет работать. Для тестов в GitHub Actions или GitLab CI это просто спасение, так как не нужно тратить время на поднятие тяжелых контейнеров.

Пять причин присмотреться к kumo

Никаких паролей. В окружении для разработки безопасность часто только мешает. kumo принимает любые запросы без проверки подлинности.
Скорость работы. Поскольку инструмент написан на Go и скомпилирован в нативный код, он потребляет минимум ресурсов и стартует за доли секунды.
Совместимость с AWS SDK v2. Если вы пишете на Go и используете официальную библиотеку от Amazon, переход на kumo потребует изменения пары строк в конфиге клиента.
Персистентность данных. По умолчанию эмулятор хранит всё в оперативной памяти — выключили и забыли. Но если вам нужно, чтобы созданные таблицы в DynamoDB или файлы в S3 пережили перезагрузку, достаточно прокинуть переменную окружения KUMO_DATA_DIR.
Прозрачное логирование. В режиме отладки инструмент выводит полные тела запросов. Если что-то идет не так, вы сразу увидите, какие данные ваше приложение отправляет «в облако».

Как это выглядит в коде

Давайте посмотрим, как настроить клиент для работы с локальным эмулятором на примере S3. Все, что нужно сделать — переопределить BaseEndpoint.

cfg, _ := config.LoadDefaultConfig(context.TODO(),
    config.WithRegion("us-east-1"),
    // Используем любые статические данные для авторизации
    config.WithCredentialsProvider(credentials.NewStaticCredentialsProvider("test", "test", "")),
)

client := s3.NewFromConfig(cfg, func(o *s3.Options) {
    o.BaseEndpoint = aws.String("http://localhost:4566")
    o.UsePathStyle = true
})

// Теперь можно создавать бакеты и заливать файлы локально
client.CreateBucket(context.TODO(), &s3.CreateBucketInput{
    Bucket: aws.String("my-local-bucket"),
})

Аналогично настраиваются и другие сервисы. Например, для SQS или Secrets Manager логика остается той же: меняем эндпоинт на локальный адрес kumo (по умолчанию это порт 4566).

Где это пригодится

Я вижу два основных сценария. Первый — локальная разработка «в самолете» или в местах с плохим интернетом. Вы можете полноценно отлаживать логику взаимодействия с очередями или базами данных, не имея доступа к сети.

Второй сценарий — интеграционные тесты. Вместо того чтобы городить сложные моки или использовать тяжеловесные решения, вы просто запускаете kumo в Docker-контейнере прямо в пайплайне.

services:
  kumo:
    image: ghcr.io/sivchari/kumo:latest
    ports:
      - "4566:4566"
    environment:
      - KUMO_DATA_DIR=/data
    volumes:
      - kumo-data:/data

Нюансы и ограничения

Проект еще молодой, и у него есть свои особенности. Например, эфемеральные состояния вроде сообщений в SQS, которые находятся в процессе обработки (in-flight), или незавершенные мультипарт-загрузки в S3 не сохраняются на диск даже при включенной персистентности.

Также стоит понимать, что это именно эмулятор, а не полная копия AWS. Логика работы некоторых сложных сервисов может отличаться от реального облака в пограничных случаях. README проекта довольно лаконичен, поэтому иногда приходится подглядывать в примеры кода в самом репозитории, чтобы понять, как лучше настроить тот или иной сервис.

Если вам надоело ждать, пока LocalStack соизволит запуститься, или вы ищете максимально легкий способ протестировать AWS-зависимый код, kumo — отличный кандидат. Он особенно хорош для Go-разработчиков благодаря нативной поддержке SDK v2 и высокой скорости работы.

Попробовать стоит, если:

Вам нужно быстрое окружение для тестов в CI.
Вы устали от сложности и тяжести существующих эмуляторов.
Ваше приложение активно использует S3, DynamoDB или SQS.

Проект активно развивается, и 500+ звезд на GitHub говорят о том, что тема локальной эмуляции облака все еще актуальна для сообщества.