Este artículo es el sexto de una serie de artículos titulados "Cómo tomar la infraestructura de red bajo su control". El contenido de todos los artículos de la serie y los enlaces se puede encontrar aquí .
Dejando algunos temas atrás, decidí comenzar un nuevo capítulo.
Volveré a la 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. Es más bien una historia corta sobre cómo la automatización puede cambiar la vida de un ingeniero. Se tratará del uso de plantillas. Al final hay una lista de mis proyectos, donde puede ver cómo funciona todo lo que se describe aquí.
DevOps para la web
Crear una configuración con un script, usar GIT para controlar los cambios en la infraestructura de TI, "relleno" remoto: estas ideas son lo primero cuando se piensa en la implementación técnica del enfoque DevOps. Las ventajas son obvias. Pero, desafortunadamente, también hay desventajas.
Cuando hace más de 5 años, nuestros desarrolladores acudieron a nosotros, a los networkers, con estas ofertas, no estábamos entusiasmados.
Debo decir que heredamos una red bastante heterogénea que consta del equipo de unos 10 proveedores diferentes. Algo era conveniente de configurar a través de nuestro cli favorito, pero en algún lugar preferimos usar la GUI. Además, el trabajo prolongado en equipos "en vivo" se enseñó al control en tiempo real. Por ejemplo, cuando hago cambios, me siento mucho más cómodo trabajando directamente a través de cli. Entonces puedo ver rápidamente que algo salió mal y "revertir" los cambios. Todo esto estaba en contradicción con sus ideas.
Surgen otras preguntas, por ejemplo, de una versión a otra, la interfaz puede variar ligeramente. Esto, al final, hará que su script cree la "configuración" incorrecta. No quisiera usar la producción para un robo.
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 son irresolubles. Simplemente diciendo "A", probablemente sea sabio decir "B", y si desea utilizar los mismos procesos para el control de cambios que en el desarrollo, necesita tener entornos de desarrollo y puesta en escena además de la producción. Entonces este enfoque parece completo. ¿Pero cuánto costará?
Pero hay una situación en la que los contras están casi nivelados, y solo quedan los profesionales. Estoy hablando del trabajo de diseño.
Proyecto
Durante los últimos dos años, he estado participando en un proyecto para construir un centro de datos para un proveedor importante. Soy responsable del F5 y Palo Alto en este proyecto. Desde el punto de vista de Cisco, es el "equipo de terceros".
Para mí personalmente, hay dos etapas distintas en este proyecto.
Primera etapa
El primer año estuve infinitamente ocupado, trabajaba de noche y los fines de semana. No pude levantar la cabeza. La presión de la gerencia y del cliente fue fuerte y continua. En una rutina constante, ni siquiera podía intentar optimizar el proceso. No fue solo y no tanto la configuración del equipo como la preparación de la documentación de diseño.
Entonces comenzaron las primeras pruebas, y me sorprendería cuántos errores menores e inexactitudes se hicieron. Por supuesto, todo funcionó, pero faltaba una letra en el nombre, faltaba una línea en el equipo ... Las pruebas continuaron y continuaron, y ya estaba en una lucha constante y diaria con errores, pruebas y documentación.
Esto continuó por un año. El proyecto, según tengo entendido, no fue fácil para todos, pero gradualmente el cliente se sintió cada vez más satisfecho, y esto hizo posible contratar ingenieros adicionales que pudieron asumir parte de la rutina.
Ahora era posible mirar un poco alrededor.
Y ese fue el comienzo de la segunda etapa.
Segunda etapa
Decidí automatizar el proceso.
Lo que entendí de la comunicación con los desarrolladores en ese momento (y debemos rendir homenaje, teníamos un equipo sólido) es que el formato de texto, aunque a primera vista parece algo del mundo del sistema operativo DOS, tiene una serie de propiedades valiosas .
Por ejemplo, un formato de texto será útil si desea aprovechar al máximo GIT y todos sus derivados. Yo queria
Bueno, parece que puede almacenar una configuración o una lista de comandos, pero hacer cambios es bastante inconveniente. Además, al diseñar, hay otra tarea importante. Debe tener documentación que describa su diseño general (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 ser una opción muy adecuada.
Entonces, cuando se usa YAML y Jinja2, el archivo YAML con parámetros de configuración, como direcciones IP, números BGP AS, ... cumple perfectamente el rol de NIP, mientras que las plantillas Jinja2 incluyen la sintaxis apropiada para el diseño, que es, de hecho, un reflejo de LLD.
Tomó dos días aprender los idiomas YAML y Jinja2. Algunos buenos ejemplos son suficientes para entender cómo funciona esto. Luego, tomó aproximadamente dos semanas crear todas las plantillas que se ajustan a 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 fue el siguiente:
- archivo yaml cambiado
- 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
- archivo YAML cambiado o 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 ya era más probable que fuera una rareza.
Una buena prueba y la capacidad de depurar todo fue el deseo del cliente de cambiar la convención de nomenclatura. Quien trabajó con F5 comprende lo picante de la situación. Pero para mí fue bastante simple. Cambié los nombres en el archivo YAML, eliminé toda la configuración del equipo, generé una nueva y la cargué. Todo, teniendo en cuenta las correcciones de errores, tomó 4 días: dos días para cada tecnología. Después de eso, estaba listo para el siguiente paso, es decir, la creación de centros de datos DEV y Staging.
Dev y puesta en escena
La puesta en escena en realidad repite la producción por completo. Dev es una copia muy simplificada construida principalmente en hardware virtual. Situación ideal para un nuevo enfoque. Si aíslo el tiempo que pasé del proceso general, creo que el trabajo no tomó más de 2 semanas. El tiempo principal es el tiempo de espera del otro lado y una búsqueda conjunta de problemas. La implementación de la tercera parte fue casi invisible para los demás. Incluso hubo tiempo para enseñar algo y escribir un par de artículos sobre Habré :)
Para resumir
Entonces, ¿qué tengo en la línea de fondo?
- todo lo que necesito para cambiar la configuración es modificar un archivo YAML simple, claramente estructurado con parámetros de configuración. Nunca cambio el script de Python y muy raramente (solo si hay un error) cambio Jinja2
- desde el punto de vista de la documentación, se obtiene una situación casi ideal. Cambia la documentación (los archivos YAML actúan como NIP) y carga esta configuración en el equipo. Por lo tanto, su documentación siempre está actualizada.
Todo esto llevó al hecho de que
- el porcentaje de errores disminuyó a casi 0
- tomó el 90 por ciento de la rutina
- la velocidad de implementación ha aumentado significativamente
PAGAR, F5Y, ACY
Dije que algunos ejemplos son suficientes para entender cómo funciona esto.
Aquí hay una versión breve (y, por supuesto, modificada) de lo que se creó en el proceso de mi trabajo.
PAY = despliegue
P alo
A lto de
Y aml = Palo Alto de Yaml
F5Y = despliegue
F5 desde
Y aml =
F5 desde
Y aml (próximamente)
ACY = despliegue
AC i desde
Y aml =
F5 desde
Y aml
Agregaré algunas palabras sobre ACY (que no debe confundirse con ACI).
Los que trabajaron con ACI saben que este milagro (y en el buen sentido, también) fue creado no por los networkers :). Olvídese de todo lo que sabía sobre la red: ¡no será útil para usted!
Es un poco exagerado, pero transmite aproximadamente la sensación que constantemente experimento durante 3 años, trabajando con ACI.
Y en este caso, ACY no es solo una oportunidad para construir un proceso de control de cambios (que es especialmente importante en el caso de ACI, porque se supone que esta es la parte central y más crítica de su centro de datos), sino que también le brinda una interfaz amigable para crear una configuración.
Los ingenieros en este proyecto usan Excel para usar ACI en lugar de YAML para exactamente el mismo propósito. Hay algunas ventajas de usar Excel, por supuesto:
- su pellizco en un archivo
- hermosas señales de que el cliente se complace en mirar
- puedes usar algunas herramientas de Excel
Pero hay un inconveniente y, en mi opinión, supera a los profesionales. Controlar los cambios y coordinar el trabajo en equipo se vuelve mucho más difícil.
ACY en realidad está aplicando los mismos enfoques que utilicé para terceros para configurar ACI.