Больше работайте с 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 для развертывания контейнеров, проверки успешного выполнения задач миграции базы данных, подтверждения идемпотентности и гарантии соответствия нашего кода стандартам компоновки.
.
├── README.md
├── defaults
│ └── main.yml
├── files
│ ├── database.php
│ └── laravel.conf
├── handlers
│ └── main.yml
├── meta
│ └── main.yml
├── molecule
│ ├── collections.yml
│ ├── default
│ │ ├── converge.yml
│ │ ├── molecule.yml
│ │ └── tests
│ │ ├── conftest.py
│ │ └── test_default.py
│ └── requirements.yml
├── tasks
│ ├── deploy_site.yml
│ ├── main.yml
│ ├── nginx_install.yml
│ └── php_install.yml
├── templates
│ └── env.j2
├── tests
│ ├── inventory
│ └── test.yml
└── vars
└── main.ymlЗадача
Можно начать с просмотра разнообразных файлов с задачами:
---
- name: Include Nginx install
include_tasks: nginx_install.yml
- name: Install php
include_tasks: php_install.yml
- name: Deploy website
include_tasks: deploy_site.ymlОтсюда мы будем использовать определенные файлы для установки ключевых веб-компонентов (Nginx и PHP) и развертывания веб-сайта Laravel.
Задачи по установке Nginx просты: обновите apt cache, установите пакеты, запустите службу и установите конфигурацию. Здесь важно отметить строку 5 cache_valid_time: 3600. Этот параметр говорит Ansible не запускать apt update, если кэш обновлен менее 3600 секунд назад, что необходимо для тестирования идемпотентности. Этот файл задачи также удаляет файл конфигурации Nginx для веб-сайта.
---
- name: Only run "update_cache=yes" if the last one is more than 3600 seconds ago
ansible.builtin.apt:
update_cache: yes
cache_valid_time: 3600
- name: install nginx
apt:
name: "{{ item }}"
state: present
with_items:
- nginx=1.18.*
- git
- name: Make sure a service unit is running
sysvinit:
state: started
name: nginx
enabled: true
- name: copy over config
copy:
src: laravel.conf
dest: /etc/nginx/sites-available/default
mode: u+rw,g-r,o-rtasks/nginx_install.yml
server {
listen 80 default_server;
listen [::]:80 default_server;
index index.php;
error_log /var/log/nginx/error.log;
access_log /var/log/nginx/access.log;
root /var/www/laravel/public;
location ~ \.php$ {
try_files $uri =404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass unix:/run/php/php8.1-fpm.sock;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
}
location / {
try_files $uri $uri/ /index.php?$query_string;
}
}file/laravel.conf
Задачи в php_install.yml установят PHP 8.1 и различные пакеты, необходимые для веб-сайта. После установки PHP мы также настроим Composer. Список пакетов и composer_path находятся в списке в defaults/main.yml.
- name: Only run "update_cache=yes" if the last one is more than 3600 seconds ago
ansible.builtin.apt:
update_cache: yes
cache_valid_time: 3600
- name: install php packages
apt:
name: "{{ php_pkgs }}"
state: present
- name: Checks if Composer is already installed
command: "{{ composer_path }}"
ignore_errors: true
register: composer_installed
- name: Install Composer if its not already installed
block:
- name: Download Composer Installation Script (if not already installed)
get_url:
url: https://getcomposer.org/installer
dest: /tmp/composer-setup.php
- name: Run Composer Installer (if not already installed)
command:
cmd: /usr/bin/php /tmp/composer-setup.php
creates: composer.phar
- name: Copy Composer Executable to /usr/local/bin
become: true
copy:
src: composer.phar
dest: /usr/local/bin/composer
remote_src: yes
mode: '0755'
- name: Remove phar
file:
path: composer.phar
state: absent
- name: Remove Install Script
file:
path: /tmp/composer-setup.php
state: absent
when: composer_installed is failedtasks/php_install.yml
---
# defaults file for laravel_role
php_pkgs:
- php8.1
- php8.1-mbstring
- php8.1-gettext
- php8.1-zip
- php8.1-fpm
- php8.1-curl
- php8.1-mysql
- php8.1-gd
- php8.1-cgi
- php8.1-soap
- php8.1-sqlite3
- php8.1-xml
- php8.1-redis
- php8.1-bcmath
- php8.1-imagick
- php8.1-intl
composer_path: /usr/local/bin/composerdefaults/main.yml
Последний набор задач развертывает код для сайта Laravel. Я использую проект, созданный Джеффри Уэй, Laravel From Scratch Blog Project, который создаст локальный сайт блога при развертывании с использованием Molecule.
Вышеуказанные задачи позволяют клонировать проект на наш хост, который создается как .env, так и databse.php файлы. Мы установим переменные окружения, необходимые для файла .env, в molecule.yml. Далее мы обновляем зависимости Composer и запускаем установку. Наконец, мы используем Artisan для запуска миграций, заполнения базы данных и генерации APP_KEY для защиты нашего сайта.
---
- name: create /var/www/ directory
file:
dest: /var/www/
state: directory
owner: www-data
group: www-data
mode: 0700
- block:
- name: Clone git repository
git:
dest: /var/www/laravel
repo: https://github.com/JeffreyWay/Laravel-From-Scratch-Blog-Project.git
update: no
register: repo
- name: set .env file
template:
src: env.j2
dest: /var/www/laravel/.env
- name: set database.php conf file
copy:
src: database.php
dest: /var/www/laravel/config/database.php
mode: u+rw,g-rw,o-r
- name: Composer update
command:
cmd: composer update
chdir: /var/www/laravel
- name: composer install
command:
cmd: composer install
chdir: /var/www/laravel
- name: php artisan steps
command:
cmd: php artisan {{ item }}
chdir: /var/www/laravel
with_items:
- migrate --seed --force
- storage:link
- config:clear
- key:generate --force
become: true
become_user: www-data
notify:
- restart php8.1-fpm
- restart nginxtasks/deploy_site.php
DB_CONNECTION={{ lookup('env','DB_CONNECTION') }}
DB_HOST={{ lookup('env','DB_HOST') }}
DB_PORT={{ lookup('env','DB_PORT') }}
DB_DATABASE={{ lookup('env','DB_DATABASE') }}
DB_USERNAME={{ lookup('env','DB_USERNAME') }}
DB_PASSWORD={{ lookup('env','DB_PASSWORD') }}
APP_ENV={{ lookup('env','APP_ENV') }}
APP_DEBUG={{ lookup('env','APP_DEBUG') }}
APP_KEY=templates/.env.j2
<?php
use Illuminate\Support\Str;
return [
'default' => env('DB_CONNECTION', 'mysql'),
'connections' => [
'mysql' => [
'driver' => 'mysql',
'url' => env('DATABASE_URL'),
'host' => env('DB_HOST', '127.0.0.1'),
'port' => env('DB_PORT', '3306'),
'database' => env('DB_DATABASE', 'forge'),
'username' => env('DB_USERNAME', 'forge'),
'password' => env('DB_PASSWORD', ''),
'unix_socket' => env('DB_SOCKET', ''),
'charset' => 'utf8mb4',
'collation' => 'utf8mb4_unicode_ci',
'prefix' => '',
'prefix_indexes' => true,
'strict' => true,
'engine' => 'InnoDB ROW_FORMAT=DYNAMIC',
'options' => extension_loaded('pdo_mysql') ? array_filter([
PDO::MYSQL_ATTR_SSL_CA => env('MYSQL_ATTR_SSL_CA'),
]) : [],
],
],
'migrations' => 'migrations',
];files/database.php
Вот с чего мы начнем. Имейте в виду, что мы не тестируем сам веб-сайт с помощью Molecule, мы просто проверяем возможность развертывания сайта. И по мере того, как мы исследуем идемпотентность и linting, мы будем соответствующим образом обновлять эти файлы. Но, прежде чем мы перейдем к компоновке, давайте посмотрим, как мы запускаем миграции или начальные компоненты без установки базы данных. Чтобы сделать это, нам нужно посмотреть на конфигурацию нашей Molecule и на то, как использовать несколько контейнеров.
Molecule
Платформы: Несколько контейнеров
Одним из преимуществ Molecule и Docker – они предоставляют средства для развертывания нескольких контейнеров. а это значит, что если мы хотим протестировать базу данных или роль обмена сообщениями, мы можем это сделать. В нашем случае это позволяет нам развернуть контейнер MySQL, выполнить миграции и ввести исходные данные для нашей роли Laravel.
Теперь давайте посмотрим на файл molecule.yml. Подобно тому, что мы делали в части 1, в блоке platforms: - это то место, где мы хотим настроить наши контейнеры. Этот раздел позволяет нам настраивать контейнеры аналогично docker-compose. Здесь мы определяем сети, тома, изображения и открытые порты. Для этого набора тестов мы используем контейнеры, созданные Джеффом Герлингом. Эти контейнеры специально разработаны для обеспечения тестирования сервисов, развернутых Ansible в контейнерах.
platforms:
- name: site
image: "geerlingguy/docker-ubuntu2204-ansible:latest"
volumes:
- /sys/fs/cgroup:/sys/fs/cgroup:ro
privileged: true
pre_build_image: true
published_ports:
- 0.0.0.0:8080:80/tcp
networks:
- name: "laravel"
- name: mysql
image: "geerlingguy/docker-ubuntu2204-ansible:latest"
volumes:
- /sys/fs/cgroup:/sys/fs/cgroup:ro
privileged: true
pre_build_image: true
published_ports:
- 0.0.0.0:3306:3306/tcp
networks:
- name: "laravel"Краткое объяснение некоторых опций, которые я использую здесь:
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, мне нужно было одно место для значений, доступных как сайту, так и базе данных.
provisioner:
name: ansible
env:
DB_CONNECTION: mysql
DB_HOST: mysql
DB_PORT: 3306
DB_DATABASE: blog
DB_USERNAME: molecule
DB_PASSWORD: moleculepass
APP_ENV: local
APP_DEBUG: trueConverge:деплой двух ролей
На этом этапе мы можем развернуть два разных контейнера в общей сети и предоставить Ansible некоторые переменные среды. Итак, как же нам подготовить эти отдельные контейнеры? Для этого необходимо несколько ключевых элементов. Мы можем начать с добавления зависимостей с помощью Ansible Galaxy и файла requirements.yml. Затем мы можем добавить блок dependency: в наш файл Molecule.
dependency:
name: galaxy
options:
ignore-certs: True
ignore-errors: True
role-file: molecule/requirements.ymldependency block for molecule.yml
---
roles:
- name: geerlingguy.mysql-fork
src: https://github.com/PCritchfield/ansible-role-mysql.gitmolecule/requirements.yml
Эти фрагменты сообщают Molecule, что нам нужно установить мою развилку роли geerlingguy.mysql с GitHub, прежде чем мы обработаем наш converge. Теперь, когда у нас есть роль, которая установит MySQL в наш контейнер, нам нужно запустить ее. Мы должны взглянуть на наш файл converge.yml. В предыдущей статье говорилось, что converge.yml – это учебное пособие, которое Molecule будет использовать для создания наших контейнеров. С этой целью нашему converge необходимо будет настроить таргетинг на несколько хостов. Ранее я упоминал, что название, которое мы даем каждому контейнеру в блоке platforms: – это то, что Molecule использует для инвентаризации, позволяя нам сделать что-то похожее на следующее:
---
- name: Converge - DB
hosts: mysql
vars:
mysql_databases:
- name: "{{ lookup('env','DB_DATABASE') }}"
mysql_users:
- name: "{{ lookup('env','DB_USERNAME') }}"
password: "{{ lookup('env','DB_PASSWORD') }}"
host: site.laravel
priv: "*.*:ALL"
tasks:
- name: "Setup MySQL DB"
include_role:
name: "geerlingguy.mysql-fork"
- name: Converge - Site
hosts: site
tasks:
- name: "Include laravel_role"
include_role:
name: "laravel_role"В этот момент molecule.yml должен выглядеть примерно так:
---
dependency:
name: galaxy
options:
ignore-certs: True
ignore-errors: True
role-file: molecule/requirements.yml
driver:
name: docker
platforms:
- name: site
image: "geerlingguy/docker-ubuntu2204-ansible:latest"
volumes:
- /sys/fs/cgroup:/sys/fs/cgroup:ro
privileged: true
pre_build_image: true
published_ports:
- 0.0.0.0:8080:80/tcp
networks:
- name: "laravel"
- name: mysql
image: "geerlingguy/docker-centos7-ansible:latest"
volumes:
- /sys/fs/cgroup:/sys/fs/cgroup:ro
privileged: true
pre_build_image: true
published_ports:
- 0.0.0.0:3306:3306/tcp
networks:
- name: "laravel"
provisioner:
name: ansible
env:
DB_CONNECTION: mysql
DB_HOST: mysql
DB_PORT: 3306
DB_DATABASE: blog
DB_USERNAME: molecule
DB_PASSWORD: moleculepass
APP_ENV: local
APP_DEBUG: true
verifier:
name: testinfraНаконец, вся подготовительная работа завершена, и мы должны выполнить команду: molecule converge . Если все работает правильно, Molecule должен извлечь роль MySQL из Galaxy, запустить два контейнера и запустить плейбуки на их целевых хостах. Мы публикуем сообщения в контейнерах, поэтому мы можем перейти к http://localhost:8080 и взаимодействовать с функциональным блогом.
Идемпотентность?
И да, и нет.
Да, так как у нас есть уверенность в том, что задачи, которые зависят от разных хостов, могут делать то, что нам нужно.
Нет, потому что некоторые из этих задач завершатся неудачей при запуске на существующем сервере. Эти сбои могут привести к головной боли для разработчиков или, что еще хуже, к простою в проде.
Давайте начнем с определения идемпотентности. Согласно Википедии, “Идемпотентность – это свойство определенных операций в математике и информатике, посредством которого они могут быть применены несколько раз без изменения результата за пределами первоначального применения”. Это означает, что независимо от того, сколько раз мы запускаем плейбуки Ansible, изменения должны применяться только при первом запуске задачи.
Вот почему идемпотентность жизненно важна для ваших ролей Ansible. Зачем устанавливать что-то дважды? Не рискуйте обновлять текущую версию Java или Nginx, когда вы можете использовать Molecule для определения возможных изменений, если вы дважды запустите свою роль.
Когда мы запустим команду idempotence, Molecule повторно запустит converge.yml и убедится, что ни одна из задач не создает изменений. Давайте посмотрим, как будет выглядеть этот результат. Запустите команду molecule idempotence, и вы должны получить следующее:
PLAY RECAP *********************************************************************
mysql : ok=32 changed=1 unreachable=0 failed=0 skipped=23 rescued=0 ignored=0
site : ok=20 changed=7 unreachable=0 failed=0 skipped=5 rescued=0 ignored=0
CRITICAL Idempotence test failed because of the following tasks:
* => geerlingguy.mysql : Ensure MySQL users are present.
* => geerlingguy.mysql : Ensure MySQL users are present.
* => laravel_role : Checks if Composer is already installed
* => laravel_role : set .env file
* => laravel_role : Composer update
* => laravel_role : composer install
* => laravel_role : php artisan steps
* => laravel_role : php artisan steps
* => laravel_role : php artisan steps
* => laravel_role : php artisan steps
* => laravel_role : php artisan steps
* => laravel_role : php artisan stepsМы видим, что несколько задач вносят изменения в запущенные экземпляры. Мы также можем видеть, что роль geerlingguy.mysql приводит к сбою нашей проверки на идемпотентность, но поскольку мы не тестируем эту роль, нам нужно убедиться, что наша проверка на идемпотентность игнорирует эту часть converge. Чтобы сделать это, мы можем добавить строку tags: molecule-idempotence-notest.
---
- name: Converge - DB
hosts: mysql
vars:
mysql_databases:
- name: "{{ lookup('env','DB_DATABASE') }}"
mysql_users:
- name: "{{ lookup('env','DB_USERNAME') }}"
password: "{{ lookup('env','DB_PASSWORD') }}"
host: site.laravel
priv: "*.*:ALL"
tasks:
- name: "Setup MySQL DB"
include_role:
name: "geerlingguy.mysql"
tags: molecule-idempotence-notest
- name: Converge - Site
hosts: site
tasks:
- name: "Include laravel_role"
include_role:
name: "laravel_role"Как и большинство тегов Ansible, мы можем использовать это в любой области. Здесь мы используем его, чтобы пропустить всю роль, но мы также могли бы использовать его для пропуска задач. С этим обновлением давайте повторим проверку идемпотентности. Molecule теперь проигнорирует первый раздел converge, который нацелен на контейнер базы данных, и выдаст нам результат, который выглядит следующим образом:
PLAY RECAP *********************************************************************
site : ok=20 changed=7 unreachable=0 failed=0 skipped=5 rescued=0 ignored=0
CRITICAL Idempotence test failed because of the following tasks:
* => laravel_role : Checks if Composer is already installed
* => laravel_role : set .env file
* => laravel_role : Composer update
* => laravel_role : composer install
* => laravel_role : php artisan steps
* => laravel_role : php artisan steps
* => laravel_role : php artisan steps
* => laravel_role : php artisan steps
* => laravel_role : php artisan steps
* => laravel_role : php artisan stepsОтлично, в итоговых данных нет хоста MySQL. Теперь, когда мы знаем, что наши проверки Molecule будут нацелены только на то, что мы хотим, нам нужно очистить остальную часть нашего кода. Преимущество выходных данных в том, что мы знаем, какие именно задачи вызывают наши проблемы с идемпотентностью. Мы начнем с самого начала задачи, которая устанавливает Composer.
Поскольку мы используем командный модуль для проверки наличия двоичного файла Composer, он всегда будет возвращать измененный. Что нас волнует, так это выходные данные, которые мы регистрируем, поэтому мы можем просто добавить параметр changed_when: false к задаче Checks if Composer is already installed в php_install.yml.
- name: Checks if Composer is already installed
command: "{{ composer_path }}"
ignore_errors: true
register: composer_installed
changed_when: falseОстальные сбои идемпотентности происходят из deploy_site.yml. Если мы посмотрим, то увидим, что мы выполняем несколько задач, которые требуются только при первоначальном развертывании сайта. Чтобы исправить это, мы можем поместить эти задачи в блок с помощью инструкции when, которая проверяет, произошло ли клонирование git. Во-первых, мы хотим переместить задачу Clone git repository из существующего блока в отдельную задачу и зарегистрировать выходные данные задачи. Помните, что нам нужно будет добавить параметры для запуска задачи от имени пользователя www-data в строки 10-17. Как только мы переместим эту задачу, мы хотим изменить оставшийся блок, чтобы проверить зарегистрированный вывод на предмет измененного статуса в строке 56.
---
- name: create /var/www/ directory
file:
dest: /var/www/
state: directory
owner: www-data
group: www-data
mode: 0700
- name: Clone git repository
git:
dest: /var/www/laravel
repo: https://github.com/JeffreyWay/Laravel-From-Scratch-Blog-Project.git
update: no
register: repo
become: true
become_user: www-data
name: configure site
- block:
- name: set .env file
template:
src: env.j2
dest: /var/www/laravel/.env
- name: set database.php conf file
copy:
src: database.php
dest: /var/www/laravel/config/database.php
mode: u+rw,g-rw,o-r
- name: Composer update
command:
cmd: composer update
chdir: /var/www/laravel
- name: composer install
command:
cmd: composer install
chdir: /var/www/laravel
- name: php artisan steps
command:
cmd: php artisan {{ item }}
chdir: /var/www/laravel
with_items:
- migrate --seed --force
- storage:link
- config:clear
- key:generate --force
become: true
become_user: www-data
notify:
- restart php8.1-fpm
- restart nginx
when: repo is changedКак только мы внесем эти изменения, мы сможем повторно запустить тест на идемпотентность. Теперь давайте запустим команду molecule idempotence и посмотрим, что мы получим. Если весь наш код обновлен правильно, мы должны увидеть следующий вывод:
PLAY RECAP *********************************************************************
site : ok=13 changed=0 unreachable=0 failed=0 skipped=10 rescued=0 ignored=0
INFO Idempotence completed successfullyОтлично, мы на один шаг приблизились к точному и функциональному набору тестов Molecule.
Линтинг
Теперь мы уже знаем, что наш код Ansible функционален и идемпотентен, но является ли он чистым и соответствующим стандартам? Чтобы выяснить это, мы можем запустить наш код через линтер. Чтобы протестировать линтинг в Molecule, вам сначала нужно включить его в главном файле. Мы можем сделать это, добавив блок lint: в конец molecule.yml под блок verifier:
..
verifier:
name: testinfra
lint: |
set -e
yamllint .
ansible-lintВы заметите, что я использую здесь два разных линтера yamllint и ansible-lint. yamllint фокусируется на синтаксисе YAML и других методах, связанных с YAML, в то время как ansible-lint фокусируется на коде и поведении, ориентированных на Ansible. Есть третий вариант, который я бы порекомендовал, если вы используете testinfra, flake8, который поможет поддерживать ваши тесты на Python в соответствии со стандартами.
Как только мы добавили блок lint:, мы можем запустить molecule lint и посмотреть, где мы могли бы захотеть улучшить наш код.
INFO Running default > lint
WARNING Listing 30 violation(s) that are fatal
fqcn-builtins: Use FQCN for builtin actions.
handlers/main.yml:3 Task/Handler: restart php8.1-fpm
fqcn-builtins: Use FQCN for builtin actions.
handlers/main.yml:11 Task/Handler: restart nginx
meta-incorrect: Should change default metadata: company
meta/main.yml:1
meta-incorrect: Should change default metadata: license
meta/main.yml:1
fqcn-builtins: Use FQCN for builtin actions.
molecule/default/converge.yml:13 Task/Handler: Setup MySQL DB
fqcn-builtins: Use FQCN for builtin actions.
molecule/default/converge.yml:21 Task/Handler: Include laravel_role
fqcn-builtins: Use FQCN for builtin actions.
tasks/deploy_site.yml:2 Task/Handler: create /var/www/ directory
fqcn-builtins: Use FQCN for builtin actions.
tasks/deploy_site.yml:10 Task/Handler: Clone git repository
git-latest: Git checkouts must contain explicit version.
tasks/deploy_site.yml:10 Task/Handler: Clone git repository
no-handler: Tasks that run when changed should likely be handlers.
tasks/deploy_site.yml:19 Task/Handler: Configure the site then migrate and seed the database
fqcn-builtins: Use FQCN for builtin actions.
tasks/deploy_site.yml:21 Task/Handler: set .env file
risky-file-permissions: File permissions unset or incorrect.
tasks/deploy_site.yml:21 Task/Handler: set .env file
fqcn-builtins: Use FQCN for builtin actions.
tasks/deploy_site.yml:26 Task/Handler: set database.php conf file
fqcn-builtins: Use FQCN for builtin actions.
tasks/deploy_site.yml:32 Task/Handler: Composer update
no-changed-when: Commands should not change things if nothing needs doing.
tasks/deploy_site.yml:32 Task/Handler: Composer update
fqcn-builtins: Use FQCN for builtin actions.
tasks/deploy_site.yml:37 Task/Handler: composer install
no-changed-when: Commands should not change things if nothing needs doing.
tasks/deploy_site.yml:37 Task/Handler: composer install
fqcn-builtins: Use FQCN for builtin actions.
tasks/deploy_site.yml:42 Task/Handler: php artisan steps
no-changed-when: Commands should not change things if nothing needs doing.
tasks/deploy_site.yml:42 Task/Handler: php artisan steps
fqcn-builtins: Use FQCN for builtin actions.
tasks/nginx_install.yml:7 Task/Handler: install nginx
fqcn-builtins: Use FQCN for builtin actions.
tasks/nginx_install.yml:15 Task/Handler: Make sure a service unit is running
fqcn-builtins: Use FQCN for builtin actions.
tasks/nginx_install.yml:21 Task/Handler: copy over config
fqcn-builtins: Use FQCN for builtin actions.
tasks/php_install.yml:6 Task/Handler: install php and related packages
fqcn-builtins: Use FQCN for builtin actions.
tasks/php_install.yml:11 Task/Handler: Checks if Composer is already installed
fqcn-builtins: Use FQCN for builtin actions.
tasks/php_install.yml:20 Task/Handler: Download Composer Installation Script (if not already installed)
risky-file-permissions: File permissions unset or incorrect.
tasks/php_install.yml:20 Task/Handler: Download Composer Installation Script (if not already installed)
fqcn-builtins: Use FQCN for builtin actions.
tasks/php_install.yml:25 Task/Handler: Run Composer Installer (if not already installed)
fqcn-builtins: Use FQCN for builtin actions.
tasks/php_install.yml:30 Task/Handler: Copy Composer Executable to /usr/local/bin
fqcn-builtins: Use FQCN for builtin actions.
tasks/php_install.yml:38 Task/Handler: Remove phar
fqcn-builtins: Use FQCN for builtin actions.
tasks/php_install.yml:43 Task/Handler: Remove Install Script
You can skip specific rules or tags by adding them to your configuration file:
# .config/ansible-lint.yml
warn_list: # or 'skip_list' to silence them completely
- experimental # all rules tagged as experimental
- fqcn-builtins # Use FQCN for builtin actions.
- git-latest # Git checkouts must contain explicit version.
- meta-incorrect # meta/main.yml default values should be changed.
- no-changed-when # Commands should not change things if nothing needs doing.
- no-handler # Tasks that run when changed should likely be handlers.
Finished with 29 failure(s), 2 warning(s) on 26 files.
WARNING Retrying execution failure 2 of: s e t - e
y a m l l i n t .
a n s i b l e - l i n t
CRITICAL Lint failed with error code 2Ого, да здесь масса потенциальных проблем, которые нужно решить. С чего нам следует начать? Давайте начнем с того, который имеет 21 случай, fqcn-builtins: Use FQCN for builtin actions. Эта ошибка означает, что мы не используем полное имя коллекции (FQCN) для многих наших задач Ansible. Нам нужно обновить все затронутые задачи до ansible.builtin.<MODULE_NAME>. Чтобы все было проще, я просто показываю ошибку и то, как должен выглядеть новый идентификатор задачи.
handlers/main.yml:3 Task/Handler: restart php8.1-fpm
ansible.builtin.sysvinit:
handlers/main.yml:11 Task/Handler: restart nginx
ansible.builtin.sysvinit:
molecule/default/converge.yml:13 Task/Handler: Setup MySQL DB
ansible.builtin.include_role:
molecule/default/converge.yml:21 Task/Handler: Include laravel_role
ansible.builtin.include_role:
tasks/deploy_site.yml:2 Task/Handler: create /var/www/ directory
ansible.builtin.file:
tasks/deploy_site.yml:10 Task/Handler: Clone git repository
ansible.builtin.git:
tasks/deploy_site.yml:21 Task/Handler: set .env file
ansible.builtin.template:
tasks/deploy_site.yml:26 Task/Handler: set database.php conf file
ansible.builtin.copy:
tasks/deploy_site.yml:32 Task/Handler: Composer update
ansible.builtin.shell:
tasks/deploy_site.yml:37 Task/Handler: composer install
ansible.builtin.shell:
tasks/deploy_site.yml:42 Task/Handler: php artisan steps
ansible.builtin.shell:
tasks/nginx_install.yml:7 Task/Handler: install nginx
ansible.builtin.apt:
tasks/nginx_install.yml:15 Task/Handler: Make sure a service unit is running
ansible.builtin.sysvinit:
tasks/nginx_install.yml:21 Task/Handler: copy over config
ansible.builtin.copy:
tasks/php_install.yml:6 Task/Handler: install php and related packages
ansible.builtin.apt:
tasks/php_install.yml:11 Task/Handler: Checks if Composer is already installed
ansible.builtin.command:
tasks/php_install.yml:20 Task/Handler: Download Composer Installation Script (if not already installed)
ansible.builtin.get_url:
tasks/php_install.yml:25 Task/Handler: Run Composer Installer (if not already installed)
ansible.builtin.command:
tasks/php_install.yml:30 Task/Handler: Copy Composer Executable to /usr/local/bin
ansible.builtin.copy:
tasks/php_install.yml:38 Task/Handler: Remove phar
ansible.builtin.file:
tasks/php_install.yml:43 Task/Handler: Remove Install Script
ansible.builtin.file:А теперь, когда они исправлены, давайте посмотрим на то, что осталось.
INFO Running default > lint
WARNING Listing 12 violation(s) that are fatal
meta-incorrect: Should change default metadata: company
meta/main.yml:1
meta-incorrect: Should change default metadata: license
meta/main.yml:1
git-latest: Git checkouts must contain explicit version.
tasks/deploy_site.yml:10 Task/Handler: Clone git repository
no-handler: Tasks that run when changed should likely be handlers.
tasks/deploy_site.yml:19 Task/Handler: Configure the site then migrate and seed the database
risky-file-permissions: File permissions unset or incorrect.
tasks/deploy_site.yml:21 Task/Handler: set .env file
no-changed-when: Commands should not change things if nothing needs doing.
tasks/deploy_site.yml:32 Task/Handler: Composer update
no-changed-when: Commands should not change things if nothing needs doing.
tasks/deploy_site.yml:37 Task/Handler: composer install
no-changed-when: Commands should not change things if nothing needs doing.
tasks/deploy_site.yml:42 Task/Handler: php artisan steps
risky-file-permissions: File permissions unset or incorrect.
tasks/php_install.yml:20 Task/Handler: Download Composer Installation Script (if not already installed)
Из оставшихся ошибок есть две, которые мы можем игнорировать: meta-incorrect, что означает, что файл в нашем каталоге ./meta по-прежнему содержит информацию по умолчанию, и no-changed-when , что означает, что конкретные задачи не являются идемпотентными. Поскольку нас не интересует метаинформация и дополнительные проверки и тесты на идемпотентность, мы можем пропустить их оба. Так как же нам пропустить эти проверки? Путем добавления файла .ansible-lint в каталог Molecule.
skip_list: # or 'skip_list' to silence them completely
- meta-incorrect # meta/main.yml default values should be changed.
- no-changed-when # Commands should not change things if nothing needs doing.Сделав это, мы можем снова запустить molecule lint и увидеть, что у нас осталось всего 4 нарушения.
INFO Running default > lint
WARNING Listing 4 violation(s) that are fatal
git-latest: Git checkouts must contain explicit version.
tasks/deploy_site.yml:10 Task/Handler: Clone git repository
no-handler: Tasks that run when changed should likely be handlers.
tasks/deploy_site.yml:19 Task/Handler: Configure the site then migrate and seed the database
risky-file-permissions: File permissions unset or incorrect.
tasks/deploy_site.yml:21 Task/Handler: set .env file
risky-file-permissions: File permissions unset or incorrect.
tasks/php_install.yml:20 Task/Handler: Download Composer Installation Script (if not already installed)
Finished with 2 failure(s), 2 warning(s) on 26 files.
Первая ошибка git-latest. Это говорит нам, что мы должны привязать версию к нашей задаче git вместо того, чтобы предполагать основную ветвь. Исправить это так же просто, как добавить к задаче однострочную version: main .
- name: Clone git repository
ansible.builtin.git:
dest: /var/www/laravel
repo: https://github.com/JeffreyWay/Laravel-From-Scratch-Blog-Project.git
update: no
version: main
become: true
become_user: www-data
notify:
- configure site
- restart php8.1-fpm
- restart nginxСледующее нарушение no-handler. Эта ошибка дает нам знать, что у нас есть задача или серия задач, которые выполняются только при изменении. Мы должны использовать функцию обработчика для выполнения задач. Исправление этого нарушения требует ряда изменений, начиная с блока задач configure site из deploy_sites.yml в отдельный файл. Я начал с tasks/configure_site.yml.
- name: configure site
block:
- name: set .env file
ansible.builtin.template:
src: env.j2
dest: /var/www/laravel/.env
mode: '0755'
- name: set database.php conf file
ansible.builtin.copy:
src: database.php
dest: /var/www/laravel/config/database.php
mode: u+rw,g-rw,o-r
- name: Composer update
ansible.builtin.command:
cmd: composer update
chdir: /var/www/laravel
- name: composer install
ansible.builtin.command:
cmd: composer install
chdir: /var/www/laravel
- name: php artisan steps
ansible.builtin.command:
cmd: php artisan {{ item }}
chdir: /var/www/laravel
with_items:
- migrate --seed --force
- storage:link
- config:clear
- key:generate --force
become: true
become_user: www-dataЗатем нам нужно внести дополнительное обновление в задачу git, добавив другой обработчик.
notify:
- configure site
- restart php8.1-fpm
- restart nginxНаконец, нам нужно обновить handlers/main.yml для вызова tasks/configure_site.yml, чтобы действовать при срабатывании notify.
---
# handlers file for laravel_role
- name: configure site
include_tasks: tasks/configure_site.yml
- name: restart php8.1-fpm
ansible.builtin.sysvinit:
name: php8.1-fpm
state: "{{ item }}"
with_items:
- stopped
- started
- name: restart nginx
ansible.builtin.sysvinit:
name: nginx
state: restartedПосле этого наши задачи по настройке нашего сайта и нашей базы данных будут выполняться только тогда, когда задача git зарегистрирует изменение.
Последнее нарушение lint это risky-file-permissions для двух файлов. Вкратце, мы не указывали разрешения для файлов, обрабатываемых Ansible, оставляя место для чрезмерно разрешающих или ограничительных разрешений для файлов. Это изменение легко устранить, добавив опцию mode: <PERMISSIONS> к файлам, которые мы обрабатываем.
tasks/configure_site.yml
- name: set .env file
ansible.builtin.template:
src: env.j2
dest: /var/www/laravel/.env
mode: '0755'
tasks/php_install.yml
- name: Download Composer Installation Script (if not already installed)
ansible.builtin.get_url:
url: https://getcomposer.org/installer
dest: /tmp/composer-setup.php
mode: '0755'После того, как мы закончим вносить эти изменения, мы можем запустить molecule lint в последний раз и убедиться, что он не возвращает никаких нарушений.
Подводя итоги
Как только последняя секция будет завершена, мы сможем собрать все это вместе и запустить molecule test, позволяющий нам увидеть все эти изменения за один прогон.
Наша роль Ansible может протестировать миграции вашей базы данных, а мы успешно подтвердили ее идемпотентность и поработали над тем, чтобы она соответствовала стандартам кодирования. Теперь вы можете двигаться дальше со знанием и уверенностью в том, что ваши роли в Ansible будут рабочими и стабильными.
Поток «Ansible: Infrastructure as Code» стартует 6 февраля.
funca
Интересно зачем конфигурационному файлу, содержащему пароли, такие права?