{"id":34742,"date":"2019-10-31T22:00:10","date_gmt":"2019-10-31T19:00:10","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-chetvertaya-avtomatizatsiya-templejty\/"},"modified":"2019-10-31T22:00:10","modified_gmt":"2019-10-31T19:00:10","slug":"kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-chetvertaya-avtomatizatsiya-templejty","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-chetvertaya-avtomatizatsiya-templejty","title":{"rendered":"C\u00f3mo tomar el control de la infraestructura de red. Cap\u00edtulo Cuarto. Automatizaci\u00f3n. Plantillas","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Este art\u00edculo es el sexto de una serie titulada \u00abC\u00f3mo tomar el control de la infraestructura de red\u00bb. Puedes encontrar el contenido de todos los art\u00edculos de la serie y los enlaces. aqu\u00ed<\/a><\/noindex><\/i>.<\/p>\n

Dejando atr\u00e1s algunos temas, decid\u00ed comenzar un nuevo cap\u00edtulo.<\/p>\n

Volver\u00e9 a la seguridad un poco m\u00e1s adelante. Aqu\u00ed quiero discutir un enfoque simple pero efectivo que, estoy seguro, puede ser \u00fatil para muchos en una forma u otra. Es m\u00e1s bien una breve historia sobre c\u00f3mo la automatizaci\u00f3n puede cambiar la vida de un ingeniero. Se tratar\u00e1 del uso de plantillas. Al final, se incluye una lista de mis proyectos donde se puede ver c\u00f3mo funciona todo lo que se describe aqu\u00ed.<\/p>\n

DevOps para redes<\/h2>\n

\nCrear configuraciones mediante scripts, usar GIT para el control de cambios de la infraestructura IT, la \u00abcarga\u00bb remota: estas ideas vienen a la mente cuando se piensa en la implementaci\u00f3n t\u00e9cnica del enfoque DevOps. Las ventajas son evidentes. Pero, desafortunadamente, tambi\u00e9n hay desventajas.<\/p>\n

Cuando hace m\u00e1s de 5 a\u00f1os, nuestros desarrolladores vinieron a nosotros, a los administradores de red, con estas propuestas, no est\u00e1bamos entusiasmados.
\n<\/a><\/noindex>
\nCabe mencionar que heredamos una red bastante heterog\u00e9nea, compuesta por equipos de aproximadamente 10 proveedores diferentes. Algunas cosas eran f\u00e1ciles de configurar a trav\u00e9s de nuestra CLI favorita, pero en otros casos prefer\u00edamos usar GUI. Adem\u00e1s, la larga experiencia con equipos \u00aben vivo\u00bb nos acostumbr\u00f3 al control en tiempo real. Por ejemplo, al hacer cambios, me siento mucho m\u00e1s c\u00f3modo trabajando directamente a trav\u00e9s de CLI. As\u00ed puedo ver r\u00e1pidamente si algo sali\u00f3 mal y \u00abrevertir\u00bb los cambios. Todo esto estaba un poco en contradicci\u00f3n con sus ideas.<\/p>\n

Tambi\u00e9n surgen otras preguntas, como que de una versi\u00f3n de software a otra la interfaz puede cambiar un poco. Esto, al final, llevar\u00e1 a que tu script genere una \u00abconfiguraci\u00f3n\u00bb incorrecta. No querr\u00eda usar producci\u00f3n para \u00abpruebas\u00bb. <\/p>\n

O, \u00bfc\u00f3mo entender que los comandos de configuraci\u00f3n se aplicaron correctamente y qu\u00e9 hacer en caso de error?<\/p>\n

No quiero decir que todas estas preguntas sean irresolubles. Simplemente, al decir \u00abA\u00bb, seguramente es razonable decir tambi\u00e9n \u00abB\u00bb y, si deseas usar los mismos procesos para el control de cambios que en desarrollo, deber\u00edas tener, adem\u00e1s de producci\u00f3n, entornos de desarrollo y pruebas. Entonces, este enfoque se ver\u00eda completo. Pero, \u00bfcu\u00e1nto costar\u00e1 esto?<\/p>\n

Pero hay una situaci\u00f3n en la que las desventajas se minimizan casi por completo y solo quedan ventajas. Estoy hablando de trabajos de proyectos.<\/p>\n

Proyecto<\/h2>\n

\nDurante los \u00faltimos dos a\u00f1os 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'.<\/p>\n

Personalmente, hay dos etapas claramente definidas en este proyecto. <\/p>\n

Primera etapa<\/h3>\n

\nEl primer a\u00f1o estuve incre\u00edblemente ocupado, trabaj\u00e9 por las noches y los fines de semana. No pod\u00eda levantar la vista. La presi\u00f3n del equipo directivo y del cliente era fuerte y continua. En la rutina constante, no pod\u00eda ni siquiera intentar optimizar el proceso. No se trataba solo de configurar el equipo, sino de elaborar la documentaci\u00f3n del proyecto. <\/p>\n

As\u00ed comenzaron las primeras pruebas, y me sorprendi\u00f3 cu\u00e1ntos peque\u00f1os errores e imprecisiones se hab\u00edan cometido. Por supuesto, todo funcionaba, pero faltaba una letra en el nombre, aqu\u00ed faltaba una l\u00ednea en el comando... Las pruebas continuaron y yo ya estaba inmerso en una lucha diaria constante con errores, pruebas y documentaci\u00f3n. <\/p>\n

As\u00ed continu\u00f3 durante un a\u00f1o. El proyecto, seg\u00fan entiendo, no fue f\u00e1cil para nadie, pero poco a poco el cliente se volvi\u00f3 cada vez m\u00e1s satisfecho, y esto nos permiti\u00f3 contratar ingenieros adicionales que pudieron asumir parte de la rutina.<\/p>\n

Ahora se pod\u00eda mirar a nuestro alrededor.
\nY este fue el comienzo de la segunda etapa. <\/p>\n

Segunda etapa<\/h3>\n

\nDecid\u00ed automatizar el proceso.<\/p>\n

Lo que entend\u00ed de mi comunicaci\u00f3n con los desarrolladores en aquel entonces (y hay que dar cr\u00e9dito, ten\u00edamos 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.
\nPor ejemplo, el formato de texto ser\u00e1 \u00fatil si desea aprovechar al m\u00e1ximo las ventajas de GIT y todos sus derivados. Y yo quer\u00eda. <\/p>\n

Bueno, parecer\u00eda que uno podr\u00eda simplemente almacenar la configuraci\u00f3n o la lista de comandos, pero hacer modificaciones resulta bastante inc\u00f3modo. Adem\u00e1s, al dise\u00f1ar existe otra tarea importante. Debe tener documentaci\u00f3n que describa su dise\u00f1o en general (Low Level Design) y la implementaci\u00f3n espec\u00edfica (Network Implementation Plan). Y en este caso, el uso de plantillas parece ser una opci\u00f3n muy adecuada.<\/p>\n

As\u00ed, al usar YAML y Jinja2, el archivo YAML con par\u00e1metros de configuraci\u00f3n, como direcciones IP, n\u00fameros BGP AS,\u2026 cumple un excelente papel como NIP, mientras que las plantillas de Jinja2 incluyen una sintaxis correspondiente al dise\u00f1o, es decir, son un reflejo del LLD. <\/p>\n

El estudio de los lenguajes YAML y Jinja2 llev\u00f3 dos d\u00edas. Para entender c\u00f3mo funciona, son suficientes algunos buenos ejemplos. Luego, pas\u00e9 alrededor de dos semanas creando todas las plantillas correspondientes a nuestro dise\u00f1o: una semana para Palo Alto y otra semana para F5. Todo esto se public\u00f3 en el githab corporativo.<\/p>\n

Ahora el proceso de cambios se ve\u00eda de la siguiente manera:<\/p>\n