lae.travis-lxc

Configure et démarre N conteneurs LXC à utiliser dans l'environnement Travis CI pour un test simplifié des rôles Ansible à travers différentes distributions.

Utilisation

Vous voulez tester vos rôles Ansible sur Travis CI, mais vous ne voulez pas utiliser Docker car cela ne simule pas un système d'exploitation complet ? LXC est ce que vous voulez utiliser. Ce rôle abstrait en théorie une grande partie du code répétitif que vous pourriez utiliser autrement.

Pour commencer, un fichier minimal .travis.yml qui teste complètement que votre rôle est valide, idempotent, et fonctionnel pourrait ressembler à ceci :

---
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:
# Valide la syntaxe de votre playbook de déploiement, qui doit contenir votre rôle
- ansible-playbook -i inventory deploy.yml --syntax-check
# Exécute le playbook de déploiement
- ansible-playbook -i inventory deploy.yml
# Exécute à nouveau le playbook de déploiement, en enregistrant la sortie dans un fichier appelé play.log,
# puis vérifie qu'il n'y a pas de tâches changées/échouées et échoue si c'est le cas.
- 'ANSIBLE_STDOUT_CALLBACK=debug ANSIBLE_DISPLAY_SKIPPED_HOSTS=no ANSIBLE_DISPLAY_OK_HOSTS=no
  unbuffer ansible-playbook -vvi inventory deploy.yml &>play.log; printf "Idempotence: ";
  grep -A1 "PLAY RECAP" play.log | grep -qP "changed=0 .*failed=0 .*"
  && (echo "PASS"; exit 0) || (echo "FAIL"; cat play.log; exit 1)'
# Tests d'intégration et autres
- ANSIBLE_STDOUT_CALLBACK=debug ansible-playbook -i inventory -v test.yml

Vous noterez que quatre fichiers sont référencés. Vous pouvez décider comment définir votre processus de construction, mais les éléments suivants servent généralement la plupart des cas :

• tests/install.yml : exécute lae.travis-lxc et d'autres étapes préinstallations
• tests/deploy.yml : exécute le rôle que vous testez
• tests/test.yml : exécute des tests de validation sur votre déploiement
• tests/inventory : contient une liste des noms d'hôtes des conteneurs LXC

Votre fichier install.yml peut ressembler à ceci :

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

# Ajoutez d'autres tâches de configuration dont vous pourriez avoir besoin mais qui ne sont pas nécessaires dans votre rôle
- hosts: all
  tasks: []

Le premier play démarre trois conteneurs de trois distributions différentes. Le deuxième play pourrait être utilisé pour exécuter d'autres rôles ou des tâches pré-installation que votre rôle ne devrait pas exécuter (par exemple, installer epel-release ou créer un nœud de périphérique pour FUSE (car LXC ne le fait pas pour vous)).

Votre deploy.yml peut ressembler à ceci :

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

C'est fondamentalement ce que ansible-galaxy init produirait dans test.yml. Cela aurait tout ce dont vous avez besoin pour exécuter votre rôle correctement. Pour des rôles plus complexes, il est judicieux de séparer les variables dans le dossier tests/group_vars et de configurer votre inventaire en conséquence.

Votre test.yml devrait contenir vos tests, si vous souhaitez exécuter des tests :

---
- hosts: all
  tasks:
    - name: Assurer que le service HTTP de Strawberry Milk fonctionne
      uri:
        url: "http://{{ inventory_hostname }}:1515"
    - block:
      - name: Afficher la configuration de Strawberry Milk
        shell: cat /etc/strawberry_milk.conf
        changed_when: false
      - name: Afficher les journaux système
        shell: "cat /var/log/messages || cat /var/log/syslog || journalctl -xb"
      ignore_errors: yes

