🥇Cómo tomar el control de la infraestructura de red. Capítulo cuarto. Automatización. Plantillas

Este artículo es el sexto de una serie titulada «Cómo tomar el control de la infraestructura de red». Puedes encontrar el contenido de todos los artículos de la serie y los enlaces. aquí.

Dejando atrás algunos temas, decidí comenzar un nuevo capítulo.

Volveré a la seguridad un poco más adelante. Aquí quiero discutir un enfoque simple pero efectivo que, estoy seguro, puede ser útil para muchos en una forma u otra. Es más bien una breve historia sobre cómo la automatización puede cambiar la vida de un ingeniero. Se tratará del uso de plantillas. Al final, se incluye una lista de mis proyectos donde se puede ver cómo funciona todo lo que se describe aquí.

DevOps para redes

Crear configuraciones mediante scripts, usar GIT para el control de cambios de la infraestructura IT, la «carga» remota: estas ideas vienen a la mente cuando se piensa en la implementación técnica del enfoque DevOps. Las ventajas son evidentes. Pero, desafortunadamente, también hay desventajas.

Cuando hace más de 5 años, nuestros desarrolladores vinieron a nosotros, a los administradores de red, con estas propuestas, no estábamos entusiasmados.

Cabe mencionar que heredamos una red bastante heterogénea, compuesta por equipos de aproximadamente 10 proveedores diferentes. Algunas cosas eran fáciles de configurar a través de nuestra CLI favorita, pero en otros casos preferíamos usar GUI. Además, la larga experiencia con equipos «en vivo» nos acostumbró al control en tiempo real. Por ejemplo, al hacer cambios, me siento mucho más cómodo trabajando directamente a través de CLI. Así puedo ver rápidamente si algo salió mal y «revertir» los cambios. Todo esto estaba un poco en contradicción con sus ideas.

También surgen otras preguntas, como que de una versión de software a otra la interfaz puede cambiar un poco. Esto, al final, llevará a que tu script genere una «configuración» incorrecta. No querría usar producción para «pruebas».

O, ¿cómo entender que los comandos de configuración se aplicaron correctamente y qué hacer en caso de error?

No quiero decir que todas estas preguntas sean irresolubles. Simplemente, al decir «A», seguramente es razonable decir también «B» y, si deseas usar los mismos procesos para el control de cambios que en desarrollo, deberías tener, además de producción, entornos de desarrollo y pruebas. Entonces, este enfoque se vería completo. Pero, ¿cuánto costará esto?

Pero hay una situación en la que las desventajas se minimizan casi por completo y solo quedan ventajas. Estoy hablando de trabajos de proyectos.

Proyecto

Durante los últimos dos años he estado participando en un proyecto para construir un centro de datos para un gran proveedor. Soy responsable en este proyecto de F5 y Palo Alto. Desde la perspectiva de Cisco, esto se considera 'equipo de terceros'.

Personalmente, hay dos etapas claramente definidas en este proyecto.

Primera etapa

El primer año estuve increíblemente ocupado, trabajé por las noches y los fines de semana. No podía levantar la vista. La presión del equipo directivo y del cliente era fuerte y continua. En la rutina constante, no podía ni siquiera intentar optimizar el proceso. No se trataba solo de configurar el equipo, sino de elaborar la documentación del proyecto.

Así comenzaron las primeras pruebas, y me sorprendió cuántos pequeños errores e imprecisiones se habían cometido. Por supuesto, todo funcionaba, pero faltaba una letra en el nombre, aquí faltaba una línea en el comando... Las pruebas continuaron y yo ya estaba inmerso en una lucha diaria constante con errores, pruebas y documentación.

Así continuó durante un año. El proyecto, según entiendo, no fue fácil para nadie, pero poco a poco el cliente se volvió cada vez más satisfecho, y esto nos permitió contratar ingenieros adicionales que pudieron asumir parte de la rutina.

Ahora se podía mirar a nuestro alrededor.
Y este fue el comienzo de la segunda etapa.

Segunda etapa

Decidí automatizar el proceso.

Lo que entendí de mi comunicación con los desarrolladores en aquel entonces (y hay que dar crédito, teníamos un gran equipo) fue que el formato de texto, aunque a primera vista parezca algo del mundo del sistema operativo DOS, tiene una serie de propiedades valiosas.
Por ejemplo, el formato de texto será útil si desea aprovechar al máximo las ventajas de GIT y todos sus derivados. Y yo quería.

