lae.travis-lxc

Настраивает и запускает N контейнеров LXC для использования в среде Travis CI для упрощенного тестирования ролей Ansible на разных дистрибутивах.

Использование

Вы хотите протестировать свои роли Ansible на Travis CI, но не хотите использовать Docker, потому что это не имитирует полноценную ОС? Вам нужно использовать LXC. Эта роль, надеюсь, упростит многие рутинные задачи, которые вам могли бы понадобиться.

Чтобы начать, минимальный .travis.yml, который тщательно тестирует вашу роль на корректность, идемпотентность и функциональность, может выглядеть так:

---
language: python
sudo: required
dist: bionic
install:
- pip install ansible
- ansible-galaxy install lae.travis-lxc,v0.9.0
- ansible-playbook tests/install.yml -i tests/inventory
before_script: cd tests/
script:
# Проверяет синтаксис вашего playbook'а развертывания, который должен содержать вашу роль
- ansible-playbook -i inventory deploy.yml --syntax-check
# Запускает playbook развертывания
- ansible-playbook -i inventory deploy.yml
# Запускает playbook развертывания снова, сохраняя вывод в файл под названием play.log,
# затем проверяет, что нет изменённых/неудачных задач и завершает с ошибкой, если они есть.
- 'ANSIBLE_STDOUT_CALLBACK=debug ANSIBLE_DISPLAY_SKIPPED_HOSTS=no ANSIBLE_DISPLAY_OK_HOSTS=no
  unbuffer ansible-playbook -vvi inventory deploy.yml &>play.log; printf "Идемпотентность: ";
  grep -A1 "PLAY RECAP" play.log | grep -qP "changed=0 .*failed=0 .*"
  && (echo "УСПЕХ"; exit 0) || (echo "НЕУСПЕХ"; cat play.log; exit 1)'
# Интеграционные тесты и тому подобное
- ANSIBLE_STDOUT_CALLBACK=debug ansible-playbook -i inventory -v test.yml

Вы заметите, что ссылается на четыре файла. Вы можете решить, как определить ваш процесс сборки, но следующее обычно удовлетворяет большинству целей:

• tests/install.yml: выполняет lae.travis-lxc и другие шаги предустановки
• tests/deploy.yml: выполняет роль, которую вы тестируете
• tests/test.yml: выполняет тесты проверки вашей развертки
• tests/inventory: содержит список имен хостов контейнеров LXC

install.yml может выглядеть так:

---
- hosts: localhost
  connection: local
  roles:
    - lae.travis-lxc
  vars:
    test_profiles:
      - profile: debian-buster
      - profile: ubuntu-focal
      - profile: centos-7
      - profile: alpine-v3.11

# Добавьте любые другие задачи настройки, которые вам могут понадобиться, но которые не обязательно должны быть в вашей роли
- hosts: all
  tasks: []

Первый play разворачивает три контейнера на трех разных дистрибутивах. Второй play может быть использован для выполнения других ролей или предварительных задач установки, которые вы бы не ожидали, что ваша роль выполнит (например, установить epel-release или создать узел устройства для FUSE (потому что LXC этого не делает для вас)).

deploy.yml может выглядеть так:

---
- hosts: all
  become: true
  any_errors_fatal: true
  roles:
    - ansible-role-strawberry-milk
  vars:
    number_of_cartons: 15

Это, по сути, отображение того, что вернёт ansible-galaxy init в test.yml. Это будет содержать все, что вам нужно для правильного выполнения вашей роли. Для более сложных ролей имеет смысл разделить переменные на папку tests/group_vars и соответственно настроить ваш инвентарь.

test.yml должен содержать ваши тесты, если вы хотите выполнить какие-либо:

---
- hosts: all
  tasks:
    - name: Убедиться, что HTTP сервис Strawberry Milk работает
      uri:
        url: "http://{{ inventory_hostname }}:1515"
    - block:
      - name: Вывести конфигурацию Strawberry Milk
        shell: cat /etc/strawberry_milk.conf
        changed_when: false
      - name: Вывести системные журналы
        shell: "cat /var/log/messages || cat /var/log/syslog || journalctl -xb"
      ignore_errors: yes

Это может быть полезно, чтобы убедиться, что сервис работает, что кластер находится в здоровом состоянии, что создаются определённые файлы... вы поняли идею. Блок, который я здесь привел, предназначен для выполнения диагностических задач, чтобы помочь мне отладить проблемы, включая вывод журналов и тому подобное. Он обернут в ignore_errors, чтобы задачи здесь не повлияли на сборку (одной из основных причин возникновения ошибок является задача вывода журналов при тестировании нескольких дистрибутивов).

И наконец, инвентарь:

debian-buster-01
ubuntu-focal-01
centos-7-01
alpine-v3-11-01

Имена хостов генерируются из двух частей, префикса и суффикса. По умолчанию они генерируются из ключа profile в test_profiles в формате {{ profile }}-{{ suffix }}, где суффикс по умолчанию равен 01.

Как только вы написали эти файлы, вы готовы протестировать свою роль в Travis CI. Однако, скорее всего, вы хотите получить от этого больше, поэтому давайте рассмотрим некоторые другие темы.

Тестирование нескольких версий Ansible

Скорее всего, вы захотите протестировать свою роль как на ветке разработки, так и на всех поддерживаемых версиях Ansible. Это то, что вам будет нужно настроить в .travis.yml, и есть различные способы сделать это:

