Esta es la versión de texto del rendimiento 25/04/2018 en el Grupo de usuarios de Linux de San Petersburgo . Código de muestra aquí: https://github.com/ultral/ansible-role-testing

Creo que está utilizando la gestión de configuración, no bash . Es decir Su configuración es el código. Si decimos que la infraestructura es código, entonces se debe aplicar la misma filosofía a su creación que para el desarrollo de software. ¿Has pensado en esto? Como lo haces Y otros?

Prerrequisitos

En el caso descrito, hubo muchos introductorios:

• Muchos roles ansibles.
• Hyper-V como el hipervisor principal.
• Nube privada con capacidades limitadas para crear máquinas virtuales sobre la marcha.
• Proxy para el acceso a Internet.
• La imposibilidad de ejecutar pruebas de roles ansibles en Docker, porque el rol es la configuración de toda la VM, incluida la configuración de red, por ejemplo.
• Deseo de utilizar la política de asistente verde para un repositorio con roles ansibles.

Antes de hacer lo que hacemos, comparamos las soluciones existentes.

Decidimos no reinventar la rueda y tomar una solución llave en mano. Nuestro equipo de infraestructura conoce Ruby, por lo que se eligió Test Kitchen & Inspec

Cocina-ci

La idea es fea y simple. Creamos una nueva máquina virtual, utilizamos el rol, ejecutamos la prueba de humo.

Política de construcción verde

Pero decidimos seguir adelante. Use el flujo ala github, es decir roles en almuerzos individuales y después de la revisión de merjim en el maestro. Si las pruebas están bien, entonces trasladamos los roles a la infraestructura.

Virtualización anidada

Como recordará, teníamos restricciones en la creación de máquinas virtuales, por lo que tuvimos que tomar una decisión desagradable en forma de virtualización anidada.

Inicialmente, probamos Virtualbox x32 para no incluir soporte anidado. Esto resultó no ser muy ideas debido a la estabilidad del kernel panic. El segundo factor importante es que estamos sentados en x86_64, por lo que la investigación continuó (hola libvirt), pero se estableció en virtualbox como más común en el sistema operativo compatible.

Dificultades

Durante el lanzamiento, todo estuvo bien, hubo varias dificultades.

Omitir la configuración del proxy del host al invitado

En algunos escenarios de prueba, se utilizó la configuración del proxy, mientras que en el host con testkitchen se utilizó un proxy transparente y el bono ansible no aceptaba variables adicionales con valores vacíos.

Solución: cursi: crea una plantilla ERB.

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

Gestión de la configuración de red a través de ansible

En algunos roles, la red se configuró, en las pruebas se veía así:

• Configuramos la red copiando el archivo.
• Aplicar la configuración de red.
• Todo es malo

Solución: agregue una interfaz a la máquina virtual

Si el conjunto de prueba contiene "_", todo cae

Virtualbox no puede usar "_" en el nombre de la máquina virtual. Y la máquina virtual usó el nombre del script.

Solución: cambie el nombre de los conjuntos de prueba "vm_" => "vm-"

Casos de prueba con la instalación de Oracle sin "." al final de la caída del nombre de la máquina virtual

El papel se utilizó en ventas condicionales cuando decidieron cubrirlo con pruebas. Cuando lo enrollas en una VM preparada, cumple el rol, cae a través de testkitchen.

Pequeña pista

 [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 

¿Alguna idea de lo que está pasando?

Fue un escenario divertido:

1. Activamos el enlace IPv4 solo en la configuración del oyente oracle.
2. Oracle utiliza el FQDN.
3. Linux contiene una base especial "myhostname" para resolver nombres de dominio, se utilizó después de / etc / hosts & dns servidores.
4. Vagrant crea VM y actualizaciones /etc/hosts .

Te explicaré un poco:
¿Qué sucede en caso de vm-oracle ?

1. vagabundo crea una máquina virtual.
2. actualizaciones vagabundas /etc/hosts ( vm-oracle x2)
3. oracle listener escucha IPv4.
4. Los oyentes oracle resuelven el nombre de dominio vm-oracle. & obtiene IPv6.
5. Falló

Lo que sucede en el caso de vm-oracle. ?

1. vagabundo crea una máquina virtual.
2. Actualizaciones vagabundas / etc / hosts ( vm-oracle y vm-oracle ).
3. oracle listener escucha IPv4.
4. Los oyentes oracle resuelven el nombre de dominio vm-oracle. y obtiene IPv4
5. Ok

OOM viene a visitarnos

OOM mató al azar máquinas virtuales. Testkitchen al mismo tiempo dio todo tipo de mensajes extraños en sus registros.

Solución: aumente la cantidad de memoria.

Construcciones lentas

Todo este esquema funcionó lentamente, durante decenas de minutos, a veces más de una hora.

Soluciones:

• Packer Premontar imágenes de máquinas virtuales.
• Ejecute múltiples casos de prueba en paralelo

Conclusión

Si decimos que la infraestructura es código, entonces se debe aplicar la misma filosofía a su creación que para el desarrollo de software. Por un lado, obtuvimos una solución de trabajo, pero hay algunos momentos desagradables:

• No es amigable, todo parece.
• Una mezcla de rubí y pitón.
• No hay controles ni roles.
• Funciona lentamente
• Difícil ...

En la salida, la molécula con acoplador se ve interesante y más nativa. Estamos pensando en eso.

Referencias

• Versión inglesa
• Diapositivas de rendimiento
• Ejemplo de código
• 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