Cela peut être utile pour s'assurer qu'un service fonctionne, qu'un cluster est sain, que certains fichiers sont créés... vous voyez l'idée. Le block ici est une zone où j'exécute des tâches de type diagnostic pour m'aider à déboguer des problèmes, y compris l'impression des journaux et autres. Il est enveloppé avec ignore_errors pour que les tâches ici n'affectent pas le build (une tâche qui pourrait échouer est l'impression des journaux lors du test de plusieurs distributions).

Enfin, l'inventaire :

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

Les noms d'hôtes sont générés à partir de deux parties, un préfixe et un suffixe. Par défaut, ceux-ci sont générés à partir de la clé profile dans test_profiles au format {{ profile }}-{{ suffix }}, où le suffixe par défaut est 01.

Une fois ces fichiers écrits, vous êtes prêts à tester votre rôle dans Travis CI. Cependant, vous voudrez probablement plus, donc passons en revue d'autres sujets.

Tester plusieurs versions d'Ansible

Il est probable que vous souhaitiez tester votre rôle contre la branche de développement ainsi que toutes les versions d'Ansible actuellement supportées. C'est quelque chose que vous voudrez configurer dans .travis.yml, et il existe diverses manières de le faire :

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

Ici, nous avons ajouté une tâche d'installation qui prendra soit ANSIBLE_GIT_VERSION, comme référence valide dans le dépôt Git d’Ansible, soit ANSIBLE_VERSION, une chaîne de version valide pouvant être passée à pip lors de l'installation.

Performance et profilage d'Ansible

Vous pouvez ajouter presque tout dans tests/ansible.cfg.

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

Cela exécute le rappel profile_tasks sur votre playbook, ce qui aide à identifier quelles tâches prennent le plus de temps à s'exécuter. Vous pourriez utiliser cela pour identifier d'éventuels problèmes de performances, par exemple. Si vous exécutez votre playbook contre plusieurs conteneurs, spécifiez forks. internal_poll_interval est un bon réglage général à avoir lorsque vous avez plusieurs tâches/boucles.

Cache

Les images LXC peuvent être mises en cache pour économiser du temps de démarrage, notamment lorsque vous testez plusieurs profils. Ajoutez ce qui suit dans votre .travis.yml, et ce rôle s'occupera du reste.

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

(pip: true n'a pas d'incidence pour ce rôle, mais cela est inclus ici car vous voudriez peut-être également mettre en cache votre installation d'Ansible.)

Variables du rôle

Pour spécifier quelles distributions tester, utilisez test_profiles. Les profils supportés incluent (n'hésitez pas à demander ou contribuer de nouveaux) :

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

Les profils suivants ont des définitions, mais ne sont pas nécessairement activement supportés en tant que cibles par ce rôle (c'est-à-dire que les tests ne sont plus effectués contre ces profils), soit parce qu'ils sont officiellement obsolètes en amont ou sont relativement anciens. Aucune garantie n'est donnée qu'ils fonctionnent toujours (mais ils le font probablement).

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

Vous pouvez consulter vars/main.yml pour plus d'informations sur ces profils.

Un conteneur de test, si aucun préfixe n'est spécifié, reçoit un nom d'hôte de {{ profile }}-{{ suffix }}, où profile est nettoyé pour une utilisation dans un nom DNS. Des préfixes par défaut sont définis dans vars/main.yml, donc référez-vous à cela si vous n'êtes pas sûr de ce qu'est le préfixe d'un profil particulier. Si test_host_suffixes n'est pas défini, suffix devient ici un entier à deux chiffres zéro remplis commençant à 1 (jusqu'au nombre demandé de hôtes spécifié par test_hosts_per_profile).

Par exemple, ce qui suit crée debian01, debian02, et debian03 :

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

Ce qui suit crée ubuntu-app-python2 et ubuntu-app-python3 :

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

Vous pouvez également remplacer la configuration du conteneur utilisée, si nécessaire (pour par exemple monter un dossier partagé) :

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

Si, par hasard, vous avez besoin de le faire (les paquets "manquants" devraient être installés par défaut dans ce rôle, alors ouvrez un problème), vous pouvez également installer des paquets supplémentaires à l'intérieur des conteneurs de test :

additional_packages:
  - make

Si le cache est identifié comme étant activé dans .travis.yml, vous pouvez mettre en cache sélectivement un sous-ensemble de vos profils de test en les spécifiant dans lxc_cache_profiles. Ceux-ci doivent être des profils valides et présents dans test_profiles.

Pour mettre en cache dans un répertoire différent de $HOME/lxc, modifiez lxc_cache_directory.

Si vous devez désactiver l'utilisation de OverlayFS dans les conteneurs LXC (par exemple si vous essayez d'utiliser OverlayFS à l'intérieur du conteneur LXC), définissez lxc_use_overlayfs à no (ou n'importe quelle variante False).

Contributeurs

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

Stabilité

Ce rôle est actuellement encore pré-1.0 et donc n'est pas garanti d'être stable. Si vous rencontrez un problème en utilisant ce rôle, veuillez ouvrir un problème avec une brève description et tous les journaux appropriés afin qu'il puisse être corrigé et que nous puissions être un pas plus près de notre première version stable.

Veuillez vous assurer que vous épinglez à une version spécifique (épingler à une version mineure peut être acceptable) lorsque vous utilisez ce rôle. Le fait de ne pas le faire peut entraîner l'échec de vos tests en raison de modifications problématiques dans une version mineure avant une version 1.0.