env:
- ANSIBLE_GIT_VERSION='devel'
- ANSIBLE_VERSION='~=2.9.0'
- ANSIBLE_VERSION='~=2.9.0'
- ANSIBLE_VERSION='~=2.7.0'
install:
- if [ "$ANSIBLE_GIT_VERSION" ]; then pip install "https://github.com/ansible/ansible/archive/${ANSIBLE_GIT_VERSION}.tar.gz";
  else pip install "ansible${ANSIBLE_VERSION}"; fi
- ansible --version

Здесь мы добавили задачу установки, которая либо возьмёт ANSIBLE_GIT_VERSION, как допустимую ссылку в репозитории git Ansible, либо ANSIBLE_VERSION, допустимую строку версии, которая может быть передана pip во время установки.

Производительность и профилирование Ansible

Вы можете поместить практически всё в tests/ansible.cfg.

[defaults]
callback_whitelist=profile_tasks
forks=20
internal_poll_interval = 0.001

Это запускает обратный вызов profile_tasks в вашем playbook'е, что помогает выявить, какие задачи требуют наибольшего времени для выполнения. Вы можете использовать это, чтобы выявить любые регрессии производительности, например. Если вы запускаете и работаете с вашим playbook'ом на нескольких контейнерах, указывайте forks. internal_poll_interval является хорошей общей настройкой, которую стоит использовать при наличии нескольких задач/циклов.

Кэширование

Образы LXC могут кэшироваться, чтобы сократить время выполнения базовой настройки, особенно когда вы тестируете на нескольких профилях. Поместите следующее в ваш .travis.yml, и эта роль позаботится об остальном.

cache:
  directories:
  - "$HOME/lxc"
  pip: true

(pip: true ничего не значит для этой роли, но он включен здесь, так как вы можете захотеть кэшировать вашу установку Ansible также.)

Переменные роли

Чтобы указать, на каких дистрибутивах тестировать, используйте test_profiles. Поддерживаемые профили включают (не стесняйтесь запрашивать/вносить новые):

test_profiles:
  - profile: alpine-v3.11
  - profile: alpine-v3.10
  - profile: alpine-v3.9
  - profile: centos-7
  - profile: debian-buster
  - profile: debian-stretch
  - profile: ubuntu-focal
  - profile: ubuntu-bionic
  - profile: ubuntu-xenial

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

test_profiles:
  - profile: alpine-v3.8
  - profile: alpine-v3.7
  - profile: alpine-v3.6
  - profile: centos-6
  - profile: debian-jessie
  - profile: debian-wheezy
  - profile: fedora-28
  - profile: fedora-27
  - profile: fedora-26
  - profile: fedora-25
  - profile: ubuntu-trusty

Вы можете посмотреть в vars/main.yml для получения дополнительной информации о этих профилях.

Тестовому контейнеру, если префикс не указан, даётся имя хоста {{ profile }}-{{ suffix }}, где profile очищается для использования в DNS имени. Параметры по умолчанию определены в vars/main.yml, так что обратитесь к нему, если не уверены, каков префикс конкретного профиля. Если test_host_suffixes не определен, suffix здесь становится целым числом с нулями, начинающимся с 1 (до запрашиваемого числа хостов, указанного в test_hosts_per_profile).

Например, следующее создаёт debian01, debian02 и debian03:

test_profiles:
  - profile: debian-buster
    prefix: debian
test_hosts_per_profile: 3

Следующее создаёт ubuntu-app-python2 и ubuntu-app-python3:

test_profiles:
  - profile: ubuntu-focal
    prefix: ubuntu-
test_host_suffixes:
  - app-python2
  - app-python3

Вы также можете переопределить используемую конфигурацию контейнера, если это необходимо (например, для монтирования общей папки):

container_config:
  - "lxc.aa_profile=unconfined"
  - "lxc.mount.auto=proc:rw sys:rw cgroup-full:rw"
  - "lxc.cgroup.devices.allow=a *:* rmw"

В случае, если вам это нужно (отсутствующие пакеты должны устанавливаться по умолчанию внутри этой роли, так что откройте проблему), вы также можете установить дополнительные пакеты внутри тестовых контейнеров:

additional_packages:
  - make

Если кэширование включено в .travis.yml, вы можете избирательно кэшировать подмножество ваших тестовых профилей, указав их в lxc_cache_profiles. Эти профили должны быть допустимыми и присутствовать в test_profiles.

Чтобы кэшировать в директорию, отличную от $HOME/lxc, измените lxc_cache_directory.

Если вам нужно отключить использование OverlayFS в контейнерах LXC (например, если вы пытаетесь использовать OverlayFS внутри контейнера LXC), установите lxc_use_overlayfs в no (или любое значение, равное False).

Участники

Musee Ullah (@lae, lae@lae.is)
Wilmar den Ouden (@wilmardo)

Стабильность

Эта роль всё ещё находится на этапе до версии 1.0 и, следовательно, не гарантируется её стабильность. Если у вас возникла проблема при использовании этой роли, откройте проблему с коротким описанием и любыми соответствующими логами, чтобы она могла быть решена и мы смогли стать на шаг ближе к нашей первой стабильной версии.

Пожалуйста, убедитесь, что вы прикрепляете конкретную версию (прикрепление к минорной версии может быть приемлемым) при использовании этой роли. Невыполнение этого может привести к тому, что ваши тесты начнут проваливаться из-за разрушительных изменений в минорной версии до выхода версии 1.0.