Floci: какой контракт может проверить локальное облако

Обработчик получает сообщение из очереди, записывает результат и падает до удаления сообщения. Полезный локальный тест должен показать следующую доставку и проверить, повторился ли побочный эффект. Успешный запрос создания очереди почти ничего не говорит об этом сбое.

Именно с таким вопросом я бы подошёл к Floci, открытому эмулятору AWS. Это обзор первичных источников, проверенных 6 ноября 2026 года. Я не устанавливал проект, не сравнивал его с AWS на практике и не измерял производительность. Предложенные ниже проверки являются анализом, а не результатами эксперимента.

Как читать таблицу сервисов

Документация различает реализацию внутри процесса и исполнение через настоящие контейнеры Docker. Для баз данных, протоколов и сред исполнения это существенная разница. Но настоящий движок ещё не воспроизводит весь управляемый сервис. В строке Aurora DSQL авторы прямо указывают, что вариант на PostgreSQL пока не повторяет ограничения DSQL и асинхронные индексы.

Поэтому список покрытия я бы превращал в перечень конкретных вызовов приложения. Для очереди это отправка синтетического сообщения, получение, запись синтетического результата и подтверждение обработки. Нужно зафиксировать используемые операции и атрибуты. Тогда изменение поведения после обновления эмулятора можно связать с определённым контрактом, а не с расплывчатой отметкой «облачные тесты прошли».

Адрес теста должен быть явным

Примеры SDK в репозитории используют локальный адрес и искусственные учётные данные. Я бы запретил тесту автоматически подхватывать производственный профиль. Следующий оригинальный пример проверяет только строку адреса. Он не запускает сервис, не изолирует сеть и не настраивает очередь.

from urllib.parse import urlsplit

def require_local_endpoint(endpoint):
    u = urlsplit(endpoint)
    if (u.scheme != "http" or u.hostname != "127.0.0.1"
            or u.port != 4566 or u.username or u.password
            or u.path not in ("", "/") or u.query or u.fragment):
        raise ValueError("Expected the explicit loopback test endpoint")
    return endpoint

Проверка намеренно узкая: другой адрес контейнера будет отклонён. Контейнерному тесту нужна собственная проверенная конфигурация сети. Здесь важен отказ при отсутствии ожидаемой цели, а не переход к реальному аккаунту по умолчанию. Производственные данные и ключи в такой сценарий попадать не должны.

Сначала выбрать сбой

Я бы отдельно проверил обычное подтверждение обработки, падение перед подтверждением, повторный бизнес-идентификатор, неверный запрос и запрещённую операцию при включённых проверках прав. Это план, а не утверждение, что Floci уже прошёл эти случаи. Для каждого нужны ожидаемый результат, ограничение времени и число побочных эффектов приложения.

Синтетическое сообщение → очередь → обработчик → запись
                                        |
                              падение до подтверждения
                                        |
                         повторная доставка → счёт записей

Выбранный контракт → отдельная разрешённая проверка в AWS

Например, бизнес-правило может требовать одну запись на идентификатор при повторных доставках. Проверять следует запись, а не только код завершения обработчика. Два последовательных запуска успешного сценария не обязательно воспроизводят падение между записью и подтверждением.

Разделить маршрутизацию и права

Руководство по аккаунтам объясняет: двенадцатизначный идентификатор ключа выбирает пространство аккаунта, другие форматы ведут в аккаунт по умолчанию. Проверка подписей по умолчанию выключена. Справочник переменных также указывает выключенное по умолчанию применение политик IAM.

Изоляция двух пространств не доказывает отклонение поддельной подписи или запрещённого вызова. Тест прав должен включать отказ и сохранять конфигурацию проверок рядом с результатом. Это отдельные свойства, даже если интерфейс сводит их к одному зелёному статусу.

Состояние и доступ к хосту

Режимы хранения включают memory, persistent, hybrid и WAL. README описывает потерю состояния при остановке для memory, немедленные записи для persistent, периодическую выгрузку для hybrid и журналирование изменений до ответа для WAL. Это документированные свойства, не независимый замер надёжности.

Сценарию с чистой очередью нужен явный жизненный цикл; сценарию восстановления нужны граница перезапуска и проверка данных. Docker-пути требуют сокета Docker. Для простой проверки внутри процесса я бы начал без такого доступа и выдавал управление контейнерами только необходимому сценарию в одноразовой среде.

Мой критерий выбора

MIT разрешает использование при соблюдении требований к уведомлению и исключает гарантию. В репозитории видна активность от 5 ноября. Эти факты не доказывают точность эмуляции. Следует закрепить версию, вести матрицу поведения и отдельно согласовать проверку важных свойств в AWS с учётом расходов и удаления ресурсов. Зелёный результат должен сопровождаться перечнем того, что осталось непроверенным.