El crecimiento de la filosofía DevOps ha traído consigo el aumento de la capacidad de las empresas y otras organizaciones para entregar aplicaciones y servicios a gran velocidad. Para ello han surgido además de prácticas un sinfín de herramientas para ayudar a completar los trabajos. Prácticamente cada semana surgen nuevas startups con algún producto innovador o una versión mejorada de alguna herramienta ya existente. 

Una de las mayores innovaciones en el área DevOps ha sido la infraestructura como código (IaC). Permitiendo tanto a administradores como a desarrolladores la capacidad de crear, manipular y eliminar infraestructura mediante cambios empleando ficheros de código se ha producido un cambio en cómo administramos nuestros entornos.

Aunque estas herramientas son en gran medida revolucionarias y permiten dar solución a muchos problemas, en ocasiones conllevan una serie de pegas, en realidad como cualquier otra aplicación. Normalmente las herramientas de IaC al principio corren en local. Cuando el administrador o desarrollador de infraestructura está empezando con ello lo normal es que almacene los ficheros localmente, quizá en un repositorio, y luego clone los ficheros para su ejecución de forma local. Lo cual es perfectamente aceptable y una práctica muy común. Los problemas comienzan cuando se trata de escalar esta práctica al resto del equipo, por ejemplo, respecto a temas de visibilidad y gobernanza. Si todos están corriendo sus despliegues en local, el equipo no tiene una visibilidad clara de quién está desplegando qué cosa, cuándo y con qué variables. Aquí es donde las herramientas de automation para IaC pueden sernos de ayuda.

Existen muchas herramientas diferentes para ayudar a solucionar este tipo de problemas. Algunas mejores que otras como siempre, con sus pros y contras. Herramientas para manejar pipelines CI/CD, plataformas de automation a medida, plataformas de automation para un propósito concreto de IaC, etc. Meternos en cada una de ellas sería casi interminable ya que podríamos hablar horas sobre cada opción. Por eso vamos a repasar de forma general y dejaremos los detalles para próximos artículos. Demos un paso atrás para hablar de las 5 plataformas de automation imprescindibles para considerar antes de que nos embarquemos en cualquier proyecto de infraestructura-como-código. Como cada compañía es diferente y el caso de uso que se esté definiendo será muy particular, revisaremos las opciones sin un orden de preferencia en especial.

Role-Based Access Control (RBAC)

Este primer factor es muy importante. Aunque hemos dicho que las herramientas no estarían en orden de importancia, lo cierto es que el RBAC tiene que estar arriba en las prioridades para cualquier organización que esté evaluando seriamente automation en IaC. Hablábamos antes que a la hora de automatizar IaC puede provocar problemas de visibilidad entre los equipos de trabajo. Normalmente querrás saber quién ha desplegado tal cosa, cuándo, dónde y porqué cuando escalas entre los equipos. La razón por la que queremos ese tipo de visibilidad es porque deseamos controlar todos esos aspectos. De esta manera podemos minimizar problemas de presupuesto y preocupaciones en cuanto a seguridad. Así podemos ofrecer acceso a despliegue en modo autoservicio pero únicamente dentro de una serie de parámetros. Disponiendo de un control granular del RBAC nos permite diseñar políticas de seguridad alineadas con las necesidades de nuestro proyecto. Algunas herramientas tienen esto de forma integrada, otras requieren de un poco más de trabajo para hacerlas funcionar. La clave es que deberías siempre tener cierto control sobre el proceso de los despliegues.

Self-Hosted Agents/Runners

Siguiendo el hilo de seguridad un montón de herramientas de automation IaC son plataformas SaaS. Las plataformas de software-como-servicio pueden ser muy seguras pero hay veces, bien por razones de compliance o de seguridad, en las que necesitamos tener un mayor control sobre nuestros despliegues. Es cuando podemos usar los agentes autoensamblados o “runners”. Mediante este diseño podemos mantener nuestros secretos, como las credenciales del cloud y cualquier otra información variable que sea sensible. Podríamos usar cualquier solución de gestión de información sensible que queramos, ya sea un servicio disponible por el proveedor cloud o una solución de un tercero. Además, nos permitiría mantener nuestro código seguro. Todas estas herramientas tienen que tener una copia del código a desplegar, por lo que haremos un “Git clone” o algún otro proceso de copia para sacar los ficheros desde donde estén almacenados para ejecutarlos. Si se trata de una solución SaaS, necesitarán, sí o sí, acceder a nuestro código, por lo que si esto es un asunto crítico para nuestra organización habrá de tenerlo en cuenta. Si no queremos dar acceso a nuestro código o información sensible a una tercera empresa, un runner o agente autoensamblado puede ayudarnos a mantener la información de forma segura y bajo nuestro control.

Planificar los Pull Request

Esta característica, llamada de distintas formas según la plataforma que usemos (PR plan, speculative plan, etc.) es muy importante en lo relacionado con el workflow. En ocasiones no somos conscientes de lo importante que es planificar el pull request hasta que una vez lo probamos nos damos cuenta de lo fácil que es y cómo nos facilita la vida.

