O enfoque IaC (Infraestrutura como Código) consiste non só no código que se almacena no repositorio, senón tamén polas persoas e procesos que rodean a este código. É posible reutilizar enfoques desde o desenvolvemento de software ata a xestión e descrición da infraestrutura? Sería unha boa idea ter presente esta idea mentres le o artigo.

Versión en inglés

Esta é unha transcrición miña actuacións en DevopsConf 2019-05-28.

Presentacións e vídeos

• Versión en inglés
• Versión rusa
• Carreira en seco 2019-04-24 SpbLUG
• Vídeo (RU) de DevopsConf 2019-05-28
• Vídeo (RU) de DINS DevOps EVENING 2019-06-20
• Diapositivas

A infraestrutura como historia de bash

Supoña que chegas a un novo proxecto, e che din: “temos A infraestrutura como código". En realidade resulta A infraestrutura como historia de bash ou por exemplo Documentación como historial de bash. Esta é unha situación moi real, por exemplo, un caso similar foi descrito por Denis Lysenko nun discurso Como substituír toda a infraestrutura e comezar a durmir tranquilo, contou como conseguiron unha infraestrutura coherente para o proxecto da historia de bash.

Con certas ganas, podemos dicir iso A infraestrutura como historia de bash isto é como o código:

1. reproducibilidade: Podes levar o historial de bash, executar os comandos desde alí e, por certo, podes obter unha configuración de traballo como saída.
2. versionado: xa sabes quen entrou e o que fixeron, de novo, non é un feito que isto o leve a unha configuración de traballo na saída.
3. historia: a historia de quen fixo que. só que non poderás usalo se perdes o servidor.

¿Que facer?

A infraestrutura como código

Mesmo un caso tan estraño como A infraestrutura como historia de bash podes tiralo polas orellas A infraestrutura como código, pero cando queremos facer algo máis complicado que o bo e vello servidor LAMP, chegaremos á conclusión de que este código debe ser modificado, cambiado, mellorado dalgún xeito. A continuación, gustaríanos considerar os paralelismos entre A infraestrutura como código e desenvolvemento de software.

SECO

Nun proxecto de desenvolvemento de sistemas de almacenamento, houbo unha subtarefa configurar periódicamente SDS: estamos lanzando un novo lanzamento; hai que lanzarlo para probas posteriores. A tarefa é moi sinxela:

• inicia sesión aquí mediante ssh e executa o comando.
• copia alí o ficheiro.
• corrixa a configuración aquí.
• iniciar o servizo alí
• ...
• BENEFICIO!

Para a lóxica descrita, bash é máis que suficiente, especialmente nas primeiras fases do proxecto, cando está a comezar. Isto non está mal que uses bash, pero co paso do tempo hai solicitudes para despregar algo semellante, pero lixeiramente diferente. O primeiro que se me ocorre é copiar e pegar. E agora xa temos dous guións moi parecidos que fan case o mesmo. Co paso do tempo, o número de scripts creceu, e atopámonos co feito de que existe unha certa lóxica empresarial para a implantación dunha instalación que debe sincronizarse entre diferentes scripts, isto é bastante complicado.

Resulta que existe unha práctica como DRY (Non Repeat Yourself). A idea é reutilizar o código existente. Parece sinxelo, pero non chegamos a isto de inmediato. No noso caso, foi unha idea banal: separar as configuracións dos scripts. Eses. lóxica empresarial de como a instalación se desprega por separado, as configuracións por separado.

SÓLIDO para CFM

