lae.travis-lxc

Konfiguruje i uruchamia N kontenerów LXC do użycia w środowisku Travis CI, co umożliwia łatwiejsze testowanie ról Ansible w różnych dystrybucjach.

Użycie

Chcesz przetestować swoje role Ansible w Travis CI, ale nie chcesz korzystać z Dockera, bo nie imituje pełnego systemu operacyjnego? LXC to to, czego potrzebujesz. Ta rola ma na celu uprościć większość potrzebnej konfiguracji.

Aby rozpocząć, minimalny plik .travis.yml, który dokładnie przetestuje, czy twoja rola jest ważna, idempotentna i funkcjonalna, może wyglądać tak:

---
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:
# Walidacja składni pliku playbooka wdrożeniowego, który powinien zawierać twoją rolę
- ansible-playbook -i inventory deploy.yml --syntax-check
# Uruchomienie playbooka wdrożeniowego
- ansible-playbook -i inventory deploy.yml
# Ponowne uruchomienie playbooka wdrożeniowego, zapisując wyjście do pliku play.log,
# a następnie sprawdzenie, czy nie ma zadań zmienionych/nieudanych. Jeśli są, test się nie powiedzie.
- 'ANSIBLE_STDOUT_CALLBACK=debug ANSIBLE_DISPLAY_SKIPPED_HOSTS=no ANSIBLE_DISPLAY_OK_HOSTS=no
  unbuffer ansible-playbook -vvi inventory deploy.yml &>play.log; printf "Idempotencja: ";
  grep -A1 "PLAY RECAP" play.log | grep -qP "changed=0 .*failed=0 .*"
  && (echo "PASS"; exit 0) || (echo "FAIL"; cat play.log; exit 1)'
# Testy integracyjne i inne
- ANSIBLE_STDOUT_CALLBACK=debug ansible-playbook -i inventory -v test.yml

Zauważysz, że cztery pliki są wymienione. Możesz zdecydować, jak zdefiniować swój proces budowania, ale poniżej przedstawiam to, co zazwyczaj spełnia większość celów:

• tests/install.yml: wykonuje lae.travis-lxc i inne kroki wstępne
• tests/deploy.yml: wykonuje rolę, którą testujesz
• tests/test.yml: wykonuje testy walidacyjne dla twojego wdrożenia
• tests/inventory: zawiera listę nazw hostów kontenerów LXC

install.yml może wyglądać tak:

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

# Dodaj inne zadania konfiguracyjne, które mogą być potrzebne, ale niekoniecznie w twojej roli
- hosts: all
  tasks: []

Pierwsza gra pokaże trzy kontenery z trzech różnych dystrybucji. Druga gra może być użyta do uruchomienia innych ról lub zadań wstępnych, które nie powinny być realizowane przez twoją rolę (na przykład instalacja epel-release lub stworzenie węzła urządzenia dla FUSE, ponieważ LXC nie robi tego za ciebie).

deploy.yml może wyglądać tak:

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

To jest właściwie przykład tego, co wygeneruje ansible-galaxy init w test.yml. Będzie to zawierało wszystko, co potrzebne do prawidłowego wykonania twojej roli. W przypadku bardziej złożonych ról, sensowne jest oddzielenie zmiennych do folderu tests/group_vars i odpowiednia konfiguracja zasobów.

test.yml powinien zawierać twoje testy, jeśli chcesz je uruchomić:

---
- hosts: all
  tasks:
    - name: Upewnij się, że usługa HTTP Strawberry Milk działa
      uri:
        url: "http://{{ inventory_hostname }}:1515"
    - block:
      - name: Wyświetl konfigurację Strawberry Milk
        shell: cat /etc/strawberry_milk.conf
        changed_when: false
      - name: Wyświetl logi systemowe
        shell: "cat /var/log/messages || cat /var/log/syslog || journalctl -xb"
      ignore_errors: yes

To może być przydatne, aby upewnić się, że usługa działa, że klaster jest w zdrowym stanie, że niektóre pliki są tworzonymi... znasz tę zasadę. Blok, który mam tutaj, to obszar, w którym przeprowadzam zadania diagnostyczne, aby pomóc mi w rozwiązywaniu problemów, który obejmuje drukowanie logów i tym podobne. Jest on owinięty w ignore_errors, aby zadania tutaj nie miały wpływu na wykonanie (głównym problemem są błędy związane z drukowaniem logów, gdy testujesz wiele dystrybucji).

A oto na koniec zasoby:

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

Nazwy hostów są generowane z dwóch części, prefiksu i sufiksu. Domyślnie są one generowane z klucza profile w test_profiles w formacie {{ profile }}-{{ suffix }}, gdzie sufiks domyślnie wynosi 01.

