Probar la infraestructura como código Terraform: Analice las pruebas unitarias y el desarrollo de un extremo a otro probando comportamientos

Para los futuros alumnos del curso "Infraestructura como código en Ansible" y todos los interesados, preparamos una traducción de material útil.



También lo invitamos a inscribirse en una lección abierta sobre el tema "Administración de Kubernetes con Kubespray" .

---

¡Dar una buena acogida! Este es otro artículo técnico de una serie de artículos de terraform y kubernetes sobre infraestructura como código de Contino.



TL; DR

El tamaño del comando no importa. De cualquier manera, implementar un buen análisis de configuración de infraestructura de terraform y pruebas de cordura de extremo a extremo no tiene por qué ser un proceso largo y complejo.



Me enfrenté a un desafío emocionante: explorar, desarrollar y presentar un marco de prueba de código abierto adecuado para la base de código terraform como parte de la tubería de lanzamiento de la infraestructura. El principio de "control de calidad en todo" está lejos de ser nuevo. Pero su implementación depende de la madurez de la infraestructura de la organización y del nivel aceptable de riesgo, hasta la etapa de alcanzar un producto terminado [de alguna manera].



Dar una nueva mirada al campo del código de infraestructura de prueba me permitió familiarizarme con los últimos marcos de prueba y actualizar mis conocimientos.







Es cierto que, al comienzo de mi viaje, sufrí el prejuicio de que preparar e implementar tal "control de calidad de clase empresarial" puede requerir mucho trabajo.



Después de todo, Hashicorp Terraform tiene suficiente funcionalidad lista para usar para validar y validar su código base .

• Control de calidad del código - terraform fmt -check
  
  
  
  y terraform validate
  
  
  
  .
• Vista previa - terraform plan
  
  
  
  .
• Construcción: TFLOG=debug terraform apply
  
  
  
  para una verificación meticulosa.

Herramientas de análisis de código estático de Terraform

Una búsqueda en Google ha revelado una lista muy extensa de herramientas de prueba de terraform potencialmente útiles.



Pero primero, repasemos la lista de nuestros requisitos.

• Tener pruebas unitarias en la configuración de recursos de terraform y la capacidad de ampliar cualquier lista genérica de mejores prácticas * comprobaciones para un proveedor de nube específico. Además, estamos interesados ​​en herramientas fáciles de usar con las que pueda comenzar de inmediato.

* Falta de instancias ec2 expuestas al mundo 0.0.0.0/0, y así sucesivamente.

•  — «» , . , , , EKS.

• , , — , , . , , .

• , . , , Go Python. , , , , . , , . , .

Enfoque: análisis y comparación de plataformas y herramientas de prueba de Terraform Es de



esperar que la siguiente lista facilite su trabajo en el análisis de la infraestructura estática como código y el control de calidad. Tenga en cuenta que esta es una lista completa de todas las herramientas de prueba de terraform relevantes que he encontrado, que es una combinación de pruebas de validez de configuración, control de calidad del código y mejores prácticas centradas en secOps con pruebas unitarias. Esta lista se presenta a continuación.

• tflint  - github.com/terraform-linters
• terrafirma  - github.com/wayfair/terrafirma
• tfsec  - github.com/liamg/tfsec
• terrascan — github.com/cesar-rodriguez/terrascan ( TF 0.13)
• checkov — github.com/bridgecrewio/checkov
• conftest — github.com/instrumenta/conftest

Resumamos. Traté de encontrar una prueba unitaria estandarizada para los componentes de recursos de terraform y un conjunto más personalizado de pruebas que toman la configuración de recursos para validar los resultados terraform plan



.



Después de revisar las ventajas y desventajas de cada plataforma, opté por una herramienta checkov



y una plataforma con un nombre muy adecuado terraform-compliance



 , ambas escritas en python. Cumplieron con todos mis requisitos descritos anteriormente.



La canalización de lanzamiento de infraestructura como código se ve así en términos generales.



Habiendo profundizado en estas plataformas, inevitablemente revisé mi propia experiencia y llegué a las siguientes conclusiones relevantes sobre el tema en discusión:

• .
• , , , .
• , , , - « » « ».

 — Checkov BridgeCrew

www.checkov.io

Checkov es una herramienta de análisis de código estático para infraestructura como código.



Escanea la infraestructura en la nube aprovisionada con plantillas Terraform, Cloudformation, Kubernetes, Serverless o ARM e identifica configuraciones incorrectas para la seguridad y el cumplimiento.