Co paso do tempo o proxecto foi medrando e continuación natural foi a aparición de Ansible. O principal motivo da súa aparición é que hai experiencia no equipo e que bash non está deseñado para unha lóxica complexa. Ansible tamén comezou a conter lóxica complexa. Para evitar que a lóxica complexa se converta en caos, existen principios para organizar o código no desenvolvemento de software SÓLIDO Tamén, por exemplo, Grigory Petrov no informe "Por que un especialista en TI necesita unha marca persoal" levantou a pregunta de que unha persoa está deseñada de tal xeito que lle sexa máis fácil operar con algunhas entidades sociais, no desenvolvemento de software estes son obxectos. Se combinamos estas dúas ideas e seguimos desenvolvéndoas, notaremos que tamén podemos utilizalas SÓLIDO para facilitar o mantemento e modificación desta lóxica no futuro.

O Principio de Responsabilidade Única

Cada clase realiza só unha tarefa.

Non hai necesidade de mesturar código e facer monstros de espagueti divinos monolíticos. A infraestrutura debe consistir en ladrillos simples. Acontece que se divide o libro de xogos de Ansible en pequenos anacos, le os roles de Ansible, entón son máis fáciles de manter.

O Principio Aberto Pechado

Principio aberto/pechado.

• Aberto á extensión: significa que o comportamento dunha entidade pode ampliarse creando novos tipos de entidades.
• Pechado ao cambio: como resultado da ampliación do comportamento dunha entidade, non se deben facer cambios no código que utiliza esas entidades.

Inicialmente, implantamos a infraestrutura de proba en máquinas virtuais, pero debido ao feito de que a lóxica empresarial de implantación estaba separada da implementación, engadimos a implementación a baremetall sen ningún problema.

O principio de substitución de Liskov

Principio de substitución de Barbara Liskov. os obxectos dun programa deben ser substituíbles por instancias dos seus subtipos sen cambiar a correcta execución do programa

Se o miras de xeito máis amplo, non é unha característica de ningún proxecto en particular que se poida aplicar alí SÓLIDO, xeralmente trátase de CFM, por exemplo, noutro proxecto é necesario despregar unha aplicación Java en caixa encima de varios Java, servidores de aplicacións, bases de datos, SO, etc. Usando este exemplo, vou considerar máis principios SÓLIDO

No noso caso, existe un acordo dentro do equipo de infraestrutura de que se instalamos o rol imbjava ou oraclejava, entón temos un executable binario java. Isto é necesario porque Os roles upstream dependen deste comportamento; esperan java. Ao mesmo tempo, isto permítenos substituír unha implementación/versión de Java por outra sen cambiar a lóxica de implantación da aplicación.

O problema aquí radica en que é imposible implementar isto en Ansible, polo que aparecen algúns acordos dentro do equipo.

Principio de segregación de interfaces

Principio de separación de interfaces: "Moitas interfaces específicas do cliente son mellores que unha interface de propósito xeral.

Inicialmente, tentamos poñer toda a variabilidade da implementación de aplicacións nun libro de xogos de Ansible, pero foi difícil de soportar, e o enfoque cando temos unha interface externa especificada (o cliente espera o porto 443), entón pódese montar unha infraestrutura a partir de ladrillos para unha implementación específica.

Principio de inversión de dependencia

O principio de inversión de dependencia. Os módulos de niveis superiores non deben depender dos módulos de niveis inferiores. Ambos tipos de módulos deben depender de abstraccións. As abstraccións non deben depender dos detalles. Os detalles deben depender das abstraccións.

Aquí o exemplo estará baseado nun antipatrón.

1. Un dos clientes tiña unha nube privada.
2. Pedimos máquinas virtuais dentro da nube.
3. Pero debido á natureza da nube, a implantación de aplicacións estivo ligada a que hipervisor estaba a máquina virtual.

Eses. A lóxica de despregamento de aplicacións de alto nivel fluía con dependencias a niveis inferiores do hipervisor, e isto supuxo problemas ao reutilizar esta lóxica. Non o fagas deste xeito.

Interacción

A infraestrutura como código non é só sobre o código, senón tamén sobre a relación entre o código e as persoas, sobre as interaccións entre os desenvolvedores de infraestruturas.

Factor autobús

