Как протестировать ANSI роли на разных дистрибутивах Linux + совместимость с различными ANSIL версиями с помощью молекулы и докера? - PullRequest
1 голос
/ 05 ноября 2019

Сценарий

Я хочу развить ансольные роли. Эти роли должны быть проверены с помощью процесса CI / CD с молекулой и использовать докер в качестве драйвера. Этот шаг проверки должен включать несколько разновидностей Linux (например, centos / ubuntu / debian), умноженных на поддерживаемые версии ANSI.

Затем следует выполнить тесты, чтобы роль проверялась с помощью

centos:7 + ansible:2.5
centos:7 + ansible:2.6
centos:7 + ansible:2.7
...
ubuntu:1604 + ansible:2.5
ubuntu:1604 + ansible:2.6
ubuntu:1604 + ansible:2.7
...

Рассматриваемые проблемы

  1. Официальный доступный образ недоступен
  2. Как лучше всего проверить роль на совместимость с доступной версией?

Выпуск 1: нет официальных ансибельных изображений

Официальные изображения ансайбл-команды устарели уже около 3 лет:

Кроме того, ссылка, на которую ссылаются устаревшие изображения, чтобы найти новые изображения с поддержкой ANSI, совершенно бесполезна из-за огромного количества результатов

https://hub.docker.com/search/?q=ansible&page=1&isAutomated=0&isOfficial=0&pullCount=1&starCount=0

Существует ли в сообществе (или ansible) хорошо поддерживаемый образ ансайла, который заполняет пустоту?

Предпочтителен с несколькими версиями, которые могут быть извлечены, и процессом КИ, которыйстроит и Vрегулярно изменяет созданное изображение.

Почему я ищу ансамбли? Я не хочу изобретать велосипед (если это возможно). Я хотел бы использовать изображения, чтобы проверить анальные роли через молекулу на предмет несовместимости версий.

Я искал, но не мог найти ничего действительно полезного. Какие изображения вы используете для запуска ansible в контейнере / оркестраторе? Вы сами создаете и поддерживаете изображения?

Например, https://hub.docker.com/r/ansibleplaybookbundle/apb-base/tags

выглядело многообещающе, однако изображения там также старше 7 месяцев (по крайней мере).


Проблема 2: как наилучшим образом проверить роль на совместимость с ANSIB-версией?

Является ли создание образов докеров для каждой комбинации ОС и ANSI-версии лучшим способом тестирования с помощью молекулы и докера в качестве драйвера? Или есть более разумный способ проверить обратную совместимость ансайловых ролей с разными версиями ансайла в разных ОС?

Я уже тестировал свои ансольные роли с молекулой и докером в качестве драйвера. Эти тесты в настоящее время только проверяют функциональность роли в различных дистрибутивах Linux, но не обеспечивают обратную обратную совместимость ANSI, выполняя роль с более ранними версиями ANSI.

Здесь приведен пример роли с тестами travis на основе centos7 / ubuntu1604 / ubuntu1804на роль ntp герлинггуа: https://github.com/Gepardec/ansible-role-ntp

Ответы [ 2 ]

1 голос
/ 14 ноября 2019

Решение

Чтобы протестировать ансольные роли с несколькими версиями ansible, python и различными версиями Linux, мы можем использовать

  • молекулу для нашей ансолевой ролифункциональность
  • докер в качестве нашего уровня абстракции, на котором мы запускаем целевую систему для нашей ответной роли
  • tox для настройки универсальных virtualenvs и тестирования наших различныхкомбинации без побочных эффектов
  • travis для автоматизации всего этого

Это будет довольно длинный / подробный ответ. Вы можете проверить пример ANSIBLE роли со всей установкой здесь


Шаг 1: проверка ансолевой роли с молекулой

Документация по молекулам: https://molecule.readthedocs.io/en/stable/

Исправления Проблема: 1) нет официальных ансамблей изображения

Я мог бы создавать ANSIB-изображения для каждого дистрибутива, который я хотел бы протестировать, как описывает Джефф Гирлинг в своих постах в блоге.

Очевидный недостаток этого подхода: изображения будут нуждаться в обслуживании (в конечном итоге)

Однако с помощью молекулы мы можем объединить базовые изображения с Dockerfile.j2 (шаблон Jinja2) для создания изображенийс минимальными требованиями для запуска ansible. Благодаря такому подходу мы теперь можем использовать официальные образы дистрибутивов Linux из Docker Hub, и нам не нужно поддерживать репозиторий Docker для каждого дистрибутива Linux и различных версий.

