Comezaremos o noso blog con publicacións baseadas nos últimos discursos do noso director técnico (Dmitry Stolyarov). Todos eles tiveron lugar en 2016 en diversos eventos profesionais e estiveron dedicados ao tema de DevOps e Docker. Xa temos un vídeo da reunión de Docker Moscow na oficina de Badoo En liña. As novas irán acompañadas de artigos que transmitan a esencia dos informes. Entón…
31 de maio na conferencia , celebrado no marco do festival "Tecnoloxías de Internet rusas" (RIT++ 2016), abriuse a sección "Implementación e implantación continua" co informe "Best Practices of Continuous Delivery with Docker". Resumiu e sistematizou as mellores prácticas para construír un proceso de entrega continua (CD) mediante Docker e outros produtos de código aberto. Traballamos con estas solucións en produción, o que nos permite confiar na experiencia práctica.
Se tes a oportunidade de pasar unha hora , recomendamos velo completo. En caso contrario, a continuación móstrase o resumo principal en forma de texto.
Entrega continua con Docker
En Entrega continua entendemos a cadea de eventos como resultado da cal o código da aplicación do repositorio de Git chega primeiro á produción e despois remata no arquivo. Parece así: Git → Construír → Probar → Lanzamento → Operar.
A maior parte do informe dedícase á fase de compilación (montaxe da aplicación) e tócanse brevemente os temas liberación e funcionamento. Falaremos de problemas e patróns que permiten resolvelos, e as implementacións específicas destes patróns poden ser diferentes.
Por que se necesita Docker aquí? Non por nada decidimos falar de prácticas de entrega continua no contexto desta ferramenta de código aberto. Aínda que todo o informe está dedicado ao seu uso, revélanse moitas razóns cando se considera o patrón principal de lanzamento do código da aplicación.
Patrón de lanzamento principal
Entón, cando lanzamos novas versións da aplicación, certamente estamos ante problema de tempo de inactividade, xerado durante a conmutación do servidor de produción. O tráfico da versión antiga da aplicación á nova non pode cambiar ao instante: primeiro debemos asegurarnos de que a nova versión non só se descargue correctamente, senón que tamén se "quece" (é dicir, que está completamente lista para atender solicitudes).
Así, durante algún tempo ambas as versións da aplicación (vella e nova) funcionarán simultaneamente. O que leva automaticamente a conflito de recursos compartidos: rede, sistema de ficheiros, IPC, etc. Con Docker, este problema resólvese facilmente executando diferentes versións da aplicación en contedores separados, para o que se garante o illamento dos recursos dentro do mesmo host (servidor/máquina virtual). Por suposto, podes facerte con algúns trucos sen illamento, pero se hai unha ferramenta preparada e conveniente, hai a razón contraria: non descoidala.
A contenerización ofrece moitos outros beneficios cando se implanta. Calquera aplicación depende de versión específica (ou rango de versións) intérprete, dispoñibilidade de módulos/extensións, etc., así como as súas versións. E isto aplícase non só ao contorno executable inmediato, senón tamén a todo o ambiente, incluído software do sistema e a súa versión (ata a distribución Linux utilizada). Debido ao feito de que os contedores conteñen non só código de aplicación, senón tamén sistema preinstalado e software de aplicación das versións requiridas, pode esquecerse dos problemas coas dependencias.
Xeneralicemos patrón de lanzamento principal novas versións tendo en conta os seguintes factores:
- Ao principio, a versión antiga da aplicación execútase no primeiro contedor.
- A nova versión lánzase e "quenta" nun segundo recipiente. Cabe destacar que esta nova versión en si pode levar non só o código da aplicación actualizado, senón tamén calquera das súas dependencias, así como os compoñentes do sistema (por exemplo, unha nova versión de OpenSSL ou toda a distribución).
- Cando a nova versión está totalmente lista para atender solicitudes, o tráfico cambia do primeiro contedor ao segundo.
- Agora pódese deter a versión antiga.
Este enfoque de implementar diferentes versións da aplicación en contedores separados proporciona outra comodidade: retroceso rápido á versión antiga (despois de todo, abonda con cambiar o tráfico ao contedor desexado).
A primeira recomendación final soa como algo que nin o capitán puido atopar: "[ao organizar a entrega continua con Docker] Usa Docker [e entende o que dá]" Lembre, esta non é unha bala de prata que resolverá todos os problemas, senón unha ferramenta que proporciona unha base marabillosa.
Reproducibilidade
Por "reproducibilidade" entendemos un conxunto xeneralizado de problemas que se atopan ao operar aplicacións. Estamos a falar de casos deste tipo:
- Os guións verificados polo departamento de calidade para a posta en escena deben reproducirse con precisión na produción.
- As aplicacións publícanse en servidores que poden recibir paquetes de diferentes espellos de repositorio (co tempo vanse actualizando, e con eles as versións das aplicacións instaladas).
- "Todo me funciona a nivel local!" (...e os desenvolvedores non poden entrar en produción.)
- Debe comprobar algo na versión antiga (arquivada).
- ...
A súa esencia xeral redúcese no feito de que é necesario o cumprimento total dos ambientes utilizados (así como a ausencia do factor humano). Como podemos garantir a reproducibilidade? Fai imaxes de Docker baseado no código de Git, e despois utilízaos para calquera tarefa: en sitios de proba, en produción, en máquinas locais de programadores... Ao mesmo tempo, é importante minimizar as accións que se realizan. despois montaxe da imaxe: canto máis sinxela sexa, menos probable que haxa erros.
A infraestrutura é código
Se os requisitos de infraestrutura (dispoñibilidade do software do servidor, a súa versión, etc.) non están formalizados e "programados", a posta en marcha de calquera actualización da aplicación pode ter consecuencias desastrosas. Por exemplo, na posta en escena xa cambiou a PHP 7.0 e reescribiu o código en consecuencia; entón a súa aparición en produción con algún PHP antigo (5.5) certamente sorprenderá a alguén. Quizais non se esqueza dun cambio importante na versión do intérprete, pero "o demo está nos detalles": a sorpresa pode estar nunha pequena actualización de calquera dependencia.
Un enfoque para resolver este problema coñécese como IaC (Infraestrutura como código, "infraestrutura como código") e implica almacenar os requisitos de infraestrutura xunto co código da aplicación. Usalo, os desenvolvedores e especialistas en DevOps poden traballar co mesmo repositorio de aplicacións Git, pero en diferentes partes del. A partir deste código, créase unha imaxe de Docker en Git, na que se desprega a aplicación tendo en conta todas as especificidades da infraestrutura. En pocas palabras, os scripts (regras) para ensamblar imaxes deberían estar no mesmo repositorio co código fonte e combinados.
No caso dunha arquitectura de aplicacións de varias capas, por exemplo, hai nginx, que está diante dunha aplicación que xa se está a executar dentro dun contedor Docker, as imaxes de Docker deben crearse a partir de código en Git para cada capa. A continuación, a primeira imaxe conterá unha aplicación cun intérprete e outras dependencias "pechadas", e a segunda imaxe conterá o nginx ascendente.
Imaxes de Docker, comunicación con Git
Dividimos todas as imaxes de Docker recollidas de Git en dúas categorías: temporais e de liberación. Imaxes temporais etiquetado polo nome da rama en Git, pódese sobrescribir no seguinte commit e só se lanza para a vista previa (non para a produción). Esta é a súa diferenza fundamental coas versións: nunca se sabe que compromiso específico hai neles.
Ten sentido recoller en imaxes temporais: a rama mestra (pode lanzala automaticamente a un sitio separado para ver constantemente a versión actual do mestra), ramas con lanzamentos, ramas de innovacións específicas.
Despois de que a vista previa das imaxes temporais chega á necesidade de tradución para a produción, os desenvolvedores poñen unha determinada etiqueta. Recollido automaticamente por etiqueta liberar imaxe (a súa etiqueta corresponde á etiqueta de Git) e desenvólvese na posta en escena. Se o departamento de calidade o verifica con éxito, pasa á produción.
papá
Todo o descrito (lanzamento, montaxe de imaxes, mantemento posterior) pódese implementar de forma independente usando scripts Bash e outras ferramentas "improvisadas". Pero se fai isto, nalgún momento a implementación levará a unha gran complexidade e unha mala controlabilidade. Entendendo isto, creamos a nosa propia utilidade de fluxo de traballo especializada para crear CI/CD. papá.
O seu código fonte está escrito en Ruby, código aberto e publicado en . Desafortunadamente, a documentación é actualmente o punto máis débil da ferramenta, pero estamos traballando nela. E escribiremos e falaremos máis dunha vez da dapp, porque... Sinceramente, non podemos esperar a compartir as súas capacidades con toda a comunidade interesada, pero mentres tanto, envía os teus problemas e solicitudes e/ou segue o desenvolvemento do proxecto en GitHub.
Actualizado o 13 de agosto de 2019: actualmente un proxecto papá renomeado a , o seu código foi completamente reescrito en Go e a súa documentación mellorouse significativamente.
Kubernetes
Outra ferramenta de código aberto preparada e que xa recibiu un importante recoñecemento no ámbito profesional é Kubernetes,un clúster de xestión de Docker. O tema do seu uso no funcionamento de proxectos construídos en Docker está fóra do alcance do informe, polo que a presentación limítase a unha visión xeral dalgunhas características interesantes.
Para o lanzamento, Kubernetes ofrece:
- Readiness probe — comprobar a preparación dunha nova versión da aplicación (para cambiar o tráfico a ela);
- actualización continua: actualización secuencial de imaxes nun grupo de contedores (apagamento, actualización, preparación para o lanzamento, cambio de tráfico);
- actualización sincrónica: actualización dunha imaxe nun clúster cun enfoque diferente: primeiro na metade dos contedores, despois no resto;
- lanzamentos canarios: lanzamento dunha nova imaxe nun número limitado (pequeno) de contedores para controlar as anomalías.
Dado que Continuous Delivery non é só o lanzamento dunha nova versión, Kubernetes dispón dunha serie de capacidades para o mantemento posterior da infraestrutura: seguimento e rexistro integrados de todos os contedores, escalado automático, etc. Todo isto xa está funcionando e só está á espera do correcto. implementación en sus procesos.
Recomendacións finais
- Usa Docker.
- Crea imaxes de aplicacións Docker para todas as túas necesidades.
- Siga o principio "A infraestrutura é código".
- Vincular Git a Docker.
- Regular a orde de lanzamento.
- Use unha plataforma preparada (Kubernetes ou outra).
Vídeos e diapositivas
Vídeo da actuación (aproximadamente unha hora) (o informe en si comeza a partir do minuto 5 - siga a ligazón para xogar a partir deste momento).
Presentación do informe:
PS
Outras reportaxes sobre o tema no noso blog:
- «» (Dmitry Stolyarov; 27 de maio de 2019 en DevOpsConf);
- «» (Dmitry Stolyarov; 8 de novembro de 2018 en HighLoad++);
- «» (Dmitry Stolyarov; 7 de novembro de 2017 en HighLoad++);
- «» (Dmitry Stolyarov; 6 de xuño de 2017 en RootConf).
Fonte: www.habr.com