Больше работайте с Molecule, чтобы убедиться, что ваша инфраструктура работает. Используйте компоновку, идемпотентность, несколько контейнеров и внутренние зависимости, чтобы при развертывании веб-сайта ваши роли Ansible вели себя должным образом.   В первой части статьи мы рассмотрели основы настройки Molecule и провели нескольких простых тестов. В этой статье мы углубимся в конфигурацию Molecule и различные проверки, которые она может выполнять. Мы рассмотрим запуск двух разных контейнеров, проверку идемпотентности и проверку синтаксиса с помощью linting. Вы можете найти код Ansible, с которого мы начинаем, на Github. Не стесняйтесь смотреть дальше на завершенный код здесь —   https://github.com/PCritchfield/ansible/tree/master/ansible_molecule_pt2/laravel_website_corrected/laravel_role. Роль, которую мы будем использовать, является практическим примером, который может отражать реальный сценарий. Однако он не должен рассматриваться как готовый к применению. С учетом сказанного, давайте подробнее рассмотрим, что он делает. Функция этой роли заключается в развертывании веб-сайта Laravel. Он участвует в установке Nginx, PHP 8.1 (и пакетов), а также Composer; на основе роли будет создан сайт Laravel. Наконец, мы будем использовать Molecule для развертывания контейнеров, проверки успешного выполнения задач миграции базы данных, подтверждения идемпотентности и гарантии соответствия нашего кода стандартам компоновки. Можно начать с просмотра разнообразных файлов с задачами:  Отсюда мы будем использовать определенные файлы для установки ключевых веб-компонентов (Nginx и PHP) и развертывания веб-сайта Laravel. Задачи по установке Nginx просты: обновите apt cache, установите пакеты, запустите службу и установите конфигурацию. Здесь важно отметить строку 5 cache_valid_time: 3600. Этот параметр говорит Ansible не запускать apt update, если кэш обновлен менее 3600 секунд назад, что необходимо для тестирования идемпотентности. Этот файл задачи также удаляет файл конфигурации Nginx для веб-сайта. tasks/nginx_install.yml file/laravel.conf Задачи в php_install.yml установят PHP 8.1 и различные пакеты, необходимые для веб-сайта. После установки PHP мы также настроим Composer. Список пакетов и composer_path находятся в списке в defaults/main.yml.   tasks/php_install.yml defaults/main.yml Последний набор задач развертывает код для сайта Laravel. Я использую проект, созданный Джеффри Уэй, Laravel From Scratch Blog Project, который создаст локальный сайт блога при развертывании с использованием Molecule. Вышеуказанные задачи позволяют клонировать проект на наш хост, который создается как .env, так и databse.php файлы. Мы установим переменные окружения, необходимые для файла .env, в molecule.yml. Далее мы обновляем зависимости Composer и запускаем установку. Наконец, мы используем Artisan для запуска миграций, заполнения базы данных и генерации APP_KEY для защиты нашего сайта. tasks/deploy_site.php templates/.env.j2 files/database.php Вот с чего мы начнем. Имейте в виду, что мы не тестируем сам веб-сайт с помощью Molecule, мы просто проверяем возможность развертывания сайта. И по мере того, как мы исследуем идемпотентность и linting, мы будем соответствующим образом обновлять эти файлы. Но, прежде чем мы перейдем к компоновке, давайте посмотрим, как мы запускаем миграции или начальные компоненты без установки базы данных. Чтобы сделать это, нам нужно посмотреть на конфигурацию нашей Molecule и на то, как использовать несколько контейнеров.   Платформы: Несколько контейнеров Одним из преимуществ Molecule и Docker –  они предоставляют средства для развертывания нескольких контейнеров. а это значит, что если мы хотим протестировать базу данных или роль обмена сообщениями, мы можем это сделать. В нашем случае это позволяет нам развернуть контейнер MySQL, выполнить миграции и ввести исходные данные для нашей роли Laravel. Теперь давайте посмотрим на файл molecule.yml. Подобно тому, что мы делали в части 1, в блоке platforms: - это то место, где мы хотим настроить наши контейнеры. Этот раздел позволяет нам настраивать контейнеры аналогично docker-compose. Здесь мы определяем сети, тома, изображения и открытые порты. Для этого набора тестов мы используем контейнеры, созданные Джеффом Герлингом. Эти контейнеры специально разработаны для обеспечения тестирования сервисов, развернутых Ansible в контейнерах. Краткое объяснение некоторых опций, которые я использую здесь: name: значение используется в качестве имени хоста контейнера как для контейнерной сети, так и для инвентаризации Ansible Volumes: подключение тома требуется для правильного запуска службы systemd privlaged: опция сообщает контейнеру, должен ли он запускаться от имени root pre_build_image: опция уведомляет Molecule о необходимости извлечения контейнера из реестра вместо его сборки published_ports: как и -p для Docker, указывает Molecule на необходимость сопоставить список портов между хостом и контейнером. Это означает, что как только у нас будет успешный converge, мы сможем перейти на localhost: 8080 и увидеть, что наш сайт работает. networks: использует команду docker network для создания отдельной сети для запуска контейнеров. В этом случае нужная нам сеть называется “laravel”. Важно отметить, что можно использовать любое расположение изображений в этом блоке. Например, мы могли бы использовать несколько операционных систем для тестирования роли параллельно или идентичные контейнеры для тестирования кластера. Единственное, что следует иметь в виду – это название, указанное в platforms: как именно Molecule использует их в блоке для создания вашего инвентаря. Provisioner: Переменные среды Существует множество методов Ansible и Molecule для обработки переменных среды. Я решил предоставить их в блоке Provisioner по двум причинам. Во-первых, это обеспечивает четкость чтения molecule.yml, так как все находится в одном месте. Во-вторых, поскольку мы развертываем больше, чем просто нашу роль Laravel с Molecule, мне нужно было одно место для значений, доступных как сайту, так и базе данных. Converge:деплой двух ролей   На этом этапе мы можем развернуть два разных контейнера в общей сети и предоставить Ansible некоторые переменные среды. Итак, как же нам подготовить эти отдельные контейнеры? Для этого необходимо несколько ключевых элементов. Мы можем начать с добавления зависимостей с помощью Ansible Galaxy и файла requirements.yml. Затем мы можем добавить блок dependency: в наш файл Molecule.   dependency block for molecule.yml molecule/requirements.yml Эти фрагменты сообщают Molecule, что нам нужно установить мою развилку роли geerlingguy.mysql с GitHub, прежде чем мы обработаем наш converge. Теперь, когда у нас есть роль, которая установит MySQL в наш контейнер, нам нужно запустить ее. Мы должны взглянуть на наш файл converge.yml. В предыдущей статье говорилось, что converge.yml – это учебное пособие, которое Molecule будет использовать для создания наших контейнеров. С этой целью нашему converge необходимо будет настроить таргетинг на несколько хостов. Ранее я упоминал, что название, которое мы даем каждому контейнеру в блоке platforms:  – это то, что Molecule использует для инвентаризации, позволяя нам сделать что-то похожее на следующее: В этот момент molecule.yml должен выглядеть примерно так:   Наконец, вся подготовительная работа завершена, и мы должны выполнить команду: molecule converge . Если все работает правильно, Molecule должен извлечь роль MySQL из Galaxy, запустить два контейнера и запустить плейбуки на их целевых хостах. Мы публикуем сообщения в контейнерах, поэтому мы можем перейти к http://localhost:8080 и взаимодействовать с функциональным блогом.  И да, и нет. Да, так как у нас есть уверенность в том, что задачи, которые зависят от разных хостов, могут делать то, что нам нужно. Нет, потому что некоторые из этих задач завершатся неудачей при запуске на существующем сервере. Эти сбои могут привести к головной боли для разработчиков или, что еще хуже, к простою в проде. Давайте начнем с определения идемпотентности. Согласно Википедии, “Идемпотентность – это свойство определенных операций в математике и информатике, посредством которого они могут быть применены несколько раз без изменения результата за пределами первоначального применения”. Это означает, что независимо от того, сколько раз мы запускаем плейбуки Ansible, изменения должны применяться только при первом запуске задачи. Вот почему идемпотентность жизненно важна для ваших ролей Ansible. Зачем устанавливать что-то дважды? Не рискуйте обновлять текущую версию Java или Nginx, когда вы можете использовать Molecule для определения возможных изменений, если вы дважды запустите свою роль. Когда мы запустим команду idempotence, Molecule повторно запустит converge.yml и убедится, что ни одна из задач не создает изменений. Давайте посмотрим, как будет выглядеть этот результат. Запустите команду molecule idempotence, и вы должны получить следующее: Мы видим, что несколько задач вносят изменения в запущенные экземпляры. Мы также можем видеть, что роль geerlingguy.mysql приводит к сбою нашей проверки на идемпотентность, но поскольку мы не тестируем эту роль, нам нужно убедиться, что наша проверка на идемпотентность игнорирует эту часть converge. Чтобы сделать это, мы можем добавить строку tags: molecule-idempotence-notest. Как и большинство тегов Ansible, мы можем использовать это в любой области. Здесь мы используем его, чтобы пропустить всю роль, но мы также могли бы использовать его для пропуска задач. С этим обновлением давайте повторим проверку идемпотентности. Molecule теперь проигнорирует первый раздел converge, который нацелен на контейнер базы данных, и выдаст нам результат, который выглядит следующим образом: Отлично, в итоговых данных нет хоста MySQL. Теперь, когда мы знаем, что наши проверки Molecule будут нацелены только на то, что мы хотим, нам нужно очистить остальную часть нашего кода. Преимущество выходных данных в том, что мы знаем, какие именно задачи вызывают наши проблемы с идемпотентностью. Мы начнем с самого начала задачи, которая устанавливает Composer. Поскольку мы используем командный модуль для проверки наличия двоичного файла Composer, он всегда будет возвращать измененный. Что нас волнует, так это выходные данные, которые мы регистрируем, поэтому мы можем просто добавить параметр changed_when: false  к задаче Checks if Composer is already installed в php_install.yml. Остальные сбои идемпотентности происходят из deploy_site.yml. Если мы посмотрим, то увидим, что мы выполняем несколько задач, которые требуются только при первоначальном развертывании сайта. Чтобы исправить это, мы можем поместить эти задачи в блок с помощью инструкции when, которая проверяет, произошло ли клонирование git. Во-первых, мы хотим переместить задачу Clone git repository  из существующего блока в отдельную задачу и зарегистрировать выходные данные задачи. Помните, что нам нужно будет добавить параметры для запуска задачи от имени пользователя www-data  в строки 10-17. Как только мы переместим эту задачу, мы хотим изменить оставшийся блок, чтобы проверить зарегистрированный вывод на предмет измененного статуса в строке 56. Как только мы внесем эти изменения, мы сможем повторно запустить тест на идемпотентность. Теперь давайте запустим команду molecule idempotence и посмотрим, что мы получим. Если весь наш код обновлен правильно, мы должны увидеть следующий вывод: Отлично, мы на один шаг приблизились к точному и функциональному набору тестов Molecule.   Теперь мы уже знаем, что наш код Ansible функционален и идемпотентен, но является ли он чистым и соответствующим стандартам? Чтобы выяснить это, мы можем запустить наш код через линтер. Чтобы протестировать линтинг в Molecule, вам сначала нужно включить его в главном файле. Мы можем сделать это, добавив блок lint: в конец molecule.yml под блок verifier: Вы заметите, что я использую здесь два разных линтера yamllint и ansible-lint. yamllint фокусируется на синтаксисе YAML и других методах, связанных с YAML, в то время как ansible-lint фокусируется на коде и поведении, ориентированных на Ansible. Есть третий вариант, который я бы порекомендовал, если вы используете testinfra, flake8, который поможет поддерживать ваши тесты на Python в соответствии со стандартами. Как только мы добавили блок lint:, мы можем запустить molecule lint и посмотреть, где мы могли бы захотеть улучшить наш код. Ого, да здесь масса потенциальных проблем, которые нужно решить. С чего нам следует начать? Давайте начнем с того, который имеет 21 случай, fqcn-builtins: Use FQCN for builtin actions. Эта ошибка означает, что мы не используем полное имя коллекции (FQCN) для многих наших задач Ansible. Нам нужно обновить все затронутые задачи до ansible.builtin.<MODULE_NAME>. Чтобы все было проще, я просто показываю ошибку и то, как должен выглядеть новый идентификатор задачи.  А теперь, когда они исправлены, давайте посмотрим на то, что осталось. Из оставшихся ошибок есть две, которые мы можем игнорировать: meta-incorrect, что означает, что файл в нашем каталоге ./meta по-прежнему содержит информацию по умолчанию, и no-changed-when , что означает, что конкретные задачи не являются идемпотентными. Поскольку нас не интересует метаинформация и дополнительные проверки и тесты на идемпотентность, мы можем пропустить их оба. Так как же нам пропустить эти проверки? Путем добавления файла .ansible-lint в каталог Molecule. Сделав это, мы можем снова запустить molecule lint и увидеть, что у нас осталось всего 4 нарушения.   Первая ошибка git-latest. Это говорит нам, что мы должны привязать версию к нашей задаче git вместо того, чтобы предполагать основную ветвь. Исправить это так же просто, как добавить к задаче однострочную version: main  . Следующее нарушение no-handler. Эта ошибка дает нам знать, что у нас есть задача или серия задач, которые выполняются только при изменении. Мы должны использовать функцию обработчика для выполнения задач. Исправление этого нарушения требует ряда изменений, начиная с блока задач configure site из deploy_sites.yml в отдельный файл. Я начал с tasks/configure_site.yml. Затем нам нужно внести дополнительное обновление в задачу git, добавив другой обработчик. Наконец, нам нужно обновить handlers/main.yml для вызова tasks/configure_site.yml, чтобы действовать при срабатывании notify. После этого наши задачи по настройке нашего сайта и нашей базы данных будут выполняться только тогда, когда задача git зарегистрирует изменение. Последнее нарушение lint  это risky-file-permissions  для двух файлов. Вкратце, мы не указывали разрешения для файлов, обрабатываемых Ansible, оставляя место для чрезмерно разрешающих или ограничительных разрешений для файлов. Это изменение легко устранить, добавив опцию mode: <PERMISSIONS> к файлам, которые мы обрабатываем. После того, как мы закончим вносить эти изменения, мы можем запустить molecule lint в последний раз и убедиться, что он не возвращает никаких нарушений. Подводя итоги Как только последняя секция будет завершена, мы сможем собрать все это вместе и запустить molecule test, позволяющий нам увидеть все эти изменения за один прогон. Наша роль Ansible может протестировать миграции вашей базы данных, а мы успешно подтвердили ее идемпотентность и поработали над тем, чтобы она соответствовала стандартам кодирования. Теперь вы можете двигаться дальше со знанием и уверенностью в том, что ваши роли в Ansible будут рабочими и стабильными. Поток «Ansible: Infrastructure as Code» стартует 6 февраля.