Opunit : validez facilement les prérequis d'applications Cloud Native

Contexte et Problématique

La migration d’applications traditionnelles vers des applications dites cloud native rime le plus souvent avec l’adoption d’architectures microservices, de consommation de services managés, d’orchestration de conteneurs… Cela se traduit d’un point de vue opérationnel par l'explosion du nombre d'éléments interdépendants à installer et configurer. Cela augmente donc le nombre de prérequis à vérifier avant de pouvoir déployer une application.

Pour ce faire, il est possible d’utiliser des moteurs de vérification matures tels qu’ InSpec, Serverspec, Bats, Testinfra… Ceux-ci couvrent en effet un spectre suffisamment large de fonctions permettant de couvrir la majorité des besoins. Et comme bien des outils matures, le coût en termes de temps de leur prise en main peut finir par être un de leur point faible pour un besoin simple. Tel sera par exemple le cas si l’on veut les utiliser pour valider les prérequis (sanity check) sur le poste local d’un projet cloud native qui constitue pourtant une vérification plutôt simple.

C’est là qu’intervient Opunit qui est un moteur de vérification de conformité beaucoup plus simple à prendre en main que ceux sus-cités.

Opunit : YAML & 4 propriétés essentielles

En effet la prise en main des moteurs Inspec et Serverspec nécessite l’apprentissage du DSL Rspec, Testinfra du python et Bats du bash … alors qu’Opunit repose sur le format de représentation des données YAML.

De plus alors qu’avec les autres outils, c’est à vous de construire avec les briques existantes des tests de vérification haut niveau, Opunit fournit directement des briques haut niveau regroupées autour de 4 propriétés :

• Availability : Le démarrage d’un service nécessite souvent à l’initialisation qu’un certain nombre d’autres éléments soient présents. Cela peut être un format de fichier de configuration, une API externe ou un service local.
• Reachability : Elle permet de déterminer la raison de l’indisponibilité précédente. Par exemple, s’il s’agit d’un fichier indisponible, on pourra tester qu’il ne l’est pas du fait de mauvais droits ; s’il s’agit d’une API externe, on pourra tester le dns par exemple.
• Identification : Elle permet de vérifier la version des composants requis mais aussi la présence et la valeur d’une variable dans un fichier de configuration.
• Capacity : Elle permet de s'assurer que le système a suffisamment de ressources (nombre de cœurs, mémoire, espace disque, réseau) pour faire fonctionner l’outil.

Ainsi la vérification de version minimale du binaire node sur le poste local se fera en utilisant semver de la façon suivante:

- version:
    cmd: node --version
    range: ^10.x.x

alors qu’en exploitant Inspec, ce serait plus long et nous devrions écrire une regexp pour avoir la version minimale de node:

describe command('node --version | 
  <récupérer la="" ligne="" et="" mot="" correspondant="">
   ’') do its('stdout') { should eq (
   
    ) } end 
   
  </récupérer>

Utilisation

Pour exécuter la vérification des propriétés Opunit, rien de plus simple :

• Dans votre projet, créez un fichier opunit.yml à l’intérieur du dossier test
• Remplissez le fichier avec le contenu suivant qui permet  de vérifier que vous utilisez une version terraform 0.13.+ et que avez accès aux updates via le site officiel :

- group:
	description: "Terraform basic opunit checks"
	checks:
    
  	- version:
     	cmd: terraform --version
     	range: ^13.x.x

  	- reachable:
    	- registry.terraform.io

• Installez nvm

Toutes les indications en vous rendant sur le lien suivant : https://github.com/nvm-sh/nvm#install--update-script

• Installez Opunit

npm install -g Opunit

• Lancez le moteur de vérification

Opunit verify local

Cela générera sur votre console un rapport de vérification:

Ainsi, il est possible de savoir très aisément quelles assertions ont échoué ou passé le test de vérification.

Limitations

La liste des 4 propriétés que l’on peut vérifier avec Opunit est loin d’être exhaustive, même si ces propriétés sont essentielles. Opunit n’est donc pas adapté à tests de vérification complexe de type “compliance as code” car il ne couvre pas tous les cas d’usage fonctionnel du fait de sa simplicité. De plus, il ne répond pas au besoin du test d’une infrastructure “bas niveau” souvent globale (et donc complexe) mais plutôt celui d’une application spécifique (environnement local ou distant). Les outils pertinents pour ce type de besoin sont InSpec, Serverspec, Bats, Testinfra…

Références

1. https://info.wescale.fr/cloudradar-cloudnative
2. Opunit! Simple unit tests for servers and containers : devops
3. Opunit: Sanity Checks for Computing Environments
4. https://github.com/ottomatica/Opunit

Pour aller plus loin

Outils de vérification de conformité infrastructure “bas niveau” pouvant aussi servir à de la compliance as code: Ansible & KitchenCI : Infrastructure As Code guidée par les Tests Part I