El paradigma Infrastructure as Code se basa en la gestión y la provisión de la infraestructura a través de código en vez de utilizar procesos manuales. El estado de la infraestructura se almacena en ficheros que contienen la representación de su configuración. No es necesario que sea la configuración exacta, sino un modelo de datos que permita generar la configuración o el estado final de los equipos objetivo.
Utilizar este tipo de representación permite, entre otras cosas:
- Realizar un seguimiento sencillo de cambios en la infraestructura. Este tipo de seguimiento se puede realizar con un sistema de control de versiones, como puede ser git.
- Desplegar y replicar la configuración de forma sencilla en la red utilizando herramientas de automatización.
- Integrar la infraestructura en pipelines CI/CD (Continuous Integration/Continuous Delivery).
El concepto Infrastructure as Code nace con la explosión exponencial de los CPD. El número de equipos, físicos o virtuales, que era necesario gestionar se incrementó en órdenes de magnitud. La aproximación tradicional de configurar manualmente los equipos ya no era válida. Era fundamental poder automatizar los despliegues masivos y conocer el estado deseado en que debía estar cada uno de los servicios. La utilización del paradigma IaC permite almacenar esa información de estado para que luego las herramientas de automatización desplieguen o actualicen los servicios. Gracias al uso de automatización e IaC la gestión de grandes data center, con cientos o miles de servidores físicos y cientos de miles servidores virtuales se hizo asumible.
Este mismo paradigma se está intentando trasladar al mundo de las redes de comunicación. El objeto es poder aprovecharse de las ventajas que aporta como, por ejemplo:
- Reducción en el coste de operación, mantenimiento y despliegue: una provisión automatizada, determinista y simplificada tiene costes menores que la provisión manual.
- Aumento de la flexibilidad y rapidez en los despliegues.
- Configuraciones deterministas: La configuración que se despliega no se va a ver afectada nunca por errores humanos. Si hay un error en la configuración es determinista, y por lo tanto trazable para su corrección.
- Utilización de pipelines CI/CD para probar la nueva configuración antes de su despliegue.
- Información de la configuración de la red trazable y editable de forma sencilla.
Pero la implantación de este paradigma en redes de comunicaciones se encuentra con retos bastante complicados:
- Heterogeneidad de equipamiento de red: cada fabricante tiene una forma diferente de configurar su equipamiento, e incluso dentro de un mismo fabricante puede haber modelos con diferente forma de configurarse (Véase Cisco con IOS, IOS-XR, NX-OS).
- Funcionalidades propietarias: aunque todos los fabricantes dicen que abogan por estándares casi todos tienden a realizar “mejoras” propietarias.
- Escasez de documentación: muchas redes no están documentadas; otras tienen documentación, pero completamente desactualizada; otras la tienen fragmentada y no indexada, por lo que encontrar la información adecuada es bastante complicado.
- Plantillas: en muchas redes no hay plantillas oficiales de configuración, por lo que el despliegue de un nuevo servicio suele seguir el modelo “copia de otro sitio donde funcione”, lo que conlleva una “deriva” en las configuraciones que se aplican en red.
- Modelo de operación: en caso de que se produzcan problemas en la red se aplica la configuración necesaria para resolver el problema y restaurar el servicio. Este tipo de configuraciones no siempre se revierten a una configuración estándar y casi nunca se documentan.
- Falta de conocimiento: aunque la automatización en las redes lleve dando vueltas años la norma es el desconocimiento de estás técnicas tanto en departamentos de ingeniería como de operaciones de red.
Vamos a obviar las complicaciones operativas de implantar un modelo Network Infrastructure as Code para centrarnos en las técnicas.
El primer y más importante escollo es cómo representar nuestra configuración como código. Aquí tenemos dos modelos claros:
- Declarativo: con esta aproximación nuestra configuración define cómo queremos que se comporte el equipo de red, cuál es el estado deseado (necesito una adyacencia ISIS en la interfaz Ethernet0).
- Imperativo: en este modelo se guardan los comandos exactos que se deben aplicar y en qué orden en el equipo objetivo.
El modelo imperativo es bastante simple, y puede solucionar nuestro problema a corto plazo. Pero no es útil a medio o largo plazo. No es independiente de fabricante, ya que cada uno tiene su propia línea de comandos.
El modelo declarativo también presenta sus problemas en los equipos de red. En estos equipos el orden en que se aplican los comandos es muchas veces fundamental, y un orden diferente de aplicación puede conllevar pérdida de servicio o de gestión.
Lo óptimo sería utilizar un modelo declarativo, pero que la automatización que vuelca la información en red sea capaz de discernir si algunos comandos se tienen que ejecutar antes que otros. Con las herramientas actuales de automatización esta aproximación no debería ser ningún problema. En este punto es necesario disponer de una abstracción que nos permita modelar la configuración de un equipo independientemente del fabricante al que pertenezca.
El lenguaje de modelado dominante, y que se utiliza con protocolos de gestión de red como NETCONF, es YANG (Yet Another Next Generation). Este lenguaje permite modelar la configuración de un equipo utilizando ficheros YAML, JSON o XML. Existen modelos YANG estándar que pueden utilizar casi todos los fabricantes. Aparte, cada fabricante define modelos propios para poder modelar sus particularidades.
Y es que el problema de conseguir una abstracción completa no está en las configuraciones sencillas, como aplicar una dirección IP a una interfaz, sino en las estructuras complejas como las políticas de routing. La forma en que se implementan estas políticas en cada fabricante es bastante diferente, pero en todas ellas se suelen utilizar varios objetos de configuración para definir esas políticas:
- Objetos para filtrar por prefijo.
- Diversos objetos para filtrar por atributos BGP.
- Etc…
Modelar de forma declarativa una política de routing no es sencillo. Que esta política se pueda abstraer de fabricante para poder volcarla en uno u otro es más complejo todavía. Pero este escollo se puede salvar con una buena definición del modelo de datos y de las plantillas de configuración. Estas plantillas permitirían que con una misma entrada (los datos) se generen configuraciones dependientes de tipo de equipo.
Una vez que vemos que es factible, aunque con esfuerzo, el modelado de la red, hay que ver cómo obtener los datos del estado actual de la red. En un green field no sería un problema, ya que el modelado sería previo a la implantación de la red. Pero el caso habitual no es precisamente ése. Hay equipos que permitirán la exportación de su configuración en formato YANG, pero no son todos. Para el resto sería necesario procesar la configuración para generar el modelo de datos. Existen herramientas que son capaces de analizar las configuraciones de algunos fabricantes y modelar su configuración (como napalm). Para aquellos fabricantes para los que no sea posible será necesario implementar un analizador de configuraciones para poder extraer los datos al modelo común.
Esta información obtenida es la que se guardará en el sistema de control de versiones, y la que se utilizará para desplegar configuración en la red. A partir de ese momento se debe considerar que esa información representa la Single Source of Truth, la fuente única de la verdad. Esto conlleva implicaciones en cómo se opera la red:
- A partir de este momento todos los cambios de red se deben realizar a partir de cambios en los ficheros de configuración de nuestro modelo de datos.
- Estos cambios se despliegan en red a través de las automatizaciones pertinentes.
- No se deben realizar cambios en la red de forma manual, ya que esto podría provocar una deriva en las configuraciones.
Mantener la fuente única de la verdad es fundamental en el paradigma IaC, ya que de otro modo es inviable la gestión de la infraestructura si hay discrepancias entre los datos almacenados en ella y la configuración real de red.
Por los motivos anteriores, establecer de forma completa el paradigma IaC en una infraestructura compleja de comunicaciones es prácticamente una quimera hoy en día. Sí es completamente posible en infraestructuras orientadas a SDN, como ACI de Cisco, que incluso tiene un acuerdo con Hashicorp, empresa líder en IaC con su herramienta Terraform. En este tipo de redes hay elementos centralizados (controladores) que conocen el estado completo de la red y tienen APIs que permiten una fácil interacción con ellos.
Entonces, ¿es posible utilizar el paradigma IaC en redes complejas de comunicaciones? La respuesta es que cambiar completamente el modelo de operación es muy complejo, pero sí es factible avanzar hacia él. La estrategia para implantar el IaC en redes de comunicaciones pasaría por seleccionar parte de la configuración para incluirlos dentro del paradigma. Las primeras partes que se pueden incluir, y que son un quick win real son aquellas relacionadas con la gestión del equipamiento:
- Configuración de SNMP
- Configuración de NTP
- Configuración de SYSLOG
- Configuración de acceso al propio equipamiento
- Etc..
Este tipo de configuración suele ser común a todos los equipos, y centralizar esta información para que la red esté siempre en el estado deseado es relativamente fácil de conseguir. A partir de ahí se pueden ir añadiendo otras partes de la configuración a nuestra infraestructura IaC, tales como:
- Configuración de interfaces troncales de red: el número de estas interfaces suele ser reducido, y su configuración más o menos homogénea.
- Políticas de calidad de servicio: éstas se suelen definir una vez y luego se aplican por tipo de interfaz.
- Políticas comunes de routing: cuando se estandarizan servicios se suelen definir políticas reutilizables por todos los clientes de un mismo servicio. Estas políticas se pueden modificar con el tiempo para adecuarse a nuevas características del servicio. Si estas políticas están dentro de nuestra infraestructura IaC el despliegue a toda la red de la modificación es trivial.
- Etc…
La última parte que se podría añadir a la infraestructura IaC en una red ya desplegada sería los clientes conectados a la misma. Esta es la parte que contienen mayor variabilidad y que además suele estar ligada a otros sistemas, como puede ser el propio CRM de una operadora. Conseguir tener esta información en la IaC permitiría simplificar dos de los procesos más abandonados de una operadora:
- Bajas de servicio: es común que en muchas redes de operadora queden restos de configuración de servicios que se han dado de baja. Bajo un modelo de IaC declarativo, al dar de baja el servicio en la fuente única de verdad los automatismos borrarían la configuración asociada.
- Modificaciones de servicio: no es raro que las modificaciones de un servicio existente se tramiten como bajas y altas, ya que suele ser más sencillo realizar este proceso que no las modificaciones. Si el modelo IaC es declarativo los automatismos se encargarán de realizar estas modificaciones.
Como conclusión, la implantación completa del paradigma IaC en una red de comunicaciones tradicional es muy compleja, pero sí que es posible aprovecharse de este paradigma para simplificar muchas de las operaciones que se realizan en red. De hecho, es una tendencia estudiar la posible aplicación de este modelo en las redes de operadora.