Supoñamos que tes Vasya no teu proxecto. Vasya sabe todo sobre a túa infraestrutura, que pasará se Vasya desaparece de súpeto? Esta é unha situación moi real, porque podería ser atropelado por un autobús. Ás veces ocorre. Se isto ocorre e o coñecemento sobre o código, a súa estrutura, como funciona, as aparencias e os contrasinais non se distribúe entre o equipo, entón podes atopar unha serie de situacións desagradables. Para minimizar estes riscos e distribuír o coñecemento dentro do equipo, pode utilizar varios enfoques

Par Devopsing

Non é como como broma, que os administradores beberon cervexa, cambiaron contrasinais e un análogo da programación de parellas. Eses. dous enxeñeiros sentan nun ordenador, nun teclado e comezan a configurar a súa infraestrutura xuntos: configurar un servidor, escribir un rol de Ansible, etc. Parece ben, pero non funcionou para nós. Pero casos especiais desta práctica funcionaron. Chega un novo empregado, o seu mentor asume unha tarefa real xunto con el, traballa e transfire coñecementos.

Outro caso especial é unha chamada de incidente. Durante un problema, reúnense un grupo de persoas de servizo e implicados, noméase un líder, que comparte a súa pantalla e expresa o tren do pensamento. Outros participantes seguen os pensamentos do líder, espían trucos da consola, comproban que non perderon ningunha liña no rexistro e aprenden cousas novas sobre o sistema. Este enfoque funcionou a maioría das veces.

Revisión do código

Subxectivamente, foi máis eficaz difundir o coñecemento sobre a infraestrutura e o seu funcionamento mediante a revisión de código:

• A infraestrutura descríbese mediante código no repositorio.
• Os cambios ocorren nunha rama separada.
• Durante unha solicitude de combinación, podes ver o delta de cambios na infraestrutura.

O máis destacado aquí foi que os revisores foron seleccionados un por un, segundo un calendario, é dicir. con certo grao de probabilidade subirás a unha nova peza de infraestrutura.

Estilo de código

Co paso do tempo, as disputas comezaron a aparecer durante as revisións, porque... os revisores tiñan o seu propio estilo e a rotación de revisores apiláronos con estilos diferentes: 2 espazos ou 4, camelCase ou snake_case. Non foi posible implementar isto de inmediato.

• A primeira idea foi recomendar o uso de linter, despois de todo, todos son enxeñeiros, todos son intelixentes. Pero os diferentes editores, OS, non son convenientes
• Isto evolucionou nun bot que escribía a slack para cada compromiso problemático e anexaba a saída de linter. Pero na maioría dos casos había cousas máis importantes que facer e o código permaneceu sen arranxar.

Mestre de construción verde

Pasa o tempo e chegamos á conclusión de que non se poden admitir no máster os compromisos que non superan certas probas. Voila! Inventamos Green Build Master, que se practica no desenvolvemento de software durante moito tempo:

• O desenvolvemento está en marcha nunha rama separada.
• Estase a executar probas neste fío.
• Se as probas fallan, o código non pasará ao mestre.

Tomar esta decisión foi moi doloroso, porque... causou moita polémica, pero pagou a pena, porque... As opinións comezaron a recibir solicitudes de fusión sen diferenzas de estilo e co paso do tempo o número de áreas problemáticas comezou a diminuír.

Probas IaC

Ademais da comprobación de estilo, podes usar outras cousas, por exemplo, para comprobar que a túa infraestrutura se pode implementar. Ou comprobar que os cambios na infraestrutura non levarán a perda de diñeiro. Por que pode ser necesario isto? A pregunta é complexa e filosófica, é mellor responder cunha historia de que, dalgún xeito, había un escalador automático en Powershell que non comprobou as condicións de límite => creáronse máis máquinas virtuales das necesarias => o cliente gastou máis diñeiro do previsto. Isto non é moi agradable, pero sería moi posible detectar este erro en etapas anteriores.

