lae.travis-lxc

Konfiguriert und startet N LXC-Container für die Verwendung in der Travis CI-Umgebung, um einfachere Tests von Ansible-Rollen über verschiedene Distributionen hinweg durchzuführen.

Nutzung

Möchten Sie Ihre Ansible-Rollen in Travis CI testen, aber Docker nicht verwenden, weil es ein vollständiges OS nicht nachahmt? LXC ist das, was Sie verwenden möchten. Diese Rolle abstrahiert hoffentlich viel vom Boilerplate-Code, den Sie sonst benötigen würden.

Um zu beginnen, könnte eine minimale .travis.yml, die gründlich testet, ob Ihre Rolle gültig, idempotent und funktional ist, folgendermaßen aussehen:

---
language: python
sudo: erforderlich
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:
# Überprüft die Syntax Ihres Deployment-Playbooks, das Ihre Rolle enthalten sollte
- ansible-playbook -i inventory deploy.yml --syntax-check
# Führt das Deployment-Playbook aus
- ansible-playbook -i inventory deploy.yml
# Führt das Deployment-Playbook erneut aus, speichert die Ausgabe in einer Datei namens play.log,
# und überprüft dann, ob es keine geänderten/fehlgeschlagenen Aufgaben gibt und schlägt fehl, wenn es welche gibt.
- 'ANSIBLE_STDOUT_CALLBACK=debug ANSIBLE_DISPLAY_SKIPPED_HOSTS=no ANSIBLE_DISPLAY_OK_HOSTS=no
  unbuffer ansible-playbook -vvi inventory deploy.yml &>play.log; printf "Idempotenz: ";
  grep -A1 "PLAY RECAP" play.log | grep -qP "changed=0 .*failed=0 .*"
  && (echo "PASS"; exit 0) || (echo "FAIL"; cat play.log; exit 1)'
# Integrationstests und ähnliches
- ANSIBLE_STDOUT_CALLBACK=debug ansible-playbook -i inventory -v test.yml

Sie werden feststellen, dass vier Dateien referenziert werden. Sie können entscheiden, wie Sie Ihren Build-Prozess definieren, aber Folgendes dient typischerweise den meisten Zwecken:

• tests/install.yml: führt lae.travis-lxc und andere Vorinstallationsschritte aus
• tests/deploy.yml: führt die Rolle aus, die Sie testen
• tests/test.yml: führt Validierungstests gegen Ihr Deployment aus
• tests/inventory: enthält eine Liste von LXC-Container-Hostnamen

install.yml könnte folgendermaßen aussehen:

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

# Fügen Sie alle anderen Einrichtungsaufgaben hinzu, die Sie möglicherweise benötigen, die aber nicht unbedingt in Ihrer Rolle erforderlich sind
- hosts: all
  tasks: []

Das erste Spiel bringt drei Container von drei verschiedenen Distributionen hoch. Das zweite Spiel könnte verwendet werden, um entweder andere Rollen oder Vorinstallationsaufgaben auszuführen, die Sie erwarten, dass Ihre Rolle nicht durchführt (zum Beispiel epel-release installieren oder einen Gerätknoten für FUSE erstellen (weil LXC das nicht für Sie tut)).

deploy.yml könnte folgendermaßen aussehen:

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

Dies ist im Grunde eine Wiedergabe dessen, was ansible-galaxy init in test.yml ausgeben würde. Dies hätte alles, was Sie benötigen, um Ihre Rolle richtig auszuführen. Für komplexere Rollen macht es Sinn, Variablen in den Ordner tests/group_vars auszulagern und Ihr Inventar entsprechend zu konfigurieren.

test.yml sollte Ihre Tests enthalten, wenn Sie welche durchführen möchten:

---
- hosts: all
  tasks:
    - name: Sicherstellen, dass der Strawberry Milk HTTP-Dienst läuft
      uri:
        url: "http://{{ inventory_hostname }}:1515"
    - block:
      - name: Strawberry Milk-Konfiguration ausgeben
        shell: cat /etc/strawberry_milk.conf
        changed_when: false
      - name: Systemprotokolle ausgeben
        shell: "cat /var/log/messages || cat /var/log/syslog || journalctl -xb"
      ignore_errors: yes

Dies kann nützlich sein, um sicherzustellen, dass ein Dienst läuft, dass ein Cluster in einem gesunden Zustand ist und dass bestimmte Dateien erstellt werden... Sie verstehen das Prinzip. Der block, den ich hier habe, ist ein Bereich, in dem ich diagnostische Aufgaben ausführe, um Probleme zu debuggen, einschließlich des Ausgebens von Protokollen und Ähnlichem. Es ist mit ignore_errors umschlossen, damit diese Aufgaben den Build nicht beeinflussen (eine häufige Fehlerquelle ist die Protokollierungsaufgabe beim Testen mehrerer Distributionen).

Und schließlich, das Inventar:

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

Die Hostnamen werden aus zwei Teilen generiert, einem Präfix und einem Nachsatz. Standardmäßig werden sie aus dem Schlüssel profile in test_profiles im Format {{ profile }}-{{ suffix }} generiert, wobei der Nachsatz standardmäßig 01 ist.