Kiedy już masz te pliki napisane, jesteś gotowy, aby przetestować swoją rolę w Travis CI. Jednak prawdopodobnie chcesz uzyskać więcej, więc omówmy inne tematy.

Testowanie wielu wersji Ansible

Prawdopodobnie będziesz chciał przetestować swoją rolę przeciwko wersji rozwojowej, a także wszystkim aktualnie wspieranym wydaniom Ansible. To coś, co chciałbyś skonfigurować w .travis.yml, a różne sposoby to zrobić wyglądają tak:

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

Tutaj dodaliśmy zadanie instalacji, które albo wykorzysta ANSIBLE_GIT_VERSION, jako ważny odnośnik w repozytorium git Ansible, albo ANSIBLE_VERSION, jako ważny ciąg wersji, który można przekazać do pip podczas instalacji.

Wydajność Ansible i profilowanie

Możesz umieścić prawie wszystko w tests/ansible.cfg.

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

To uruchamia callback profile_tasks w twoim playbooku, co pomaga w zidentyfikowaniu, które zadania zajmują najwięcej czasu. Możesz to wykorzystać do zidentyfikowania wszelkich regresji wydajności. Jeśli uruchamiasz swój playbook przeciwko wielu kontenerom, określ forks. internal_poll_interval to dobre ogólne ustawienie, które warto mieć, gdy masz wiele zadań/pętli.

Caching

Obrazy LXC mogą być pamiętane, aby zaoszczędzić czas uruchamiania, zwłaszcza, gdy testujesz przeciwko kilku profilom. Dodaj poniższe do swojego .travis.yml, a ta rola zajmie się resztą.

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

(pip: true nie ma znaczenia dla tej roli, ale jest tutaj włączone, ponieważ możesz chcieć również zapamiętać swoją instalację Ansible.)

Zmienne roli

Aby określić, które dystrybucje testować, użyj test_profiles. Obsługiwane profile obejmują (możesz zgłaszać nowe):

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

Poniższe profile mają definicje, ale niekoniecznie są aktywnie wspierane jako cele przez tę rolę (tzn. testy już nie są przeprowadzane przeciwko tym), ponieważ są oficjalnie zakończone lub są stosunkowo stare. Nie ma gwarancji, że są wciąż funkcjonalne (choć prawdopodobnie są).

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

Możesz zobaczyć vars/main.yml po więcej informacji na temat tych profili.

Kontener testowy, jeśli nie jest określony prefiks, otrzymuje nazwę hosta {{ profile }}-{{ suffix }}, gdzie profile jest dostosowane do użycia w nazwie DNS. Domyślne prefiksy są zdefiniowane w vars/main.yml, więc odwołuj się do niego, jeśli nie jesteś pewien, jaki prefiks ma dany profil. Jeśli test_host_suffixes nie jest określone, wtedy suffix tutaj staje się liczbą całkowitą z zerowym wypełnieniem, zaczynając od 1 (aż do określonej liczby hostów wskazanej przez test_hosts_per_profile).

Na przykład, następujące tworzy debian01, debian02 i debian03:

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

Następujące tworzy ubuntu-app-python2 i ubuntu-app-python3:

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

Możesz również nadpisać używaną konfigurację kontenera, jeśli to konieczne (na przykład w przypadku montowania folderu współdzielonego):

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

Na wszelki wypadek, jeśli potrzebujesz, możesz także zainstalować dodatkowe pakiety w kontenerach testowych:

additional_packages:
  - make

Jeśli zauważono, że caching jest włączony w .travis.yml, możesz selektywnie zapamiętać podzbiór swoich profilów testowych, określając je w lxc_cache_profiles. Muszą to być ważne profile i obecne w test_profiles.

Aby zapisywać do katalogu innego niż $HOME/lxc, zmodyfikuj lxc_cache_directory.

Jeśli potrzebujesz wyłączyć użycie OverlayFS w kontenerach LXC (np. jeśli próbujesz użyć OverlayFS wewnątrz kontenera LXC), ustaw lxc_use_overlayfs na no (lub jakąkolwiek wersję False).

Współpracownicy

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

Stabilność

Ta rola jest obecnie w fazie przed-wydaniem i dlatego nie jest gwarantowana jako stabilna. Jeśli napotkasz problem używając tej roli, otwórz zgłoszenie z krótkim opisującym problem i wszelkimi odpowiednimi logami, aby można było go naprawić i być o krok bliżej do pierwszego stabilnego wydania.

Upewnij się, że przypinasz do konkretnych wersji (przypinanie do wersji mniejszych może być dopuszczalne), gdy korzystasz z tej roli. Brak tego może spowodować, że twoje testy zaczną nie przechodzić z powodu zmian łamiących w drobnej wersji przed premierą 1.0.