Поддержка запросов в AWS Config с помощью Moto

Разработана экспериментальная функция для AWS Config, которая предоставляет возможности AWS Config в модульных тестах. Эта функция является экспериментальной, поскольку существует множество сервисов, которые ещё не поддерживаются и со временем потребуют добавления сообществом. На этой странице подробно описано, как работает эта функция и как её можно использовать.

Что это такое и зачем мне это использовать?

AWS Config — это сервис AWS, который описывает типы ресурсов AWS и может отслеживать их изменения с течением времени. В настоящее время moto не поддерживает обработку изменений истории конфигурации, но у него есть несколько имитированных методов, которые могут быть чрезвычайно полезны для модульного тестирования.

Если вы разрабатываете автоматизацию, которой необходимо взаимодействовать с AWS Config, то это поможет вам написать тесты, способные имитировать ваш код в рабочей среде.

Как это работает?

Возможности AWS Config в moto работают путём изучения состояния ресурсов, созданных в moto, а затем возвращают эти данные так, как это сделал бы AWS Config (без учёта истории). Это будет работать путём запроса всех бэкэндов moto (регионов) для данного типа ресурса.

Однако это будет работать только с теми типами ресурсов, для которых эта возможность включена.

Текущие поддерживаемые типы ресурсов:

1. S3 (все);
2. IAM (роль, политика).

Руководство разработчика

Есть несколько частей этого процесса для добавления новых возможностей в moto:

1. Список ресурсов;
2. Описание ресурсов.

Для обоих есть ряд предварительных условий:

Базовые компоненты

В файле moto/core/models.py находится класс с именем ConfigQueryModel. Это базовый класс, который отслеживает все бэкэнды типов ресурсов.

Как минимум, типы ресурсов, для которых это включено, будут иметь:

1. Файл config.py, который будет импортировать бэкэнды типа ресурсов (из __init__.py);
2. В ресурсе config.py реализацию класса ConfigQueryModel с логикой, уникальной для типа ресурса;
3. Экземпляр класса ConfigQueryModel;
4. В файле moto/config/models.py импорт экземпляра ConfigQueryModel, обновление RESOURCE_MAP, чтобы иметь сопоставление типа ресурса AWS Config с экземпляром на предыдущем шаге (только что импортированным).

Пример выше реализован для S3. Вы можете увидеть это, посмотрев:

1. moto/s3/config.py;
2. moto/config/models.py.

Тестирование

Для каждого типа ресурсов вам нужно будет протестировать несколько отдельных областей:

• Протестируйте запросы бэкэнда, чтобы убедиться, что обнаруженные ресурсы возвращаются (например, для IAM::Policy напишите tests.tests_iam.test_policy_list_config_discovered_resources). Для написания этих тестов вы не должны использовать boto для создания ресурсов. Вам нужно будет использовать методы модели бэкэнда для предоставления ресурсов. Это делается для того, чтобы тесты были совместимы с сервером moto. Вы должны создать тесты для типа ресурса, чтобы протестировать список и получение объекта.

• Протестируйте конфигурационный словарь для всех сценариев (например, для IAM::Policy напишите tests.tests_iam.test_policy_config_dict). Для написания этого теста вам потребуется создавать ресурсы таким же образом, как и в первом тесте (не используя boto), во всех значимых конфигурациях, которые приведут к созданию другого конфигурационного словаря. Затем запросите бэкэнд и убедитесь, что каждый из словарей соответствует вашим ожиданиям.

• Проверьте, всё ли работает вместе с клиентами boto. (например, для IAM::Policy напишите tests.tests_iam.test_policy_config_client). Основными двумя элементами для тестирования будут boto.client('config').list_discovered_resources(), boto.client('config').list_aggregate_discovered_resources() и т. д. Этот тест не должен быть очень тщательным, но он в основном проверяет, что логика переднего и заднего конца работает вместе и возвращает правильные ресурсы. Обратите внимание, что методы агрегирования начинаются с заглавных букв (например, Limit), в то время как методы без агрегирования имеют строчные буквы (например, limit). Ресурсы

Для большинства типов ресурсов верно следующее:

1. Существуют региональные бэкэнды со своими наборами данных.
2. Агрегация конфигурации может извлекать данные из любого региона бэкэнда — мы предполагаем, что всё находится в одной учётной записи.

Реализация возможности перечисления будет отличаться для каждого типа ресурса. Как минимум вам нужно будет вернуть список словарей List of Dict, которые выглядят следующим образом:

[
    {
        'type': 'AWS::Тип данных AWS Config',
        'name': 'Имя ресурса',
        'id': 'ID ресурса',
        'region': 'Регион ресурса — если глобальный, то вы можете захотеть, чтобы вызывающая логика передавала регион агрегатора для региона ресурса — или просто us-east-1 :P'
    }
    , ...
]

Рекомендуется прочитать комментарий к функции list_config_service_resources класса ConfigQueryModel в базовом классе здесь.

^^ Код AWS Config увидит это и правильно отформатирует как для агрегированных, так и для неагрегированных вызовов.

Общие советы по реализации

Агрегация и неагрегация запросов могут и должны использовать одну и ту же общую логику. Различия заключаются в следующем:

• Неагрегированный список будет указывать имя региона backend backend_region.
• Агрегированный список должен иметь возможность перечислять типы ресурсов во всех бэкэндах и при необходимости фильтровать, передавая resource_region.

Примером рабочей реализации этого является S3 (moto/s3/config.py).

Разбиение на страницы обычно должно иметь возможность извлекать ресурс в любом регионе, поэтому его следует сегментировать по region-item-name — это не сделано для S3, потому что S3 имеет глобально уникальное пространство имён.

Описание ресурсов

Извлечение конфигурации ресурса имеет некоторое сходство с перечислением ресурсов, но требует больше работы (для реализации). Из-за различных способов настройки ресурса потребуется выполнить некоторую работу, чтобы гарантировать правильность возвращаемого Config dict.

Для большинства типов ресурсов верно следующее:

1. Существуют региональные бэкэнды со своими наборами данных.
2. Агрегация конфигурации может извлекать данные из любого региона бэкэнда — мы предполагаем, что всё находится в одной учётной записи.

Текущая реализация предназначена для S3. S3 очень сложен, и в зависимости от того, как настроено ведро, будет зависеть то, что вернёт Config.

Реализуя получение конфигурации ресурса, вам нужно будет возвращать как минимум None, если ресурс не найден, или словарь dict, который выглядит так, как его вернул бы AWS Config.

Рекомендуется прочитать комментарий к функции get_config_resource класса ConfigQueryModel в базовом классе здесь.