En esencia, lo que significa es que cada vez que abrimos un pull request de una rama, la plataforma de automation completará el despliegue hasta la fase de plan para que podemos ver exactamente qué es lo que hará el cambio de código. Si, por ejemplo, añadimos un 0 extra a una variable o fichero de código, podemos encontrarnos 100 instancias en lugar de 10. Sería genial saber qué es lo que ocurrirá con el cambio antes de que se produzca, dándonos la opción de rápidamente arreglar el error antes de que pase. En el mundo DevOps, es mejor siempre errar rápido y cerca del loop para detectar los fallos grandes antes de que ocurran, por eso esta característica es tan importante. Si la plataforma de automation que hemos elegido hace esto correctamente, cuando ejecute la fase del plan actualizará el pull request directamente y de manera automática reflejará los cambios como un comentario. De esta forma los desarrolladores podrán ver lo que va a pasar antes de que intenten hacer el merge del despliegue a la rama principal de producción.Si vamos un paso más allá añadiendo checks de servicio al pull request, podemos incluso configurarlo para que si el despliegue falla por cualquier motivo, se bloquee la opción de hacer un merge a los desarrolladores hasta que el problema se haya resuelto. Todas estas utilidades nos ayudan a trabajar con la metodología GitOps. El pilar central de GitOps es usar nuestro repositorio como una única fuente de verdad sobre lo que tiene que ser desplegado, es decir, una administración de la infraestructura con una metodología de pull requests. No es, como muchas veces se usa para simplemente almacenar los ficheros de terraform. Más información de GitOps aquí.

Despliegue Continuo (CD)

Esta característica es esencial para la mayoría de ingenieros DevOps, aunque dependiendo del workflow puede ser no tan importante. Aunque no se use en un inicio en nuestro proyecto no quiere decir que no se vaya a usar más adelante a medida que este evolucione y crezca con nuevos workflows. El CD (del inglés Continuous Deployment) es la capacidad de las plataformas de automatización de usar webhooks u otro tipo de conexión al repositorio de nuestro código fuente para que pueda disparar automáticamente un proceso de despliegue cuando hacemos un commit o un push al repositorio.

Esta función va asociada al plan de pull request, para hacerla funcionar correctamente también es necesario un despliegue continuo. Ahora bien, simplemente por disponer de un despliegue continuo no significa que se van a realizar push a producción en mitad de día cada vez que hay un commit o push. Deberíamos dar la posibilidad de pausar el proceso de despliegue después del plan de pruebas. Para algunos casos, como son los sandbox de desarrolladores, podríamos habilitar las auto aprobaciones de despliegues ya que en estos casos no serían necesarias las validaciones previas. Todo depende de los workflows y procesos que tengamos. Una buena plataforma nos dará la capacidad de controlar todo esto.

Extensibilidad “Shift Left” 

Esta funcionalidad es como un comodín, puede significar diferentes cosas dependiendo de cada situación. En esencia hablamos de la capacidad de integrar, o al menos interoperar, con una multitud de otras herramientas durante el proceso de despliegue. El concepto, que algunos llaman verificación continua, básicamente significa poder mover las herramientas y procesos pendientes al proceso de despliegue para estar pendientes de los problemas potenciales antes de que comiencen. Antes hemos hablado de detectar “problemillas” antes del despliegue. Esto no es solamente para temas de configuración de recursos. Hablamos de temas de seguridad, compliance, rendimiento, o incluso presupuesto. Si la herramienta IaC de automation que usamos nos da la posibilidad de integrar procesos y otras herramientas que usamos para validar estos temas dentro del proceso de despliegue nos dará más tranquilidad ayudándonos en la anticipación. Si tenemos la capacidad de que otras áreas de la compañía como seguridad o finanzas puedan estar implicados desde el principio nos va a permitir ser más ágiles. No tendríamos la preocupación de sobrepasar el presupuesto cada vez que hacemos un despliegue. No tendríamos que estar preocupados por un fallo de seguridad si estamos validando la seguridad durante cada despliegue. Este tipo de funcionalidad puede tener varios nombres según la herramienta que usemos. Como comenté antes, en DevOps es mejor cometer los errores pronto para darles solución rápidamente. Integrando las validaciones de otros equipos en el despliegue nos permitirá reaccionar antes.

Conclusión

Hemos hablado ya de las cinco funciones. Hemos comentado funciones básicas de seguridad, de algunos workflows de automatización imprescindibles para facilitarnos la vida. Y hemos comentado brevemente los temas más en la vanguardia del mundo DevOps como la verificación continua. Profundizar en cada tema lleva su tiempo hasta tenerlo integrado todo en nuestra plataforma de IaC. Algunas funciones pueden tener otros nombres pero los conceptos detrás son los mismos. Si tu plataforma no puede darles cabida, puede que no sea la más adecuada para nuestro proyecto.