Hay varias pruebas unitarias predeterminadas que se ejecutan al escanear el repositorio de código terraform que muestran desviaciones de las mejores prácticas, por ejemplo, cuando, de acuerdo con su configuración de seguridad, tiene una máquina virtual en el puerto 22 expuesta al mundo (0.0.0.0/0).



Todas las pruebas se pueden encontrar en este enlace de GitHub.



Es muy fácil comenzar con la plataforma.

• Instale el binario.
• Inicialice el directorio terraform con terraform init.
• Ejecute chechov en este directorio.

Todas las pruebas unitarias que se ejecutan de forma predeterminada se pueden enumerar en la línea de comandos. Además, cuando se ejecuta checkov, la plataforma devolverá de forma predeterminada todas las pruebas unitarias aprobadas y fallidas. Muy conveniente, fácil de comenzar a usar. Se prueban los métodos avanzados de Terraform, pero no todos. Ésta es una diferencia fundamental.



Chechov evaluará con gusto SOLO su código terraform



. La plataforma puede funcionar inmediatamente después terraform init



. A ella no le importa el tuyo terraform plan



 , con todas las ventajas y desventajas. La plataforma hace lo que se indica, es decir, "análisis de código estático". Sea consciente de las posibles consecuencias, así como de cualquier consideración lógica, para sus recursos.

checkov .

Si está listo para realizar un desarrollo profundo de Python, puede escribir pruebas unitarias adicionales. El lenguaje de desarrollo de la plataforma era uno de mis requisitos, porque a veces tengo que analizar el código base de las pruebas para estimar qué tan difícil sería [si fuera necesario] crear tales métodos adicionales. Este momento, sumado a los problemas de servicio para el grupo en su conjunto, se convirtió en el factor principal para elegir esta plataforma frente a otra alternativa que lograría el mismo resultado.



En resumen, la plataforma checkov es excelente en el área del análisis de código estático. Específicamente si necesito incluir en la lista blanca la subred IP definida inicialmente. Pero esta opción no es adecuada para pruebas e2e que necesitan una plataforma de prueba separada.



Por otro lado, como solución, puedo replicar la prueba unitaria y codificar mi configuración de subred / IP. Y luego, ¿qué pasa si tengo varias instancias y proyectos? Saltar esta prueba, incluso si la necesito? Tal vez. O tal vez no.



Aquí es donde entra en juego la segunda plataforma de pruebas - terraform-compliance



.

Conformidad con Terraform

terraform-compliance.com

Terraform-compliance  es una plataforma de prueba liviana diseñada para auditorías de seguridad y cumplimiento en terraform para garantizar que su infraestructura se pruebe tan negativamente como el código.

Antecedentes

Una vez más, el desarrollo de pruebas de comportamiento de extremo a extremo (BDD) se ha utilizado recientemente como un marco de prueba, lo que destaca la necesidad de un marco de prueba universal. Pero este no es el único beneficio. Sencillez.



De hecho, me parece que BDD no recibe suficiente atención. Es posible que haya oído hablar de Test Driven Development (TDD), que tiene raíces profundas, principalmente en el entorno de desarrollo de software. Pero aquí es donde plataformas como BDD facilitan la creación de lógica adicional, ofreciendo al mantenedor de infraestructura promedio una forma más simple, concisa y repetible de desarrollar pruebas personalizadas de extremo a extremo sin tener que aprender a fondo ningún lenguaje de programación nuevo y especializado.



Y aunque el código puede describir, de hecho, todo en el mundo, en última instancia, todo depende de la capacidad de administración, la capacidad de comprender la complejidad del código (que puede requerir la preparación de una documentación extensa), sin mencionar el soporte y el mantenimiento.  Lea más sobre BDD aquí.



Cucumber.io  no es solo un lenguaje, es un sistema que facilita las pruebas al adoptar un enfoque WYSIWYG para la creación, comprensión y mantenimiento de pruebas. Estos ejemplos se determinan antes del desarrollo y se utilizan como criterios de aceptación.



Son parte de la definición.

Pruebas con Terraform-Compliance

Cada plataforma se revisa por sus méritos, con un estudio en profundidad de dónde se pueden utilizar mejor sus características y matices. De cara al futuro, puedo decir que se pueden utilizar ambas plataformas.



A continuación se muestra un ejemplo de una prueba de este tipo desarrollada utilizando la plataforma terraform-compliance



BDD. Le permite realizar pruebas de un extremo a otro bastante complejas.



La plataforma terraform-compliance



usa la salida terraform plan