Здесь важные биты в молекуле.

platforms:
  - name: instance-${TOX_ENVNAME}
    image: ${MOLECULE_DISTRO:-'centos:7'}
    command: /sbin/init
    volumes:
      - /sys/fs/cgroup:/sys/fs/cgroup:ro
    privileged: true

Стандартный файл dockerfile.j2 из молекулы уже хорош, но у меня есть несколько дополнений

# Molecule managed

{% if item.registry is defined %}
FROM {{ item.registry.url }}/{{ item.image }}
{% else %}
FROM {{ item.image }}
{% endif %}

{% if item.env is defined %}
{% for var, value in item.env.items() %}
{% if value %}
ENV {{ var }} {{ value }}
{% endif %}
{% endfor %}
{% endif %}

RUN if [ $(command -v apt-get) ]; then                                                        apt-get update && apt-get install -y python sudo bash ca-certificates iproute2 && apt-get clean; \
    elif [ $(command -v zypper) ]; then                                                       zypper refresh && zypper install -y python sudo bash python-xml iproute2 && zypper clean -a; \
    elif [ $(command -v apk) ]; then                                                          apk update && apk add --no-cache python sudo bash ca-certificates; \
    elif [ $(command -v xbps-install) ]; then                                                 xbps-install -Syu && xbps-install -y python sudo bash ca-certificates iproute2 && xbps-remove -O; \
    elif [ $(command -v swupd) ]; then                                                        swupd bundle-add python3-basic sudo iproute2; \
    elif [ $(command -v dnf) ] && cat /etc/os-release | grep -q '^NAME=Fedora';          then dnf makecache && dnf --assumeyes install python sudo python-devel python*-dnf bash iproute && dnf clean all; \
    elif [ $(command -v dnf) ] && cat /etc/os-release | grep -q '^NAME="CentOS Linux"' ; then dnf makecache && dnf --assumeyes install python36 sudo platform-python-devel python*-dnf bash iproute && dnf clean all && ln -s /usr/bin/python3 /usr/bin/python; \
    elif [ $(command -v yum) ]; then                                                          yum makecache fast && yum install -y python sudo yum-plugin-ovl bash iproute && sed -i 's/plugins=0/plugins=1/g' /etc/yum.conf && yum clean all; \
    fi

# Centos:8 + ansible 2.7 failed with error: "The module failed to execute correctly, you probably need to set the interpreter"
# Solution: ln -s /usr/bin/python3 /usr/bin/python

По умолчанию это будет тестировать роль с помощью centos: 7. Тем не менее, мы можем установить переменную окружения MOLECULE_DISTRO для любого изображения, которое мы хотели бы протестировать, и запустить его через

MOLECULE_DISTRO=ubuntu:18.04 molecule test

Сводка

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

Файлы, использованные на этом шаге

Источник


Шаг 2. Проверьте совместимость вашей роли (Python версия X, ANSIBLE X версия дистрибутива Linux)

Исправления Проблема 2: как лучше всего проверить роль на совместимость с ANSIB версией?

Давайте использовать tox для создания виртуальных сред, чтобы избежать побочных эффектов при тестировании различных сценариев совместимости.

Здесь важные биты в tox.ini

[tox]
minversion = 3.7
envlist = py{3}-ansible{latest,29,28}-{   alpinelatest,alpine310,alpine39,alpine38,   centoslatest,centos8,centos7,   debianlatest,debian10,debian9,debian8,   fedoralatest,fedora30,fedora29,fedora28,   ubuntulatest,ubuntu2004,ubuntu1904,ubuntu1804,ubuntu1604   }

# only test currently supported ansible versions
# https://docs.ansible.com/ansible/latest/reference_appendices/release_and_maintenance.html#release-status

skipsdist = true

[base]
passenv = *
deps =
    -rrequirements.txt
    ansible25: ansible==2.5
    ...
    ansiblelatest: ansible
commands =
    molecule test
setenv =
    TOX_ENVNAME={envname}
    MOLECULE_EPHEMERAL_DIRECTORY=/tmp/{envname}

[testenv]
passenv = 
    {[base]passenv}
deps = 
    {[base]deps}
commands = 
    {[base]commands}
setenv =
    ...
    centoslatest:     MOLECULE_DISTRO="centos:latest"
    centos8:          MOLECULE_DISTRO="centos:8"
    centos7:          MOLECULE_DISTRO="centos:7"
    ...
    {[base]setenv}

