Marathon<\/a><\/noindex>\u00a0<\/li>\n<\/ul>\n<\/p>\n
7. Infraestructura como c\u00f3digo (IaC)<\/h2>\n
<\/p>\n
Descripci\u00f3n breve de la tecnolog\u00eda<\/h3>\n
\n Y as\u00ed llegamos a la \u00faltima secci\u00f3n. Generalmente, esta tecnolog\u00eda y las tareas relacionadas no est\u00e1n bajo la responsabilidad de los ingenieros de automatizaci\u00f3n. Y hay razones para esto. En primer lugar, en muchas organizaciones, los problemas de infraestructura est\u00e1n bajo el control del departamento de DevOps, y el equipo de desarrollo no se preocupa mucho por lo que sostiene el pipeline y c\u00f3mo se debe mantener todo lo relacionado. En segundo lugar, seamos honestos, la pr\u00e1ctica de \"Infraestructura como c\u00f3digo (IaC)\" a\u00fan no se aplica en muchas empresas. Pero definitivamente se ha convertido en una tendencia popular y es importante intentar estar involucrado en los procesos, enfoques y herramientas relacionados. O, al menos, estar al tanto de lo que sucede.<\/p>\n
Empecemos con la motivaci\u00f3n para usar este enfoque. Ya hemos discutido que para ejecutar pruebas en GitlabCI necesitamos al menos recursos para ejecutar el Gitlab Runner. Y para iniciar contenedores con navegadores\/emuladores, debemos reservar una VM o un cl\u00faster. Adem\u00e1s de los recursos para pruebas, necesitamos una cantidad significativa de potencia para mantener los entornos de desarrollo, staging, producci\u00f3n, lo que tambi\u00e9n incluye bases de datos, horarios autom\u00e1ticos, configuraciones de red, balanceadores de carga, permisos de usuarios, etc. El problema clave radica en los esfuerzos requeridos para mantener todo esto. Hay varias maneras en que podemos realizar cambios y desplegar actualizaciones. Por ejemplo, en el contexto de GCP, podemos utilizar la consola de UI en el navegador y realizar todas las acciones haciendo clic en botones. Un m\u00e9todo alternativo podr\u00eda ser el uso de llamadas API para interactuar con entidades en la nube o el uso de la utilidad de l\u00ednea de comandos gcloud para realizar las manipulaciones necesarias. Pero con una cantidad realmente grande de diferentes entidades y elementos de infraestructura, se vuelve dif\u00edcil o incluso imposible realizar todas las operaciones manualmente. Adem\u00e1s, todas estas acciones manuales son incontroladas. No podemos enviarlas para revisi\u00f3n antes de su ejecuci\u00f3n, utilizar un sistema de control de versiones y revertir r\u00e1pidamente cambios que condujeron a un incidente. Para resolver tales problemas, los ingenieros han creado y siguen creando scripts autom\u00e1ticos en bash\/shell, lo que no es mucho mejor que los m\u00e9todos anteriores, ya que no son tan f\u00e1ciles de leer, entender, mantener y modificar r\u00e1pidamente en un estilo procedimental.<\/p>\n
En este art\u00edculo y gu\u00eda pr\u00e1ctica, utilizo dos herramientas relacionadas con la pr\u00e1ctica de IaC. Estas son Terraform y Ansible. Algunos creen que no tiene sentido usarlas al mismo tiempo, ya que sus funcionalidades son similares y son intercambiables. Sin embargo, el hecho es que inicialmente se les asignan tareas completamente diferentes. Y el hecho de que estas herramientas deber\u00edan complementarse fue confirmado en una presentaci\u00f3n conjunta por desarrolladores de HashiCorp y RedHat. La diferencia conceptual radica en que Terraform es una herramienta de aprovisionamiento para gestionar los propios servidores. Mientras que Ansible es una herramienta de gesti\u00f3n de configuraciones, encargada de instalar, configurar y gestionar el software en esos servidores.<\/p>\n
Otra caracter\u00edstica clave que distingue a estas herramientas es el estilo de escritura del c\u00f3digo. A diferencia de bash y Ansible, Terraform utiliza un estilo declarativo, basado en la descripci\u00f3n del estado final deseado que se debe alcanzar como resultado de su ejecuci\u00f3n. Por ejemplo, si estamos a punto de crear 10 VMs y aplicar cambios a trav\u00e9s de Terraform, obtendremos 10 VMs. Si aplicamos el script nuevamente, no suceder\u00e1 nada, ya que ya tenemos 10 VMs, y Terraform lo sabe porque almacena el estado actual de la infraestructura en un archivo de estado. En cambio, Ansible utiliza un enfoque procedural y, si le pedimos que cree 10 VMs, en la primera ejecuci\u00f3n obtendremos 10 VMs, de manera similar a Terraform. Pero tras una segunda ejecuci\u00f3n, ya tendremos 20 VMs. Esta es la importante diferencia. En el estilo procedural, no almacenamos el estado actual y simplemente describimos la secuencia de pasos que deben llevarse a cabo. Por supuesto, podemos manejar diversas situaciones, agregar algunas comprobaciones sobre la existencia de recursos y su estado actual, pero no tiene sentido gastar nuestro tiempo y esforzarnos en controlar esta l\u00f3gica. Adem\u00e1s, esto aumenta el riesgo de cometer errores.\u00a0<\/p>\n
Resumiendo todo lo anterior, se puede concluir que para el aprovisionamiento de servidores, la herramienta m\u00e1s adecuada es Terraform y la notaci\u00f3n declarativa. Por otro lado, el trabajo de gesti\u00f3n de configuraciones es mejor delegarlo a Ansible. Una vez aclarado esto, veamos ejemplos de uso en el contexto de la automatizaci\u00f3n.<\/p>\n
Valor para la infraestructura de automatizaci\u00f3n<\/h3>\n
\n Aqu\u00ed es importante entender que la infraestructura de automatizaci\u00f3n de pruebas debe considerarse como parte de toda la infraestructura de la empresa. Eso significa que todas las pr\u00e1cticas de IaC deben aplicarse de manera global a los recursos de toda la organizaci\u00f3n. Qui\u00e9n es responsable de esto depende de sus procesos. El equipo de DevOps tiene m\u00e1s experiencia en estos temas, ya que ve la situaci\u00f3n en su totalidad. Sin embargo, los ingenieros de QA est\u00e1n m\u00e1s involucrados en el proceso de construcci\u00f3n de la automatizaci\u00f3n y la estructura del pipeline, lo que les permite identificar mejor todos los cambios necesarios y las oportunidades de mejora. La mejor opci\u00f3n es trabajar juntos, intercambiar conocimientos e ideas para lograr el resultado esperado.\u00a0<\/p>\n
Voy a dar algunos ejemplos del uso de Terraform y Ansible en el contexto de la automatizaci\u00f3n de pruebas y las herramientas que hemos discutido anteriormente:<\/p>\n
1. Describir a trav\u00e9s de Terraform las caracter\u00edsticas y par\u00e1metros necesarios de las VMs y cl\u00fasteres.<\/p>\n
2. Instalar con Ansible las herramientas necesarias para la prueba: docker, Selenoid, Selenium Grid y cargar las versiones necesarias de navegadores\/emuladores.<\/p>\n
3. Describir a trav\u00e9s de Terraform las caracter\u00edsticas de la VM en la que se ejecutar\u00e1 GitLab Runner.<\/p>\n
4. Instalar con Ansible GitLab Runner y las herramientas auxiliares necesarias, establecer configuraciones y ajustes.<\/p>\n
Ilustraci\u00f3n del estado actual de la infraestructura<\/h3>\n
\n![\"Las](\"\/wp-content\/uploads\/2020\/04\/5d793a800a4ef62e181e6cb3a3f0544e.png\")
<\/p>\n
Enlaces para estudiar:<\/h3>\n
<\/p>\n