... Como resultado, permite que se formen "planes" de lanzamiento completos y se prueben a fondo. Por ejemplo, controle que se use el par de claves de cifrado correcto [para su proveedor de nube] para la cuenta, el entorno, etc. Tiene mucha libertad creativa y, lo más importante, la plataforma es muy fácil de usar.



Solo revisa los pasos y ejemplos a continuación.

• Paso 1. Inicialice el directorio terraform: # terraform init
• Paso 2. Puede generar rápidamente un plan de terraform con el siguiente comando: #terraform plan -out = plan.out
• Paso 3. Escribe algunas pruebas. Es una cuestión sencilla: ya existe una carpeta con ejemplos. Repasemos mis propios ejemplos de prueba a continuación, basados ​​en la salida de mi plan de terraform.

Este es un fragmento del plan de terraform



 configuración de terraform que crea el EKS con el grupo de lanzamiento especificado. Asegurémonos de que nuestro código terraform



no use la infraestructura instancetype



, sino que use el "aprobado" a1.xlarge



o a1.2xlarge



.



Ahora lo cambiaré intencionalmente t2.small



para simular fallas de prueba.



Escribamos una prueba para asegurarnos de que este requisito se valida con éxito.

• Paso 4. Hagamos que los terraform-compliance
  
  
  
  tableros evalúen usando escenarios de prueba:#terraform-compliance -p plan.out -f ./<test-cases-folder>
  
  
  
  

Ejecutando pruebas

Ejemplo de resultado de aprobado y reprobado







Si nuestro código de marco de Terraform está utilizando el correcto instancetype



, todos los resultados serán ÉXITO en verde.



Si nuestro código de infraestructura Terraform viola el requisito porque es incorrecto instancetype



, los resultados serán FALLOS en rojo.



Escribamos aún más pruebas.







Algunas pruebas más simples tomadas del directorio de ejemplos:







Si una falla, el usuario verá "valor_actual" que se recupera y se muestra con fines de ayuda y depuración.

Resultados de la prueba

Después de ejecutar todas las pruebas, se muestra un resumen conveniente de todas las pruebas aprobadas y fallidas, que también incluye las pruebas perdidas. Me gusta porque me permite escribir una larga lista de pruebas rigurosas, así como proporcionar información clara al final de qué pruebas fallaron y cuándo. Además, si falla, algunas pruebas se pueden omitir con una etiqueta @warning



, como se muestra en el siguiente ejemplo.

habrastorage.org/getpro/habr/upload_files/c22/910/cb9/c22910cb95fb4ccc7555d44bd8b5436b

Salir

Sin lugar a dudas, esta fue una gran oportunidad para echar un vistazo a algunos de los marcos superiores de validación y prueba disponibles para el código como marcos Terraform.



Disfruté viendo estas dos plataformas y me sorprendió particularmente la facilidad de integración de checkov, así como las increíbles e2e terraform plan



opciones de validación y prueba personalizadas que ofrece terraform-compliance



.



Este último me recuerda el comportamiento de behave, otro gran marco de prueba de BDD e2e kubernetes con el que he trabajado en el pasado.



Los marcos de prueba escritos completamente en Python facilitan el intercambio de conocimientos de Python entre plataformas y reducen la cantidad de capacidad intelectual necesaria para mantener y desarrollar pruebas en el futuro.



Si necesita comparar su configuración con las mejores prácticas cuando no necesita un plan terraform, checkov podría ser el indicado para usted. De lo contrario, la respuesta podría ser una plataforma terraform-compliance



que tenga un conjunto más rico de funciones de validación terraform plan



. Lo mejor de todo es que ser una plataforma BDD es terraform-compliance



muy fácil de aprender.



Las pruebas unitarias son lo primero. Tan fácil como un pastel. La plataforma Checkov de Bridgecrewio permite verificar el cumplimiento de las mejores prácticas desde el primer momento.



Realmente no hay una buena razón para omitir cualquiera de estas pruebas de CC, sin importar qué tan grande sea su grupo. Especialmente considerando los insignificantes costos laborales que deben aplicarse para implementarlos (ver ejemplos en el artículo).



PS Contino tiene una buena cantidad de proyectos fantásticos. Si desea trabajar en proyectos de infraestructura ultramodernos o está buscando tareas serias, ¡contáctenos! Estamos contratando personal y buscando mentes brillantes en todos los niveles. En Contino, nos enorgullecemos de desarrollar proyectos de transformación de la nube de vanguardia para empresas medianas y grandes por igual.

«Infrastructure as a code in Ansible».



« Kubernetes Kubespray».