Dada la necesidad de crear infraestructuras en varios entornos al mismo tiempo que se garantiza la estandarización y el monitoreo efectivo, resulta crucial proveer estos entornos de forma segura. Para lograr esto, adoptar un enfoque de infraestructura inmutable, donde los entornos se proveen como código, es fundamental.
El propósito de este artículo es demostrar una posible aproximación para lograr esto utilizando las estructuras de GitLab para imponer plantillas y estándares, Terraform para aplicar y mantener estándares en servidores, y Ansible para la provisión y configuración de software, utilizando un modelo de roles compartidos en repositorios. Para manejar el estado de las máquinas con Terraform, utilizamos MinIO, ya que permite esta implementación en entornos locales.
Diseño de Arquitectura
Paso 1
El proceso siempre comienza con la presentación de un issue estandarizado, especificando el modelo de stack a utilizar, si se necesitan permisos de cortafuegos, y si se trata de una configuración nueva o solo una actualización de recursos.
Paso 2
El operador revisa el issue y comienza el proceso. Todas las conversaciones y el tiempo dedicado se registran dentro del issue.
Paso 3
Se inicia un nuevo proyecto en GitLab, basado en el modelo de infraestructura que se creará. Este proyecto se coloca dentro del grupo correspondiente en GitLab, donde hereda las variables de entorno necesarias para la creación estandarizada de infraestructuras.
Paso 4
Al crear el proyecto, solo necesita especificar las IPs para la infraestructura a provisionar en el entorno especificado en el issue (KVM, VMware). Después de planificar con Terraform, se crean los recursos requeridos, incluyendo agregar etiquetas si es necesario, para que Veeam realice respaldos basados en políticas de etiqueta.upon completion, the state of the created infrastructure is stored in a bucket.
Paso 5
El siguiente paso implica ejecutar tareas estándar para todos los servidores, como identificarlos, actualizar paquetes, instalar utilidades necesarias y registrar el anfitrión en Zabbix para monitorear básico del sistema operativo y de la pila. Dependiendo del grupo de recursos, se asignan las claves de acceso apropiadas al equipo responsable. Por ejemplo, los administradores de bases de datos reciben claves de acceso para los servidores de bases de datos.
Paso 6
Basado en el modelo elegido, se lleva a cabo el proceso de instalación y configuración de toda la pila. Asimismo, se crean usuarios y, cuando sea necesario, se registran las credenciales en Vault.
Paso 7
Con la aplicación ahora ejecutándose en el nuevo entorno, se puede realizar un seguimiento específico para cada pila, registrando el nuevo servidor en Consul. En su turno, Prometheus identifica dónde necesita recolectar información. Cada pila tiene su panel de seguimiento configurado ya, variando solo por el nombre del proyecto que se creó.
Paso 8
La nueva infraestructura se entrega al solicitante. En el caso de bases de datos, las credenciales se proporcionan directamente en Vault.
Estructura del Proyecto
La estructura de la carpeta en GitLab se organiza de la siguiente manera:
- /infrastructure/: El grupo principal, donde se deben almacenar las variables de entorno globales y los valores por defecto
- /infrastructure/gitlab-models: Modelos de pipelines, donde tenemos dos proyectos principales
- ansible-pipelines: Un proyecto dedicado a mantener las pilas y la composición de los roles.
En la imagen de arriba, vemos un ejemplo de tareas comunes. En la estructura, se encuentra en la ruta:/infrastructure/gitlab-models/ansible-pipelines/common-task/provision.yml
- terraform-pipelines: Pipelines para los modelos de infraestructura disponibles, como vSphere, KVM, AWS, etc.
En la imagen de arriba, tenemos un ejemplo de una tubería que reside dentro del grupo terraform-pipelines, como kvm-terraform-pipeline.yml. Como podemos ver, es un modelo de GitLab CI diseñado para ser extendido en una tubería de stack.
- /infrastructure/templates: En este grupo, tenemos los proyectos de bootstrap, que se utilizarán para crear los modelos de stack.
- /infrastructure/provision/ansible/roles: En este proyecto, solo tenemos los roles de Ansible, lo que nos permite centralizar y actualizar los roles de manera aislada.
- /infrastructure/dependencies-iac: Este repositorio contiene las dependencias de la plataforma, como los archivos Docker para Terraform y Ansible, garantizando que las versiones de las herramientas y bibliotecas necesarias no se modifiquen.
- /infrastructure/modules/: Los módulos creados para Terraform se almacenan en este repositorio, con cada proyecto teniendo su respectivo directorio.
- /infrastructure/on-premise/: Este grupo es donde se mantienen las infraestructuras creadas, y segmentadas por entorno, centro de datos, stack y proyecto. En la imagen, podemos ver la jerarquía de grupos y subgrupos hasta el proyecto final. En cada uno de estos niveles, podemos anular los valores de variables asociadas con los grupos.
Cómo Usar una Plataforma
Para simplificar el uso de la plataforma, creamos un repositorio llamado issues-ops, donde proporcionamos una plantilla de issue que se puede seleccionar según necesidades específicas. De esta manera, la solicitud de infraestructura se registra desde el principio.
Una vez creado el issue, el equipo DevSecOps puede comenzar a configurar el entorno. Para esto, simplemente necesitan navegar hasta el grupo adecuado, en este caso, infrastructure/on-premise/staging/dc1/loadbalancer/nginx, y crear un nuevo proyecto basado en una plantilla. Posteriormente, deben proporcionar el nombre del proyecto a crear y asignar las variables necesarias.
Dentro de cada plantilla, el archivo .gitlab-ci.yml requerido para la creación del entorno ya está configurado. En el caso de NGINX, se configura en este formato.
En esta configuración, se incluyen tanto las plantillas de creación de infraestructura como las plantillas de Ansible, garantizando que los roles predeterminados ya están integrados en estos proyectos. Además, proporcionamos pasos para ampliar el modelo. Si se necesitan instalar roles adicionales, solo se agrega el bloque correspondiente, permitiendo un enfoque modular y de bloques en la configuración.
En la imagen de abajo, vemos el pipeline que ejecutó la creación del entorno solicitado. Notarán que authorized_keys y common se ejecutaron, incluso sin declararse explicitamente en el .gitlab-ci.yml. Esto es porque tenemos roles estándar que provienen de la plantilla de Ansible importada, garantizando que los roles predeterminados se apliquen a todos los proyectos.
Conclusión
La plataforma de infraestructura ha contribuido granmente a mantener y aplicar normas porque requiere un modelo predefinido que debe ser planeado, probado, implementado y puesto a disposición como una plantilla antes de que pueda ser creada cualquier nueva infraestructura. Este proceso garantiza que cada vez que necesitemos proveer recursos en un entorno, estamos estableciendo normas consistentes, versando estos entornos y asegurando que puedan ser reconstruidos de forma fiable si es necesario.
Uno de los mayores desafíos es mantener y validar los modelos actualizados, especialmente a medida que las aplicaciones evolucionan y las versiones del sistema operativo cambian. Es crucial recordar que al usar la infraestructura como código, todos los cambios deben ser realizados a través de él, garantizando la versión de configuración y la inmutabilidad del entorno. No hacer esto puede provocar que la plataforma reverta el entorno a su estado definido, potencialmente anulando cambios manuales.
El modelo propuesto en este artículo es versátil y aplicable a entornos tanto en la nube como en la tierra, lo que lo convierte en una solución efectiva para infraestructuras híbridas.
Source:
https://dzone.com/articles/implement-an-iac-platform-with-terraform-ansible-gitlab