Sobald Sie diese Dateien geschrieben haben, sind Sie bereit, Ihre Rolle in Travis CI zu testen. Sie möchten wahrscheinlich mehr daraus machen, daher lassen Sie uns einige andere Themen durchgehen.

Testen mehrerer Ansible-Versionen

Es ist wahrscheinlich, dass Sie Ihre Rolle gegen den Entwicklungszweig sowie alle aktuell unterstützten Ansible-Versionen testen möchten. Dies ist etwas, das Sie in .travis.yml konfigurieren möchten, und es gibt verschiedene Möglichkeiten, dies zu tun:

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

Hier haben wir eine Installationsaufgabe hinzugefügt, die entweder ANSIBLE_GIT_VERSION als gültigen Verweis im Ansible-Git-Repository oder ANSIBLE_VERSION, eine gültige Versionszeichenfolge, die während der Installation an pip übergeben werden kann, übernimmt.

Ansible-Leistung und Profiling

Sie können fast alles in tests/ansible.cfg ablegen.

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

Dies führt den profile_tasks Callback in Ihrem Playbook aus, der hilft zu identifizieren, welche Aufgaben am längsten dauern. Sie könnten dies verwenden, um Leistungsregressionen zu identifizieren. Wenn Sie Ihr Playbook gegen mehrere Container ausführen, geben Sie forks an. internal_poll_interval ist eine gute allgemeine Einstellung, die Sie haben sollten, wenn Sie mehrere Aufgaben/Schleifen haben.

Caching

LXC-Images können zwischengespeichert werden, um die Bootstrap-Zeit zu verkürzen, insbesondere wenn Sie gegen mehrere Profile testen. Fügen Sie Folgendes in Ihre .travis.yml ein, und diese Rolle kümmert sich um den Rest.

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

(pip: true hat für diese Rolle keine Bedeutung, ist aber hier enthalten, da Sie möglicherweise auch Ihre Ansible-Installation zwischenspeichern möchten.)

Rollenvariablen

Um festzulegen, gegen welche Distributionen getestet werden soll, verwenden Sie test_profiles. Unterstützte Profile sind (fühlen Sie sich frei, neue anzufordern/beizutragen):

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

Die folgenden Profile sind definiert, werden aber nicht unbedingt aktiv als Ziele von dieser Rolle unterstützt (d.h. Tests werden nicht mehr gegen diese durchgeführt), sei es, weil sie offiziell EOL upstream sind oder relativ alt sind. Es werden keine Garantien gegeben, dass sie noch funktionsfähig sind (aber sie sind wahrscheinlich noch funktionsfähig).

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

Sie können vars/main.yml für weitere Informationen zu diesen Profilen einsehen.

Ein Testcontainer, wenn kein Präfix angegeben ist, erhält einen Hostnamen von {{ profile }}-{{ suffix }}, wobei profile für die Verwendung in einem DNS-Namen aufbereitet wird. Standardpräfixe sind in vars/main.yml definiert, also schauen Sie nach, wenn Sie sich nicht sicher sind, was das Präfix eines bestimmten Profils ist. Wenn test_host_suffixes nicht definiert ist, wird suffix hier zu einer null-paddierten zweiziffrigen Ganzzahl, die bei 1 beginnt (bis zur angeforderten Anzahl von Hosts, die durch test_hosts_per_profile angegeben wird).

Beispielsweise erstellt Folgendes debian01, debian02 und debian03:

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

Folgendes erstellt ubuntu-app-python2 und ubuntu-app-python3:

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

Sie können auch die verwendete Containerkonfiguration nach Bedarf überschreiben (z. B. zum Mounten eines freigegebenen Ordners):

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

Falls notwendig (Fehlende Pakete sollten standardmäßig innerhalb dieser Rolle installiert werden, also eröffnen Sie ein Ticket), können Sie auch zusätzliche Pakete innerhalb der Testcontainer installieren:

additional_packages:
  - make

Wenn Caching in .travis.yml aktiviert ist, können Sie eine Teilmenge Ihrer Testprofile auswählen, die zwischengespeichert werden soll, indem Sie sie in lxc_cache_profiles angeben. Diese müssen gültige Profile sein und in test_profiles vorhanden sein.

Um in ein anderes Verzeichnis als $HOME/lxc zu cachen, ändern Sie lxc_cache_directory.

Wenn Sie die Verwendung von OverlayFS in den LXC-Containern deaktivieren müssen (z. B. wenn Sie versuchen, OverlayFS innerhalb des LXC-Containers zu verwenden), setzen Sie lxc_use_overlayfs auf no (oder jede False-Variante).

Mitwirkende

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

Stabilität

Diese Rolle befindet sich derzeit noch in der Version vor 1.0 und ist daher nicht garantiert stabil. Wenn Sie beim Verwenden dieser Rolle auf ein Problem stoßen, eröffnen Sie bitte ein Ticket mit einer kurzen Beschreibung und den entsprechenden Protokollen, damit es behoben werden kann und wir einen Schritt näher an unserer ersten stabilen Version sind.

Bitte stellen Sie sicher, dass Sie eine spezifische Version angeben (das Festlegen auf minor könnte in Ordnung sein), wenn Sie diese Rolle verwenden. Andernfalls können Ihre Tests beginnen zu fehlschlagen, aufgrund von breaking Changes in einer Minor-Version vor einer 1.0-Version.