Валентина Пытлик

Всем привет! Меня зовут Валентина, я разработчик в тестировании облака Selectel. В своей прошлой статье я рассказала, как мы автоматизировали запуск Tempest-тестов в GitLab. Материал вам понравился, поэтому я написала продолжение. В нашей автоматизации была проблема: после тестов ресурсы «подвисали» и не удалялись. Отработавшие тесты занимали проектные квоты и это влияло на стабильность пайплайна. Для решения этой проблемы нам нужен был инструмент, который умеет автоматически утилизировать ресурсы после каждого теста — и мы кое-что нашли. Интересно? Подробности в статье. Исследование существующих решений Первое, о чем я задумалась, можно ли использовать bash-скрипты для утилизации ресурсов. Однако нашлись причины против этой идеи — и их было несколько. Очистка ресурсов будет проходить в production-окружении, а значит должна быть безопасной. Чтобы удаление ресурсов было безопасным, важно производить его с учетом уникальных идентификаторов (UUID) ресурсов. Поскольку процесс будет выполняться от имени администратора, есть вероятность удалить лишнее, но это можно также отнести к безопасности. Поэтому нужно было найти уже существующее решение, которое соответствует всем требованиям, или же написать собственное. Первым делом я решила исследовать сам Tempest: предположила, что с проблемой очистки ресурсов сталкивались не только мы — и оказалась права. Tempest предлагает встроенный Cleanup, но в сети о нем крайне мало информации, если не учитывать официальную документацию с инструкцией по запуску. Знакомство с Tempest Cleanup По умолчанию Tempest Cleanup содержит в себе три основные команды, каждая из которых отвечает за определенный этап очистки. --init-saved-state Позволяет сохранить исходное состояние облака до запуска тестов. Обычно рекомендуется сначала запустить tempest cleanup --init-saved-state. Он создает файл saved_state.json со списком объектов, которые уже существуют в OpenStack и не будут удалены в процессе работы Cleanup. Однако если по каким-то причинам она не была запущена, необходимо отредактировать файл saved_state.json, добавив туда объекты, которые не подлежат удалению. --dry-run Перед запуском самого процесса очистки рекомендуется запустить tempest cleanup --dry-run. Это позволит создать файл dry_run.json со списком объектов, которые будут удалены при запуске Cleanup. Следует убедиться, что данный файл не содержит объектов, которые не подлежат удалению. tempest cleanup Если запустить команду tempest cleanup без каких-либо аргументов, запустится процесс очистки. При этом если сделать это сразу, есть вероятность удалить нужные данные. Поэтому необходимо запускать Tempest Cleanup в следующей последовательности: При запуске Cleanup обращается к конфигурационному файлу tempest.conf, чтобы найти, где собирать информацию об объектах. В конфигурации с помощью параметра region указывается, где будут запускаться тесты, а в случае с Cleanup — собираться информация об объектах OpenStack. Если рассматривать работу Tempest Cleanup из коробки, то он собирает информацию о следующих OpenStack объектах: Отчеты Tempest Cleanup Повторюсь: при запуске Cleanup с флагом --init-saved-state генерируется saved_state.json, в котором хранится информация об уже существующих объектах. Они не будут удалены при запуске очистки ресурсов, поэтому наличие этого файла особенно важно. Структура saved_state.json — словарь со всеми типами объектов: Если объектов конкретного типа не найдено, в отчете мы увидим пустой словарь, например: Если же объекты найдены, в отчете мы получаем основную информацию: uuid, name, status, project_id и другие данные. При запуске Cleanup с флагом --dry-run генерируется файл dry_run.json, в котором хранится информация об объектах, которые остались после тестирования и буду удалены. Файл отчета имеет схожую структуру с файлом saved_state.json: В целом, такое решение нам подходит, однако есть парочка нюансов, которые следует исправить. Что было исправлено Одна из главных проблем Cleanup заключалась в том, что у него большая область действия — целый регион, в котором могут быть не только тестовые ресурсы, но и объекты других команд, а также ресурсы клиента. Поэтому мы приняли решение сократить области действия. Все объекты, которые попадают под область действия Cleanup, можно условно разделить на две группы. project related Объекты, которые находятся под определенным проектом. На изображении такие объекты помечены полем project_id: global Объекты, которые не принадлежат определенным проектам — например, пользователи. На изображении они окрашены в фиолетовый цвет: Нам было важно, чтобы Tempest Cleanup был универсальным и конфигурируемым, поскольку его будет использовать не только наша команда. Вся необходимая настройка должна проводиться через tempest.conf, как и при запуске тестов. Для этого внутри конфигурационного файла мы создали раздел , внутри которого были добавлены параметры для настройки Tempest Cleanup: Далее я более подробно расскажу о каждом из добавленных параметров. cleanup_project_ids Первым делом мы сделали, чтобы project related-объекты собирались только внутри тестовых проектов. Однако у каждой команды свои проекты, следовательно, и свой набор UUID. Поэтому внутри раздела мы добавили параметр cleanup_project_ids, который включает в себя список UUID тестовых проектов. skip_global_cleanup_services Проведя небольшой анализ используемых во время тестирования объектов, мы обнаружили, что зачастую пользователи, проекты и роли не создаются и не удаляются во время тестов, потому что используется accounts.yaml. Это файл с заранее созданными проектами, внутри которых уже есть пользователи с определенными ролями. Поскольку для тестирования выделен конкретный домен и регион, в создании и удалении новых объектов также нет необходимости. Так как все эти объекты относятся к группе global, можно в раздел добавить параметр, который будет принимать значение True или False, и включать или исключать глобальные объекты в Tempest Cleanup. Так в tempest.conf появился новый параметр -- skip_global_cleanup_services. Если skip_global_cleanup_servicesTrue, то Cleanup не будет собирать информацию об объектах flavor, image, user, project, domain, role и region. Если же skip_global_cleanup_servicesFalse, то данные объекты будут включены в работу Cleanup. include_octavia Поскольку мы настраивали Tempest Cleanup для сервиса Octavia, который по умолчанию не включен в набор тестов Tempest и отсутствует в Cleanup, появилась необходимость включить объекты loadbalancer в логику работы. Однако Octavia не является дефолтным сервисом, поэтому нужно было сделать его включение в Tempest Cleanup опциональным. Для этого в раздел был добавлен новый параметр — include_octavia, который принимает значения True или False, в зависимости от того, тестируется на данный момент Octavia или нет. Важно отметить: если в тестовый набор Tempest не подключен octavia tempest plugin, то объекты типа loadbalancers не будут принимать участие в тестировании. Поэтому при запуске Tempest Cleanup их счетчик будет равен 0 и удалять будет нечего. Однако если внутри облака не подключен сам сервис Octavia, то при запуске Tempest Cleanup будет ошибка, которая будет указывать на то, что мы пытаемся отправить запрос на несуществующий/неизвестный эндпоинт. В этом случае стоит перевести параметр include_octavia в значение False. skip_quotas_deletion В ходе запуска тестов выяснилось, что после каждого прогона происходит удаление не только объектов OpenStack, но и проектных квот. Под проектными квотами я подразумеваю количественное ограничение на создание объектов внутри тестовых проектов. Из-за этого перед каждым прогоном необходимо было идти и выставлять квоты для всех проектов. После небольшого исследования выяснилось, что Tempest Cleanup содержит в себе также три набора квот, разбитых по сервисам: квоты для Nova сервиса, квоты для Volume сервиса, квоты для Network сервиса. На изображении они выделены желтым цветом. Чтобы решить эту проблему, достаточно было исключить квоты из области действия Cleanup. Для этого мы создали параметр skip_quotas_deletion, который находится в разделе конфигурационного файла tempest.conf. Этот параметр принимает значение True, если необходимо исключить проектные квоты из очистки. И принимает значение False, если проектные квоты нужно подчистить. По умолчанию мы исключаем квоты из области действия Cleanup. Таким образом, нам удалось избавиться от очистки ненужных ресурсов и минимизировать ручное вмешательство в процесс подготовки к тестированию. И выглядит так, что наш Cleanup готов к использованию. Как интегрировали Cleanup в пайплайн В прошлой своей статье я поделилась, как мы автоматизировали процесс запуска тестов. Теперь передо мной стояла задача включить модифицированный Tempest Cleanup в уже созданный пайплайн. Важно отметить, что перед тем, как запускать Tempest Cleanup, необходимо выполнить необходимые настройки. Для запуска — в директорию /etc/tempest/ положить конфигурационный файл tempest.conf. Однако по умолчанию этой директории нет, поэтому ее нужно создать самостоятельно, используя права администратора. В основе пайплайна заложен скрипт, внутри которого реализована следующая последовательность действий. 1. Создание тестового окружения: 2. Создание конфигурационного файла tempest.conf: 3. Копирование файла в директорию /etc/tempest/ для работы Tempest Cleanup: 4. Запуск Tempest Cleanup с флагом --init--saved_state: 5. Запуск тестов Tempest: 6. Запуск Tempest Cleanup с флагом --dry-run: 7. Запуск Tempest Cleanup для очистки ресурсов после тестирования: 8. Создание отчетов: Заключение Нам удалось решить вопрос с очисткой «подвисших» ресурсов. Теперь после каждого запуска тестов активируется Cleanup, который экономит время на ручной уборке. Также благодаря своевременной очистке ресурсов дальнейшие запуски пайплайнов производятся без проблем с квотами.