Poderíase preguntar, por que facer unha infraestrutura complexa aínda máis complexa? As probas para a infraestrutura, igual que para o código, non se tratan de simplificar, senón de saber como debería funcionar a túa infraestrutura.

Pirámide de proba de IaC

Probas IaC: Análise Estática

Se implementas toda a infraestrutura á vez e comprobas que funciona, podes descubrir que leva moito tempo e require moito tempo. Polo tanto, a base debe ser algo que funcione rapidamente, hai moito e abrangue moitos lugares primitivos.

Bash é complicado

Vexamos un exemplo trivial. seleccione todos os ficheiros do directorio actual e cópiese noutro lugar. O primeiro que se me ocorre:

for i in * ; do 
    cp $i /some/path/$i.bak
done

E se hai un espazo no nome do ficheiro? Ben, ok, somos intelixentes, sabemos como usar comiñas:

for i in * ; do cp "$i" "/some/path/$i.bak" ; done

Ben feito? Non! E se non hai nada no directorio, é dicir. globbing non funcionará.

find . -type f -exec mv -v {} dst/{}.bak ;

Ben feito agora? Non... Esquecín o que pode haber no nome do ficheiro n.

touch x
mv x  "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dir

Ferramentas de análise estática

O problema do paso anterior podería detectarse cando esquecemos as comiñas, para iso hai moitos remedios na natureza Shellcheck, en xeral hai moitos deles, e moi probablemente podes atopar un linter para a túa pila no teu IDE.

Lingua
Ferramenta

bater
Shellcheck

Rubio
RuboCop

python
Pilinto

ansible
Ansible Lint

Probas IaC: Probas unitarias

Como vimos no exemplo anterior, os linters non son omnipotentes e non poden sinalar todas as áreas problemáticas. Ademais, por analoxía coas probas no desenvolvemento de software, podemos recordar probas unitarias. O que se me ocorre inmediatamente é shunit, xunit, rspec, pytest. Pero que facer con ansible, chef, saltstack e outros semellantes?

Xa ao principio falamos SÓLIDO e que a nosa infraestrutura debería estar formada por pequenos ladrillos. Chegou o seu momento.

1. A infraestrutura está dividida en pequenos ladrillos, por exemplo, roles Ansible.
2. Implígase algún tipo de ambiente, xa sexa docker ou unha máquina virtual.
3. Aplicamos o noso rol de Ansible a este ambiente de proba.
4. Comprobamos que todo funcionou como esperabamos (facemos probas).
5. Decidimos ben ou non.

Testing IaC: ferramentas de proba unitaria

Pregunta, que son as probas para CFM? Podes simplemente executar o script ou usar solucións preparadas para iso:

CFM
Ferramenta

Ansible
Testinfra

Xefe
Inspeccionar

Xefe
Especificación do servidor

pila de sal
Goss

Exemplo para testinfra, comprobando que os usuarios test1, test2 existen e están nun grupo sshusers:

def test_default_users(host):
    users = ['test1', 'test2' ]
    for login in users:
        assert host.user(login).exists
        assert 'sshusers' in host.user(login).groups

Que escoller? A pregunta é complexa e ambigua, aquí tes un exemplo de cambios nos proxectos en github para 2018-2019:

Marcos de proba de IaC

Xorde a pregunta: como xuntalo todo e lanzalo? Pode tómao e faino ti mesmo se hai un número suficiente de enxeñeiros. Ou podes tomar solucións preparadas, aínda que non hai moitas:

CFM
Ferramenta

Ansible
Molécula

Xefe
Cociña de proba

Terraform
Terratest

Exemplo de cambios nos proxectos en github para 2018-2019:

Molécula vs. Cociña de probas

Inicialmente nós intentou usar testkitchen:

1. Crear unha máquina virtual en paralelo.
2. Aplicar roles de Ansible.
3. Realizar a inspección.

