Il s'agit de la version texte de la présentation 2018-04-25 au Saint-Petersburg Linux User Group . L'exemple de configuration localise à https://github.com/ultral/ansible-role-testing

Je suppose que vous faites de la gestion de configuration, pas bash . Cela signifie que vous devez le tester un peu. Avez-vous déjà testé des rôles ansibles? Comment tu fais?

Comment faire

Dans mon cas, nous avons:

• Beaucoup de différents rôles ansibles.
• Les hôtes Hyper-V en tant qu'hyperviseur.
• Un cloud privé avec une possibilité limitée de créer des VM à la demande.
• Un proxy pour l'accès à Internet.
• Test d'incapacité des rôles ansibles à l'intérieur de Docker, en raison d'une configuration role = whole VM
• Décision de mettre en œuvre une politique de construction écologique pour le référentiel git avec des rôles ansibles.

Comparons les solutions existantes pour les tests.

Nous avons décidé de ne pas réinventer la roue et de ne pas préparer de solution de production. Notre équipe d'infrastructure avait de solides compétences en rubis et une grande expérience avec le rubis, nous avons donc choisi Test Kitchen & inspec

Cuisine-ci

L'idée principale est de créer une nouvelle VM, d'appliquer un rôle ansible et de faire des tests de fumée.

Politique de construction écologique

Nous avons également mis en œuvre une politique de construction écologique. Nous avons exécuté des tests pour chaque commit dans la branche master et si les tests sont corrects, lors de l'application des rôles ansibles.

Virtualisation imbriquée

Comme vous vous en souvenez, nous avions un cloud privé avec une possibilité limitée de créer des VM à la demande. Nous avons décidé de créer des VM à l'intérieur des VM.

Tout d'abord, nous avons essayé d'exécuter Virtualbox x32 sans imbriqué. C'était une mauvaise idée à cause de la panique du noyau. De plus, la grande majorité de nos machines virtuelles dans notre infrastructure sont des x86_64, nous avons donc décidé de poursuivre la recherche. En conséquence, nous avons décidé d'utiliser la virtualisation imbriquée. J'espère que cela a été pris en charge par nos serveurs hôtes.

Problèmes rencontrés

J'implémentais testkitchen et je rencontrais des problèmes.

Passer les paramètres de proxy de l'hôte à la machine virtuelle invitée testkitchen

Dans certaines combinaisons de test, nous avons configuré les paramètres du client proxy dans la machine virtuelle créée par testkitchen. Cependant, le proxy n'a pas été configuré sur l'hôte de testkitchen et ansible ne peut pas utiliser de variables supplémentaires avec des valeurs vides

Solution: créez un modèle erb pour définir le proxy par défaut si les variables ENV ne sont pas définies

<%= ENV['http_proxy'].to_s.empty? ? 'http://proxy.example.com:3128' : ENV['http_proxy'] %> 

Gérer les paramètres réseau via playbook

Certains rôles configurent les interfaces réseau. La combinaison d'essai ressemblait à:

• Déployer les paramètres réseau sur les machines virtuelles
• Recharger le réseau
• C'est raté

Solution: ajouter des interfaces aux machines virtuelles

Échec si les valises contiennent "-" dans le nom

Virtualbox ne peut pas utiliser "_" dans un nom de VM

Solution: renommer les valises "vm_" => "vm-"

Le test Oracle échoue sans "." à la fin du nom de la machine virtuelle

Nous utilisons le rôle dans la production, mais lorsque nous avons décidé de le tester, il a échoué. Nous l'avons reproduit.

Je voudrais montrer un indice.

 [root@vm-oracle vagrant]# getent ahosts vm-oracle 127.0.0.1 STREAM vm-oracle 127.0.0.1 DGRAM 127.0.0.1 RAW [root@vm-oracle vagrant]# getent ahosts vm-oracle. fe80::a00:27ff:febd:bd6a STREAM vm-oracle fe80::a00:27ff:febd:bd6a DGRAM fe80::a00:27ff:febd:bd6a RAW 10.0.2.15 STREAM 10.0.2.15 DGRAM 10.0.2.15 RAW [root@oracle vagrant]# getent ahosts oracle.example.com. 192.168.128.182 STREAM oracle.example.local 192.168.128.182 DGRAM 192.168.128.182 RAW 

Avez-vous une idée de ce qui se passe?

C'est un bug délicat:

1. nous avons activé l'écoute IPv4 uniquement dans les paramètres du programme d'écoute Oracle
2. oracle utilisé FQDN
3. linux contient une base de données spéciale "myhostname" pour résoudre le nom d'hôte, il est utilisé après la résolution de / etc / hosts & dns
4. Vagrant créé VM et mis à jour /etc/hosts

J'aimerais clarifier un peu plus:
Que s'est-il passé en cas de vm-oracle ?

1. vagrant créé vm
2. vagrant mis à jour /etc/hosts ( vm-oracle x2)
3. écouteur Oracle a écouté IPv4
4. les auditeurs d'oracle ont résolu vm-oracle. et obtenu IPv6
5. ÉCHEC

Que s'est-il passé en cas vm-oracle. ?

1. vagrant créé vm
2. vagrant mis à jour / etc / hosts ( vm-oracle & vm-oracle. )
3. écouteur Oracle a écouté IPv4
4. les auditeurs d'oracle ont résolu vm-oracle. et obtenu IPv4
5. Ok

OOM arrive

Le MOO tuait au hasard des VM. Testkitchen a échoué avec des erreurs étranges.

Solution: augmenter la RAM

Constructions lentes

Ça fonctionnait lentement

Solutions:

• Packer . Boîte vagabonde pré-construite avec des tâches courantes
• Accès simultané

Conclusion

D'une part, la mise en œuvre actuelle fonctionne, mais d'autre part, il y a quelques problèmes

• n'est pas convivial.
• nous mélangeons rubis et python.
• il n'y a pas de contrôle d'indépendance.
• ça marche lentement.
• il est difficile de tracer les journaux à un seul travail.

En conséquence, la molécule et le docker pourraient être une solution assez intéressante.

Quelques liens connexes

• C'est un poteau croisé. Original
• Version russe
• présentation
• exemple simple
• http://kitchen.ci/
• https://github.com/chef/kitchen-inspec
• https://docs.chef.io/config_yml_kitchen.html
• https://docs.chef.io/ctl_kitchen.html
• https://github.com/neillturner/kitchen-ansible/blob/master/provisioner_options.md