Este artículo es el sexto de la serie "Cómo tomar el control de su infraestructura de red". Se pueden encontrar los contenidos de todos los artículos de la serie y los enlaces. .
Habiendo dejado varios temas atrás, decidí comenzar un nuevo capítulo.
Volveré a seguridad un poco más tarde. Aquí quiero discutir un enfoque simple pero efectivo, que estoy seguro, de una forma u otra, puede ser útil para muchos. Esta es más bien una historia corta sobre cómo la automatización puede cambiar la vida de un ingeniero. Hablaremos sobre el uso de plantillas. Al final hay una lista de mis proyectos donde podrás ver cómo funciona todo lo aquí descrito.
DevOps para la red
Crear una configuración con un script, usar GIT para controlar los cambios en la infraestructura de TI, "cargar" remotamente: estas ideas surgen primero cuando se piensa en la implementación técnica del enfoque DevOps. Las ventajas son obvias. Pero, lamentablemente, también existen desventajas.
Cuando hace más de 5 años nuestros desarrolladores, los networkers, se acercaron a nosotros con estas propuestas, no quedamos encantados.
Debo decir que heredamos una red bastante heterogénea, compuesta por equipos de unos 10 proveedores diferentes. Era conveniente configurar algunas cosas a través de nuestro cli favorito, pero en otras preferíamos usar la GUI. Además, el largo trabajo con equipos "vivos" nos ha enseñado a controlar en tiempo real. Por ejemplo, al realizar cambios, me siento mucho más cómodo trabajando directamente a través del cli. De esta manera puedo ver rápidamente que algo salió mal y revertir los cambios. Todo esto estaba en cierta contradicción con sus ideas.
También surgen otras preguntas, por ejemplo, la interfaz puede cambiar ligeramente de una versión a otra del software. Esto eventualmente hará que su script cree una "configuración" incorrecta. No me gustaría utilizar la producción para el "rodaje".
¿O cómo entender que los comandos de configuración se aplicaron correctamente y qué hacer en caso de error?
No quiero decir que todos estos problemas sean irresolubles. Probablemente solo decir "A" tenga sentido para decir también "B" y si desea utilizar los mismos procesos para el control de cambios que en el desarrollo, entonces necesita tener entornos de desarrollo y ensayo además de producción. Entonces este enfoque parece completo. ¿Pero cuánto costará?
Pero hay una situación en la que las desventajas prácticamente se nivelan y solo quedan las ventajas. Me refiero al trabajo de diseño.
proyecto
Durante los últimos dos años participo en un proyecto para construir un centro de datos para un gran proveedor. Soy responsable de F5 y Palo Alto en este proyecto. Desde el punto de vista de Cisco, se trata de "equipos de terceros".
Para mí personalmente, hay dos etapas distintas en este proyecto.
Primera etapa
El primer año estuve infinitamente ocupado, trabajé noches y fines de semana. No podía levantar la cabeza. La presión de la dirección y del cliente fue fuerte y continua. En una rutina constante, ni siquiera podía intentar optimizar el proceso. No se trataba sólo ni tanto de la configuración del equipo como de la preparación de la documentación de diseño.
Han comenzado las primeras pruebas y me sorprendería saber cuántos pequeños errores e imprecisiones se cometieron. Por supuesto, todo funcionó, pero faltaba una letra en el nombre, faltaba una línea en el comando... Las pruebas siguieron y siguieron, y yo ya estaba en una lucha constante y diaria con errores, pruebas y documentación. .
Esto continuó durante un año. El proyecto, según tengo entendido, no fue fácil para todos, pero poco a poco el cliente quedó cada vez más satisfecho y esto permitió contratar ingenieros adicionales que pudieron encargarse ellos mismos de parte de la rutina.
Ahora podríamos mirar un poco 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 ese momento (y debemos rendir homenaje, teníamos un equipo fuerte) es que el formato de texto, aunque a primera vista parece algo del mundo del sistema operativo DOS, tiene un número de propiedades valiosas.
Así, por ejemplo, el formato de texto te será útil si quieres aprovechar al máximo GIT y todos sus derivados. Y yo quería hacerlo.
Bueno, parecería que simplemente puedes almacenar una configuración o una lista de comandos, pero realizar cambios es bastante inconveniente. Además, existe otra tarea importante durante el diseño. Debe tener documentación que describa su diseño en su conjunto (Diseño de bajo nivel) y su implementación específica (Plan de implementación de red). Y en este caso, el uso de plantillas parece una opción muy adecuada.
Así, al utilizar YAML y Jinja2, un archivo YAML con parámetros de configuración como direcciones IP, números BGP AS,… cumple perfectamente el papel de NIP, mientras que las plantillas de Jinja2 incluyen una sintaxis correspondiente al diseño, es decir, es esencialmente un reflejo de LLD.
Me tomó dos días aprender YAML y Jinja2. Unos pocos buenos ejemplos son suficientes para entender cómo funciona esto. Luego nos llevó unas dos semanas crear todas las plantillas que coincidieran con nuestro diseño: una semana para Palo Alto y otra semana para F5. Todo esto fue publicado en githab corporativo.
Ahora el proceso de cambio se veía así:
- cambió el archivo YAML
- creó un archivo de configuración usando una plantilla (Jinja2)
- guardado en un repositorio remoto
- subió la configuración creada al equipo
- vi un error
- cambió el archivo YAML o la plantilla Jinja2
- creó un archivo de configuración usando una plantilla (Jinja2)
- ...
Está claro que al principio se dedicó mucho tiempo a la edición, pero después de una o dos semanas esto se volvió bastante raro.
Una buena prueba y oportunidad para depurar todo fue el deseo del cliente de cambiar la convención de nomenclatura. Quienes trabajaron con F5 comprenden lo picante de la situación. Pero para mí todo fue bastante sencillo. Cambié los nombres en el archivo YAML, eliminé toda la configuración del equipo, generé una nueva y la subí. Todo, incluidas las correcciones de errores, tomó 4 días: dos días para cada tecnología. Después de eso, estaba listo para la siguiente etapa, es decir, la creación de centros de datos DEV y Staging.
Desarrollo y puesta en escena
En realidad, la puesta en escena replica completamente la producción. Dev es una copia muy simplificada construida principalmente en hardware virtual. Una situación ideal para un nuevo enfoque. Si aislo el tiempo que dediqué del proceso general, creo que el trabajo no tomó más de 2 semanas. Lo principal es esperar al otro lado y buscar problemas juntos. 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 sobre Habré :)
para resumir
Entonces, ¿qué tengo en el resultado final?
- Todo lo que tengo que hacer para cambiar la configuración es cambiar un archivo YAML simple y claramente estructurado con parámetros de configuración. Nunca cambio el script de Python y muy raramente (solo si hay un error) cambio el heatlate de Jinja2.
- Desde el punto de vista de la documentación, esta es una situación casi ideal. Cambias la documentación (los archivos YAML sirven como NIP) y subes esta configuración al equipo. De esta forma tu documentación estará siempre actualizada
Todo esto llevó al hecho de que
- la tasa de error ha caído a casi 0
- El 90 por ciento de la rutina se ha ido.
- la velocidad de implementación ha aumentado significativamente
PAGO, F5Y, ACY
Dije que algunos ejemplos son suficientes para entender cómo funciona.
Aquí hay una versión corta (y por supuesto modificada) de lo que se creó durante mi trabajo.
= despliegue Palo Ala de Yaml = Palo Alto de Yaml
= despliegue F5 en Yaml = F5 en Yaml (próximamente)
= despliegue ACYo de Yaml = F5 en Yaml
Agregaré algunas palabras sobre ACY (que no debe confundirse con ACI).
Quienes han trabajado con ACI saben que este milagro (y en el buen sentido también) definitivamente no fue creado por networkers :). Olvídese de todo lo que sabía sobre la red: ¡no le será útil!
Es un poco exagerado, pero transmite a grandes rasgos la sensación que he experimentado constantemente, durante los últimos 3 años, trabajando con ACI.
Y en este caso, ACY no es sólo una oportunidad para construir 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 su centro de datos), sino que también le brinda una interfaz fácil de usar para crear la configuración.
Los ingenieros de este proyecto utilizan Excel para configurar ACI en lugar de YAML exactamente para los mismos propósitos. Por supuesto, existen ventajas al utilizar Excel:
- tu NIP en un solo archivo
- hermosos carteles que sean agradables de ver para el cliente
- puedes usar algunas herramientas de excel
Pero hay un inconveniente y, en mi opinión, supera a los pros. Controlar los cambios y coordinar el trabajo en equipo se vuelve mucho más difícil.
ACY es en realidad una aplicación de los mismos enfoques que utilicé para que un tercero configurara ACI.
Fuente: habr.com