Los pros y los contras de la infraestructura como código

Si trabaja en el mundo de la automatización y DevOps, probablemente se haya topado con el término "Infraestructura como código" (IaC). Mediante Wikipedia:

"La infraestructura como código (IaC) es el proceso de administrar y aprovisionar centros de datos informáticos a través de archivos de definición legibles por máquina, en lugar de configuración de hardware físico o herramientas de configuración interactiva".

Durante el año pasado, administré la infraestructura: Red Hat Virtualización (RHV) y entornos de tecnología de virtualización propietaria. Al principio, automaticé algunas tareas, pero la mayor parte de mi trabajo era manual. Intenté automatizar el aprovisionamiento de la implementación y configuración de vCenter y ESXi. No fue un éxito tan grande como quería que fuera, y ciertamente no fue un conducto de ningún tipo. Después de eso, automaticé algunas otras tareas de infraestructura más pequeñas.

Sin embargo, en los últimos tres o cuatro meses, comencé a invertir más tiempo en automatizar implementaciones completas. Esto se debe a que me pidieron que trabajara en la automatización de la implementación del entorno RHV que usamos para las pruebas. Nuestra infraestructura contiene Red Hat OpenStack, RHV y algunos entornos de VMware; administramos alrededor de 20 TB de almacenamiento y 23 hosts bare metal; y administro más de 50 máquinas virtuales.

También soy especialista certificado en automatización de Ansible por Red Hat. Entonces, cuando me pidieron que me hiciera cargo de este proyecto de automatización, decidí usar algunos de los roles de Ansible ya escritos por el oVirt equipo. Para que funcionaran, tuve que agregar playbooks personalizados y scripts de shell, y juntarlos todos como uno solo. Jenkins pipeline hizo que funcionara a la perfección.

Después de trabajar en este proyecto, puedo decir que sé lo que significa tener tu infraestructura como código. En la actualidad, dos de nuestros cuatro entornos RHV están documentados en código y se mantienen en un repositorio Git controlado por versión.

A través de mi experiencia, he aprendido que el enfoque de IaC tiene muchas ventajas y desventajas que sería conveniente considerar.

Índice

    Beneficios de IaC

    • Estoy relativamente relajado porque sé que si algo sale mal, puedo llamar a mi canalización de Jenkins para volver a implementar mi env con un solo clic.
      • Antes de la automatización, si algo salía mal, tenía que volver a implementar y configurar meticulosamente todo mi entorno. Fue un desafío traer de vuelta el mismo entorno. Esto se debe a que cada vez que hay un cambio en el entorno, los sistemas que interactúan con el entorno también necesitan actualizaciones. Un ejemplo es asegurarse de que los nombres del centro de datos, el clúster, la red y el almacén de datos sean exactamente iguales después de la reimplementación.
    • Puedo compartir este código con otros equipos o personas, y ellos pueden usarlo para configurar su env.
      • La mayor parte del código que escribo tiene una base que puede tomar una lista de variables de entrada que le permiten personalizar la implementación según sus necesidades. Por lo tanto, es un código compartible que otros pueden reutilizar.
    • Mi entorno será el mismo cada vez que ejecute la canalización.
      • Como mi canalización utiliza un conjunto prescrito de parámetros para la implementación, cada vez que ejecuto mi canalización obtengo exactamente el mismo entorno, en términos de cantidad de hosts, redes, centros de datos, clústeres y almacenes de datos, y sus nombres son idénticos.
    • Mi canalización es escalable.
      • Mi código está generalizado de tal manera que pasar un archivo de configuración con los parámetros correctos me permitirá implementar env en uno, dos o 100 servidores porque algunos de los parámetros se ejecutan en un bucle que puede tomar cualquier cantidad de parámetros.

    Desventajas de IAC

    • A veces es difícil mantener todo ese código. A medida que cambian las versiones del software, es posible que sea necesario actualizar el código. Definitivamente es un costo adicional.
      • Ya tengo alrededor de 8500 líneas de código en mi repositorio de canalización de implementación de RHV, y todavía hay algunos elementos en mi lista de tareas pendientes que necesito actualizar; algunas son características, otras son deuda técnica.
    • Cuando la ejecución falla en alguna parte, puede que no sea tan fácil reiniciar exactamente en el mismo punto, y la reejecución desde cero puede llevar mucho tiempo.
    • Si está utilizando un código escrito por otra persona, es posible que deba dedicar mucho tiempo a comprenderlo, lo que puede ser difícil.
      • Por ejemplo, uno de los roles de Ansible que estaba usando carecía de algunas de las funciones requeridas. Pasé mucho tiempo entendiendo, luego depurando, luego agregando nuevas características, luego haciendo que los mantenedores las fusionaran en el repositorio (donde tuvimos más ciclos de revisión-retroalimentación-actualización-repetición).

    IaC ha mejorado mi carrera en muchos sentidos, pero hay momentos en los que es difícil manejarlo como equipo.

    ¿Que piensas? ¿Cuáles son sus mejores prácticas o puntos débiles de IaC?

    Artículos de interés

    Subir