Ceci est la version texte de la performance 2018-04-25 au Saint-Petersburg Linux User Group . Exemple de code ici: https://github.com/ultral/ansible-role-testing

Je crois que vous utilisez la gestion de configuration, pas bash . C'est-à-dire votre configuration est du code. Si nous disons que l'infrastructure est du code, alors la même philosophie devrait être appliquée à sa création comme pour le développement de logiciels. Avez-vous pensé à ça? Comment tu fais? Et d'autres?

Prérequis

Dans le cas décrit, il y en a eu beaucoup d'introduction:

• Nombreux rôles ansibles.
• Hyper-V comme hyperviseur principal.
• Cloud privé avec des capacités limitées pour créer des machines virtuelles à la volée.
• Proxy pour l'accès à Internet.
• L'incapacité à exécuter des tests de rôles ansibles dans Docker, car le rôle est la configuration de la machine virtuelle entière, y compris les paramètres réseau par exemple.
• Désir d'utiliser la politique de l'assistant vert pour un référentiel avec des rôles ansibles.

Avant de faire ce que nous faisons, nous comparons les solutions existantes.

Nous avons décidé de ne pas réinventer la roue et de prendre une solution clé en main. Notre équipe d'infrastructure connaît le rubis, donc Test Kitchen & inspec a été choisi

Cuisine-ci

L'idée est très simple. Nous créons une nouvelle machine virtuelle, utilisons le rôle, exécutons le test de fumée.

Politique de construction écologique

Mais nous avons décidé de continuer. Utilisez ala github flow, c'est-à-dire rôles dans des brunchs individuels et après l'examen merjim dans le maître Si les tests sont corrects, nous déployons les rôles sur l'infrastructure.

Virtualisation imbriquée

Comme vous vous en souvenez, nous avions des restrictions sur la création de machines virtuelles, nous avons donc dû prendre une décision désagréable sous forme de virtualisation imbriquée.

Initialement, nous avons essayé Virtualbox x32 pour ne pas inclure de support imbriqué. Cela s'est avéré être peu d'idées en raison de la stabilité de la panique du noyau. Le deuxième facteur important est que nous sommes assis sur x86_64, donc la recherche s'est poursuivie (hi libvirt), mais s'est installée sur virtualbox comme plus courante sur les systèmes d'exploitation pris en charge.

Des difficultés

Lors du lancement, tout s'est bien passé, il y a eu un certain nombre de difficultés.

Ignorer les paramètres de proxy de l'hôte à l'invité invité

Dans certains scénarios de test, des paramètres de proxy ont été utilisés, tandis que sur l'hôte avec testkitchen, un proxy transparent a été utilisé et le bonus ansible n'a pas accepté de variables supplémentaires avec des valeurs vides.

Solution: ringard - créez un modèle ERB.

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

Gestion des paramètres réseau via ansible

Dans certains rôles, le réseau a été configuré, lors des tests, il ressemblait à ceci:

• Nous configurons le réseau en copiant le fichier.
• Appliquer les paramètres réseau.
• Tout va mal.

Solution: ajouter une interface à la machine virtuelle

Si l'ensemble de test contient "_" tout tombe

Virtualbox ne peut pas utiliser "_" dans le nom de la machine virtuelle. Et la machine virtuelle a utilisé le nom du script.

Solution: renommer les ensembles de tests "vm_" => "vm-"

Cas de test avec l'installation d'Oracle sans "." à la fin de la chute du nom de la machine virtuelle

Le rôle a été utilisé dans une vente conditionnelle lorsqu'ils ont décidé de le couvrir de tests. Lorsque vous le roulez dans une machine virtuelle préparée, il remplit le rôle, il passe par testkitchen.

Petit 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 

Une idée de ce qui se passe?

C'était un scénario amusant:

1. Nous avons activé la liaison IPv4 uniquement dans les paramètres du programme d'écoute Oracle.
2. oracle utilise le nom de domaine complet.
3. linux contient une base spéciale "myhostname" pour résoudre les noms de domaine, elle a été utilisée après les serveurs / etc / hosts & dns.
4. Vagrant crée une VM et met à jour /etc/hosts .

Je vais vous expliquer un peu:
Que se passe-t-il en cas de vm-oracle ?

1. vagrant crée une machine virtuelle.
2. mises à jour vagrant /etc/hosts ( vm-oracle x2)
3. L'écouteur Oracle écoute IPv4.
4. les écouteurs oracle résolvent le nom de domaine vm-oracle. & obtient IPv6.
5. ÉCHEC

Que se passe-t-il dans le cas de vm-oracle. ?

1. vagrant crée une machine virtuelle.
2. vagrant met à jour / etc / hosts ( vm-oracle & vm-oracle. ).
3. L'écouteur Oracle écoute IPv4.
4. les écouteurs oracle résolvent le nom de domaine vm-oracle. et obtient IPv4
5. Ok

OOM vient nous rendre visite

OOM a tué des machines virtuelles au hasard. Testkitchen a en même temps donné toutes sortes de messages étranges dans ses journaux.

Solution: augmentez la quantité de mémoire.

Constructions lentes

Tout ce schéma a fonctionné lentement, pendant des dizaines de minutes, parfois plus d'une heure.

Solutions:

• Packer . Pré-assembler des images de machine virtuelle.
• Exécutez plusieurs cas de test en parallèle

Conclusion

Si nous disons que l'infrastructure est du code, alors la même philosophie devrait être appliquée à sa création comme pour le développement de logiciels. D'une part, nous avons obtenu une solution de travail, mais il y a des moments désagréables:

• Pas sympa, tout a l'air.
• Un mélange de rubis et de python.
• Il n'y a pas de contrôles et de rôles.
• Ça marche lentement.
• Difficile ....

À la sortie, la molécule avec docker semble intéressante et plus native. Nous y réfléchissons.

Les références

• Version anglaise
• Diapositives de performance
• Exemple de code
• 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