Para 25-35 papeis funcionou 40-70 minutos, o que foi longo.

O seguinte paso foi a transición a jenkins/docker/ansible/molecule. Idioloxicamente todo é igual

1. Libros de xogos de pelusa.
2. Aliñar os papeis.
3. Lanzamento do contedor
4. Aplicar roles de Ansible.
5. Executar testenfra.
6. Comprobar a idempotencia.

A realización de 40 papeis e as probas para unha ducia comezaron a levar uns 15 minutos.

O que escoller depende de moitos factores, como a pila utilizada, a experiencia no equipo, etc. aquí cada un decide por si mesmo como pechar a pregunta da proba unitaria

Probas IaC: Probas de integración

O seguinte paso na pirámide de probas de infraestruturas serán as probas de integración. Son similares ás probas unitarias:

1. A infraestrutura divídese en pequenos ladrillos, por exemplo roles Ansible.
2. Implígase algún tipo de ambiente, xa sexa docker ou unha máquina virtual.
3. Para este ambiente de proba aplícase Conxunto de Papeis ansibles.
4. Comprobamos que todo funcionou como esperabamos (facemos probas).
5. Decidimos ben ou non.

En liñas xerais, non comprobamos o rendemento dun elemento individual do sistema como nas probas unitarias, comprobamos como está configurado o servidor no seu conxunto.

Probas de IaC: probas de extremo a extremo

Na parte superior da pirámide recíbenos probas End to End. Eses. Non comprobamos o rendemento dun servidor separado, dun script ou dun ladrillo separado da nosa infraestrutura. Comprobamos que moitos servidores están conectados entre si, a nosa infraestrutura funciona como esperamos. Desafortunadamente, nunca vin solucións preparadas en caixa, probablemente porque... A infraestrutura adoita ser única e difícil de modelar e crear un marco para probar. Como resultado, cada un crea as súas propias solucións. Hai unha demanda, pero non hai resposta. Por iso, vouvos contar o que hai para empurrar aos demais a pensar ou fregarme o nariz polo feito de que todo se inventou hai moito antes que nós.

Un proxecto cunha rica historia. Úsase en grandes organizacións e probablemente cada un de vostedes se cruzase indirectamente con el. A aplicación admite moitas bases de datos, integracións, etc. Coñecer como pode ser a infraestrutura é unha gran cantidade de ficheiros de composición docker e saber que probas executar en que ambiente está Jenkins.

Este esquema funcionou durante bastante tempo, ata dentro do marco investigación non tentamos transferir isto a Openshift. Os contedores seguen sendo os mesmos, pero o ambiente de lanzamento cambiou (ola DRY de novo).

A idea de investigación foi máis aló, e en turno aberto atoparon algo como APB (Ansible Playbook Bundle), que che permite acumular coñecementos sobre como implementar infraestrutura nun contedor. Eses. hai un punto de coñecemento repetible e comprobable sobre como implantar a infraestrutura.

Todo isto soaba ben ata que nos atopamos cunha infraestrutura heteroxénea: necesitabamos Windows para as probas. Como resultado, o coñecemento de que, onde, como implementar e probar está en jenkins.

Conclusión

A infraestrutura como é o código

• Código no repositorio.
• Interacción humana.
• Probas de infraestruturas.

Ligazóns

• Versión Inglés
• Publicación cruzada do blog persoal
• Carreira en seco 2019-04-24 SpbLUG
• Vídeo (RU) de DevopsConf 2019-05-28
• Vídeo (RU) de DINS DevOps EVENING 2019-06-20
• Leccións aprendidas ao escribir máis de 300,000 liñas de código de infraestrutura & versión de texto
• Integración da infraestrutura como código nunha canalización de entrega continua
• Probando a infraestrutura como código
• Desenvolvemento e mantemento efectivos dos roles de Ansible
• Ansible non é unha barbaridade!

Fonte: www.habr.com