Bueno, parecería que uno podría simplemente almacenar la configuración o la lista de comandos, pero hacer modificaciones resulta bastante incómodo. Además, al diseñar existe otra tarea importante. Debe tener documentación que describa su diseño en general (Low Level Design) y la implementación específica (Network Implementation Plan). Y en este caso, el uso de plantillas parece ser una opción muy adecuada.

Así, al usar YAML y Jinja2, el archivo YAML con parámetros de configuración, como direcciones IP, números BGP AS,… cumple un excelente papel como NIP, mientras que las plantillas de Jinja2 incluyen una sintaxis correspondiente al diseño, es decir, son un reflejo del LLD.

El estudio de los lenguajes YAML y Jinja2 llevó dos días. Para entender cómo funciona, son suficientes algunos buenos ejemplos. Luego, pasé alrededor de dos semanas creando todas las plantillas correspondientes a nuestro diseño: una semana para Palo Alto y otra semana para F5. Todo esto se publicó en el githab corporativo.

Ahora el proceso de cambios se veía de la siguiente manera:

cambié el archivo YAML
creé el archivo de configuración usando la plantilla (Jinja2)
guardé en el repositorio remoto
subí la configuración creada al equipo
vi el error
cambié el archivo YAML o la plantilla Jinja2
creé el archivo de configuración usando la plantilla (Jinja2)
…

Es evidente que al principio se necesitaba mucho tiempo para las correcciones, pero después de una o dos semanas esto se volvió más bien una rareza.

Una buena prueba y oportunidad para depurar todo fue el deseo del cliente de cambiar la convención de nombres. Quien ha trabajado con F5 entiende la complejidad de la situación. Pero para mí todo fue bastante simple. Cambié los nombres en el archivo YAML, eliminé toda la configuración del equipo, generé una nueva y la subí. Todo, incluyendo la corrección de errores, tomó 4 días: dos días para cada tecnología. Después de eso, estaba listo para la siguiente etapa, que es la creación de centros de datos DEV y Staging.

Dev y Staging

Staging replica casi completamente la producción. Dev es una copia muy reducida y construida principalmente sobre equipamiento virtual. Una situación ideal para aplicar el nuevo enfoque. Si se separa el tiempo que gasté, creo que el trabajo no llevó más de 2 semanas. El tiempo principal es el tiempo de espera por la otra parte y la búsqueda conjunta de problemas. La implementación de terceros pasó casi desapercibida para los demás. Incluso hubo tiempo para aprender algo y escribir un par de artículos en Habr 🙂

Resumiendo

Entonces, ¿qué tengo en resultado?

todo lo que necesito para cambiar la configuración es modificar un archivo YAML simple y claramente estructurado con parámetros de configuración. Nunca cambio un script de Python y muy rara vez (solo si hay un error) cambio la plantilla Jinja2.
Desde el punto de vista de la documentación, se obtiene una situación casi ideal. Cambias la documentación (los archivos YAML cumplen el papel de NIP) y subes esta configuración al hardware. Así, tu documentación siempre está actualizada.

Todo esto llevó a que

el porcentaje de errores se redujo prácticamente a 0
se eliminó el 90 por ciento de la rutina
la velocidad de implementación aumentó considerablemente

PAY, F5Y, ACY

Dije que unos pocos ejemplos son suficientes para entender cómo funciona.
Aquí tienes una versión breve (y, por supuesto, modificada) de lo que se creó durante mi trabajo.

PAY = implementación Palo Alto de Yaml = Palo Alto de YAML
F5Y = implementación F5 from Yaml = F5 from Yaml (próximamente)
ACY = implementación ACi de Yaml = F5 from Yaml

Agregaré algunas palabras sobre ACY (no confundir con ACI).

Aquellos que han trabajado con ACI saben que esta maravilla (y en el buen sentido también) no fue creada por verdaderos expertos en redes :). ¡Olvida todo lo que sabías sobre redes — no te servirá!
Un poco exagerado, pero transmite aproximadamente la sensación que he estado experimentando durante 3 años trabajando con ACI.

Y en este caso, ACY no solo brinda la posibilidad de establecer un proceso de control de cambios (lo cual es especialmente importante en el caso de ACI, porque se supone que es la parte central y más crítica de tu centro de datos), sino que también te ofrece una interfaz amigable para crear la configuración.

Los ingenieros en este proyecto utilizan Excel para configurar ACI en lugar de YAML, con precisión para los mismos objetivos. Usar Excel, por supuesto, tiene ventajas: