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, включно з витратами та видаленням ресурсів. Поруч із результатом має лишатися перелік неперевірених меж.