Совокупность требований. Txt

docker
molecule

, просто выполнив

tox

, он создаст виртуальные envs для каждого компатаСочетание ibility, определенное в tox.ini как

envlist = py{3}-ansible{latest,29,28}-{   alpinelatest,alpine310,alpine39,alpine38,   centoslatest,centos8,centos7,   debianlatest,debian10,debian9,debian8,   fedoralatest,fedora30,fedora29,fedora28,   ubuntulatest,ubuntu2004,ubuntu1904,ubuntu1804,ubuntu1604   }

, что в данном конкретном случае означает: python3 x отчетная версия x linux distro

Отлично! Мы создали тесты для проверок совместимости с дополнительным преимуществом - всегда тестировать с ansible последней, чтобы замечать ранние изменения на раннем этапе.

Файлы, используемые на этом шаге

Источник


Шаг 3: CI с travis

Выполнение локальных проверок - это хорошо, работа в инструменте CI - это здорово. Итак, давайте сделаем это.

Для этой цели важны следующие биты в .travis.yml

---
version: ~> 1.0

os: linux
language: python

python:
  - "3.8"
  - "3.7"
  - "3.6"
  - "3.5"

services: docker

cache:
  pip: true
  directories:
  - .tox

install:
  - pip install tox-travis
env:
  jobs:
    # ansible:latest - check for breaking changes
    ...
    - TOX_DISTRO="centoslatest"     TOX_ANSIBLE="latest"
    - TOX_DISTRO="centos8"          TOX_ANSIBLE="latest"
    - TOX_DISTRO="centos7"          TOX_ANSIBLE="latest"
    ...
    # ansible: check version compatibility
    # only test currently supported ansible versions
    # 
https://docs.ansible.com/ansible/latest/reference_appendices/release_and_maintenance.html#release-status
    - TOX_DISTRO="centoslatest"     TOX_ANSIBLE="{29,28}"
    - TOX_DISTRO="centos8"          TOX_ANSIBLE="{29,28}"
    - TOX_DISTRO="centos7"          TOX_ANSIBLE="{29,28}"
    ...  
script:
  - tox -e $(echo py${TRAVIS_PYTHON_VERSION} | tr -d .)-ansible${TOX_ANSIBLE}-${TOX_DISTRO}
   # remove logs/pycache before caching .tox folder  
  - |
    rm -r .tox/py*/log/*                                                               
    find . -type f -name '*.py[co]' -delete -o -type d -name __pycache__ -delete

Сначала мы указали language: python для запуска сборок с несколькими версиями Python, как определенов списке python:.

Нам нужен докер, поэтому мы добавим его через services: docker.

Тест займет довольно много времени, давайте кешируем pip и наш virtenv, созданный с помощью tox с

cache:
  pip: true
  directories:
  - .tox

Нам нужен токс ...

install:
  - pip install tox-travis

И, наконец, мы определим все наши тесты

env:
  jobs:
    # ansible:latest - check for breaking changes
    ...
    - TOX_DISTRO="centoslatest"     TOX_ANSIBLE="latest"
    ...

Обратите внимание, что у меня есть отдельные задания для последних и разных версий. Это специально. Я хотел бы легко увидеть, что сломалось. Совместимость версий или предстоящие изменения в последней версии ansible.

Файлы, использованные на этом шаге

Источник


Бонус: параллельно запускать tox

Вы можете запустить тесты параллельно (например, 3 теста одновременно), выполнив

tox -p 3

Однако это не даст выходной сигнал от молекулы. Вы можете включить это с помощью

tox -p 3 -o true

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

Источник

1 голос
/ 06 ноября 2019

Здесь нет реального ответа, но есть некоторые идеи:

Ansible Silo , возможно, подойдет, но без коммита в течение года.

И это не совсем то, что вы 'ищите, но Ansible Runner предназначен для использования в сценарии использования «run ansible». И это часть Ansible Tower / AWS, поэтому она должна сохраняться.

Runner предназначен для наиболее полезной части автоматизации и инструментов, которые должны вызывать Ansible и использовать его результаты.

Они упоминают выполнение из контейнера здесь

Дизайн Ansible Runner делает его особенно подходящим для управления выполнением Ansible изнутриконтейнер для рабочих процессов одноцелевой автоматизации

Но проблема для вас заключается в том, что официальный контейнер ansible / ansible-runner помечен после версии ansible-runner, а сам ansible установлен через pip install ansible в контейнеревремя сборки.

...