Este artigo é o sexto da serie "Como tomar o control da túa infraestrutura de rede". Pódense atopar os contidos de todos os artigos da serie e as ligazóns .
Despois de deixar atrás varios temas, decidín comezar un novo capítulo.
Volverei á seguridade un pouco máis tarde. Aquí quero discutir un enfoque sinxelo pero eficaz, que estou seguro, dunha forma ou outra, pode ser útil para moitos. Esta é máis unha pequena historia sobre como a automatización pode cambiar a vida dun enxeñeiro. Falaremos do uso de modelos. Ao final hai unha lista dos meus proxectos onde podes ver como funciona todo o que aquí se describe.
DevOps para a rede
Crear unha configuración cun script, usar GIT para controlar os cambios na infraestrutura de TI, "carga" remota: estas ideas veñen primeiro cando pensas na implementación técnica do enfoque DevOps. As vantaxes son evidentes. Pero, por desgraza, tamén hai desvantaxes.
Cando hai máis de 5 anos, os nosos desenvolvedores chegaron a nós, os networkers, con estas propostas, non estabamos encantados.
Debo dicir que herdamos unha rede bastante variada, formada por equipos duns 10 provedores diferentes. Era conveniente configurar algunhas cousas a través do noso cli favorito, pero noutras preferimos usar a GUI. Ademais, un longo traballo en equipos "en directo" ensinounos a controlar en tempo real. Por exemplo, ao facer cambios, síntome moito máis cómodo traballando directamente a través do cli. Deste xeito, podo ver rapidamente que algo saíu mal e retrotraer os cambios. Todo isto estaba en certa contradición coas súas ideas.
Tamén xorden outras preguntas, por exemplo, a interface pode cambiar lixeiramente dunha versión a outra do software. Isto eventualmente fará que o teu script cree a "configuración" incorrecta. Non me gustaría usar a produción para "correr".
Ou, como entender que os comandos de configuración foron aplicados correctamente e que facer en caso de erro?
Non quero dicir que todas estas cuestións sexan irresolubles. Só dicir "A" probablemente teña sentido dicir "B" tamén, e se queres usar os mesmos procesos para o control de cambios que no desenvolvemento, entón tes que ter ambientes de desenvolvemento e de posta en escena ademais da produción. Entón, este enfoque parece completo. Pero canto vai custar?
Pero hai unha situación na que as desvantaxes están practicamente niveladas e só quedan as vantaxes. Falo de traballos de deseño.
Proxecto
Durante os últimos dous anos estiven participando nun proxecto para construír un centro de datos para un gran provedor. Son o responsable de F5 e Palo Alto neste proxecto. Desde o punto de vista de Cisco, trátase dun “equipo de terceiros”.
Para min persoalmente, hai dúas etapas distintas neste proxecto.
Primeira etapa
O primeiro ano estiven interminablemente ocupado, traballaba noites e fins de semana. Non podía levantar a cabeza. A presión da dirección e do cliente foi forte e continua. Nunha rutina constante, nin sequera podía tentar optimizar o proceso. Non foi só e non tanto a configuración dos equipos como a elaboración da documentación de deseño.
Comezaron as primeiras probas, e sorprenderíame cantos pequenos erros e imprecisións se cometeron. Por suposto, todo funcionou, pero faltaba unha letra no nome, faltaba unha liña no comando... As probas foron e seguían, e eu xa estaba nunha loita constante e diaria con erros, probas e documentación. .
Isto continuou durante un ano. O proxecto, polo que entendo, non foi doado para todos, pero aos poucos o cliente quedou cada vez máis satisfeito, e iso permitiu contratar enxeñeiros adicionais que puidesen asumir eles mesmos parte da rutina.
Agora poderiamos mirar un pouco ao redor.
E este foi o comezo da segunda etapa.
Segunda etapa
Decidín automatizar o proceso.
O que entendín da miña comunicación cos desenvolvedores naquel momento (e hai que renderlle unha homenaxe, tiñamos un equipo forte) é que o formato de texto, aínda que a primeira vista parece algo do mundo do sistema operativo DOS, ten un número de propiedades valiosas.
Así, por exemplo, o formato de texto será útil se queres aproveitar ao máximo GIT e todos os seus derivados. E eu quería.
Ben, parece que pode simplemente almacenar unha configuración ou unha lista de comandos, pero facer cambios é bastante inconveniente. Ademais, hai outra tarefa importante durante o deseño. Debería ter documentación que describa o seu deseño no seu conxunto (Deseño de baixo nivel) e a súa implementación específica (Plan de implantación da rede). E neste caso, o uso de modelos parece unha opción moi axeitada.
Así, cando se usa YAML e Jinja2, un ficheiro YAML con parámetros de configuración como enderezos IP, números de BGP AS,... cumpre perfectamente o papel de NIP, mentres que os modelos Jinja2 inclúen a sintaxe correspondente ao deseño, é dicir, é esencialmente un reflexo de LLD.
Levou dous días aprender YAML e Jinja2. Algúns bos exemplos son suficientes para entender como funciona isto. Despois tardou unhas dúas semanas en crear todos os modelos que coincidían co noso deseño: unha semana para Palo Alto e outra para F5. Todo isto foi publicado en githab corporativo.
Agora o proceso de cambio quedou así:
- cambiou o ficheiro YAML
- creou un ficheiro de configuración usando un modelo (Jinja2)
- gardado nun repositorio remoto
- cargou a configuración creada no equipo
- Vin un erro
- cambiou o ficheiro YAML ou o modelo Jinja2
- creou un ficheiro de configuración usando un modelo (Jinja2)
- ...
Está claro que ao principio pasou moito tempo en edicións, pero despois dunha ou dúas semanas isto converteuse nunha rareza.
Unha boa proba e oportunidade para depurar todo foi o desexo do cliente de cambiar a convención de nomeamento. Os que traballaron con F5 entenden o picante da situación. Pero para min foi todo moi sinxelo. Modifiquei os nomes no ficheiro YAML, eliminei toda a configuración do equipo, xerei un novo e cargueino. Todo, incluídas as correccións de erros, levou 4 días: dous días para cada tecnoloxía. Despois diso, estaba preparado para a seguinte etapa, é dicir, a creación de centros de datos DEV e Staging.
Dev e posta en escena
A posta en escena en realidade replica completamente a produción. Dev é unha copia moi reducida construída principalmente en hardware virtual. Unha situación ideal para un novo enfoque. Se illo o tempo que pasei do proceso xeral, entón creo que o traballo non levou máis de 2 semanas. O momento principal é esperar polo outro lado e buscar problemas xuntos. A implantación de terceiros pasou case desapercibida para outros. Incluso houbo tempo para aprender algo e escribir un par de artigos sobre Habré :)
para resumir
Entón, que teño no fondo?
- Todo o que teño que facer para cambiar a configuración é cambiar un ficheiro YAML sinxelo e claramente estruturado con parámetros de configuración. Nunca cambio o script de Python e moi raramente (só se hai un erro) cambio o calor de Jinja2
- Dende o punto de vista da documentación, esta é unha situación case ideal. Cambias a documentación (os ficheiros YAML serven como NIP) e cargas esta configuración no equipo. Deste xeito, a súa documentación estará sempre actualizada
Todo isto levou a que
- a taxa de erro baixou a case 0
- O 90 por cento da rutina desapareceu
- a velocidade de implementación aumentou significativamente
PAGO, F5Y, ACY
Dixen que son suficientes algúns exemplos para entender como funciona.
Aquí tes unha versión curta (e por suposto modificada) do que se creou durante o meu traballo.
= despregamento Palo Alto dende Yaml = Palo Alto de Yaml
= despregamento F5 de Yaml = F5 de Yaml (próximamente)
= despregamento ACeu de Yaml = F5 de Yaml
Vou engadir algunhas palabras sobre ACY (non confundir con ACI).
Os que traballaron con ACI saben que este milagre (e no bo sentido tamén) definitivamente non foi creado polos networkers :). Esquece todo o que sabías sobre a rede: non che será útil!
É un pouco esaxerado, pero transmite aproximadamente a sensación de que estiven experimentando constantemente, durante os últimos 3 anos, traballando con ACI.
E neste caso, ACY non só é unha oportunidade para construír un proceso de control de cambios (o que é especialmente importante no caso de ACI, porque se supón que é a parte central e máis crítica do teu centro de datos), senón que tamén che ofrece unha interface amigable para crear configuración.
Os enxeñeiros deste proxecto usan Excel para configurar ACI en lugar de YAML para exactamente os mesmos propósitos. Hai, por suposto, vantaxes ao usar Excel:
- o teu NIP nun ficheiro
- fermosos sinais que son agradables para o cliente
- pode usar algunhas ferramentas de Excel
Pero hai un inconveniente e, na miña opinión, supera os pros. Controlar os cambios e coordinar o traballo en equipo faise moito máis difícil.
ACY é en realidade unha aplicación dos mesmos enfoques que usei para o terceiro para configurar ACI.
Fonte: www.habr.com