Començarem el nostre blog amb publicacions basades en els últims discursos del nostre director tècnic (Dmitri Stolyarov). Tots ells van tenir lloc l'any 2016 en diferents esdeveniments professionals i van estar dedicats al tema de DevOps i Docker. Ja tenim un vídeo de la reunió de Docker Moscou a l'oficina de Badoo En línia. Els nous aniran acompanyats d'articles que transmetin l'essència dels informes. Tan…
31 de maig a la conferència , celebrat en el marc del festival "Russian Internet Technologies" (RIT++ 2016), la secció "Desplegament i desplegament continus" va obrir amb l'informe "Best Practices of Continuous Delivery with Docker". Va resumir i sistematitzar les millors pràctiques per crear un procés de lliurament continu (CD) mitjançant Docker i altres productes de codi obert. Treballem amb aquestes solucions en producció, la qual cosa ens permet confiar en l'experiència pràctica.
Si tens l'oportunitat de passar una hora , recomanem veure'l sencer. En cas contrari, a continuació es mostra el resum principal en forma de text.
Lliurament continu amb Docker
Sota lliurament continu entenem la cadena d'esdeveniments com a resultat dels quals el codi de l'aplicació del repositori Git arriba primer a la producció i després acaba a l'arxiu. Es veu així: Git → Construir → Prova → Alliberar → Operar.
La major part de l'informe es dedica a l'etapa de compilació (assemblatge de l'aplicació) i es toquen breument els temes de llançament i funcionament. Parlarem de problemes i patrons que permeten resoldre'ls, i les implementacions específiques d'aquests patrons poden ser diferents.
Per què es necessita Docker aquí? No és per res que hem decidit parlar de pràctiques de lliurament continu en el context d'aquesta eina de codi obert. Tot i que tot l'informe està dedicat al seu ús, es revelen moltes raons quan es considera el patró principal de desplegament del codi de l'aplicació.
Patró de desplegament principal
Per tant, quan publiquem noves versions de l'aplicació, sens dubte ens trobem davant problema d'inactivitat, generat durant la commutació del servidor de producció. El trànsit de l'antiga versió de l'aplicació a la nova no pot canviar a l'instant: primer hem d'assegurar-nos que la nova versió no només es descarrega correctament, sinó que també s'ha "escalfat" (és a dir, completament a punt per atendre les sol·licituds).
Així, durant algun temps les dues versions de l'aplicació (antiga i nova) funcionaran simultàniament. Que condueix automàticament a conflicte de recursos compartits: xarxa, sistema de fitxers, IPC, etc. Amb Docker, aquest problema es resol fàcilment executant diferents versions de l'aplicació en contenidors separats, per als quals l'aïllament dels recursos està garantit dins del mateix host (servidor/màquina virtual). Per descomptat, podeu fer-ho amb alguns trucs sense aïllament, però si hi ha una eina preparada i còmoda, hi ha la raó contrària: no descuidar-la.
La contenerització ofereix molts altres avantatges quan es desplega. Qualsevol aplicació depèn versió específica (o rang de versions) intèrpret, disponibilitat de mòduls/extensions, etc., així com les seves versions. I això s'aplica no només a l'entorn executable immediat, sinó també a tot l'entorn, inclòs programari del sistema i la seva versió (fins a la distribució Linux utilitzada). A causa del fet que els contenidors contenen no només codi d'aplicació, sinó també sistema preinstal·lat i programari d'aplicació de les versions requerides, podeu oblidar-vos dels problemes amb les dependències.
Resumim patró de desplegament principal noves versions tenint en compte els factors següents:
- Al principi, la versió antiga de l'aplicació s'executa al primer contenidor.
- A continuació, la nova versió es desplega i "s'escalfa" en un segon contenidor. Cal destacar que aquesta nova versió pot portar no només el codi d'aplicació actualitzat, sinó també qualsevol de les seves dependències, així com els components del sistema (per exemple, una nova versió d'OpenSSL o tota la distribució).
- Quan la nova versió està totalment preparada per atendre sol·licituds, el trànsit canvia del primer contenidor al segon.
- La versió antiga ara es pot aturar.
Aquest enfocament de desplegar diferents versions de l'aplicació en contenidors separats proporciona una altra comoditat: retrocés ràpid a la versió antiga (al cap i a la fi, n'hi ha prou amb canviar el trànsit al contenidor desitjat).
La primera recomanació final sona com una cosa a la qual ni tan sols el capità va trobar cap error: "[quan organitzeu el lliurament continu amb Docker] Utilitzeu Docker [i entendre el que dóna]" Recordeu que aquesta no és una bala de plata que resolgui tots els problemes, sinó una eina que proporciona una base meravellosa.
Reproductibilitat
Per "reproducibilitat" entenem un conjunt generalitzat de problemes que es troben en operar aplicacions. Estem parlant d'aquests casos:
- Els guions verificats pel departament de qualitat per a la posada en escena s'han de reproduir amb precisió en producció.
- Les aplicacions es publiquen en servidors que poden rebre paquets de diferents rèpliques de repositoris (amb el temps s'actualitzen, i amb elles les versions de les aplicacions instal·lades).
- "Tot em funciona a nivell local!" (...i els desenvolupadors no poden entrar en producció.)
- Heu de comprovar alguna cosa a la versió antiga (arxivada).
- ...
La seva essència general es redueix al fet que és necessari el compliment total dels entorns utilitzats (així com l'absència del factor humà). Com podem garantir la reproductibilitat? Feu imatges de Docker basat en codi de Git, i després utilitzar-los per a qualsevol tasca: en llocs de prova, en producció, en màquines locals de programadors... Al mateix temps, és important minimitzar les accions que es realitzen. després muntar la imatge: com més senzill és, menys probabilitats hi ha errors.
La infraestructura és codi
Si els requisits d'infraestructura (disponibilitat del programari del servidor, la seva versió, etc.) no estan formalitzats i "programats", el llançament de qualsevol actualització de l'aplicació pot tenir conseqüències desastroses. Per exemple, en la posada en escena ja heu canviat a PHP 7.0 i heu reescrit el codi en conseqüència; llavors, la seva aparició en producció amb algun PHP antic (5.5) sens dubte sorprendrà algú. Potser no us oblideu d'un canvi important en la versió de l'intèrpret, però “el diable està en els detalls”: la sorpresa pot estar en una petita actualització de qualsevol dependència.
Un enfocament per resoldre aquest problema es coneix com IaC (Infraestructura com a codi, "infraestructura com a codi") i implica emmagatzemar els requisits d'infraestructura juntament amb el codi de l'aplicació. Utilitzant-lo, els desenvolupadors i els especialistes de DevOps poden treballar amb el mateix repositori d'aplicacions Git, però en diferents parts del mateix. A partir d'aquest codi, es crea una imatge Docker a Git, en la qual es desplega l'aplicació tenint en compte totes les especificitats de la infraestructura. En poques paraules, els scripts (regles) per muntar imatges haurien d'estar al mateix dipòsit amb el codi font i fusionats.
En el cas d'una arquitectura d'aplicació multicapa, per exemple, hi ha nginx, que es troba davant d'una aplicació que ja s'executa dins d'un contenidor Docker, les imatges de Docker s'han de crear a partir del codi de Git per a cada capa. Aleshores, la primera imatge contindrà una aplicació amb un intèrpret i altres dependències "a prop", i la segona imatge contindrà el nginx amunt.
Imatges Docker, comunicació amb Git
Dividim totes les imatges de Docker recollides de Git en dues categories: temporals i de llançament. Imatges temporals etiquetat pel nom de la branca a Git, es pot sobreescriure per la següent confirmació i només es desplega per a la previsualització (no per a la producció). Aquesta és la seva diferència clau amb les de llançament: mai se sap quin commit específic hi ha.
Té sentit recollir-les en imatges temporals: la branca mestra (podeu desplegar-la automàticament a un lloc separat per veure constantment la versió actual de la mestra), branques amb llançaments, branques d'innovacions específiques.
Després que la vista prèvia de les imatges temporals arriba a la necessitat de traduir-les a la producció, els desenvolupadors posen una determinada etiqueta. Recollida automàticament per etiqueta alliberar imatge (la seva etiqueta correspon a l'etiqueta de Git) i es desplega a la posada en escena. Si és verificat amb èxit pel departament de qualitat, passa a producció.
dapp
Tot el que es descriu (lançament, muntatge d'imatges, manteniment posterior) es pot implementar de manera independent mitjançant scripts Bash i altres eines "improvisades". Però si ho feu, en algun moment la implementació comportarà una gran complexitat i una poca controlabilitat. Entenent-ho, vam crear la nostra pròpia utilitat de flux de treball especialitzada per crear CI/CD: dapp.
El seu codi font està escrit en Ruby, codi obert i publicat a . Malauradament, actualment la documentació és el punt més feble de l'eina, però hi estem treballant. I escriurem i parlarem de la dapp més d'una vegada, perquè... Sincerament, no podem esperar per compartir les seves capacitats amb tota la comunitat interessada, però mentrestant, envia els teus problemes i sol·licituds i/o segueix el desenvolupament del projecte a GitHub.
Actualitzat el 13 d'agost de 2019: actualment un projecte dapp rebatejat a , el seu codi s'ha reescrit completament a Go, i la seva documentació s'ha millorat significativament.
Kubernetes
Una altra eina de codi obert ja feta que ja ha rebut un important reconeixement en l'entorn professional és Kubernetes, un clúster de gestió de Docker. El tema del seu ús en el funcionament de projectes construïts a Docker està fora de l'abast de l'informe, per la qual cosa la presentació es limita a una visió general d'algunes característiques interessants.
Per al llançament, Kubernetes ofereix:
- sonda de preparació: comprovació de la disponibilitat d'una nova versió de l'aplicació (per canviar-hi trànsit);
- actualització continua: actualització seqüencial d'imatges en un grup de contenidors (apagada, actualització, preparació per al llançament, canvi de trànsit);
- actualització sincrònica: actualització d'una imatge en un clúster amb un enfocament diferent: primer a la meitat dels contenidors i després a la resta;
- llançaments canaris: llançament d'una nova imatge en un nombre limitat (petit) de contenidors per controlar les anomalies.
Com que Continuous Delivery no és només el llançament d'una nova versió, Kubernetes disposa d'una sèrie de capacitats per al manteniment posterior de la infraestructura: monitorització i registre integrats per a tots els contenidors, escalat automàtic, etc. Tot això ja està funcionant i només està esperant el correcte implementació en els vostres processos.
Recomanacions finals
- Utilitzeu Docker.
- Creeu imatges de Docker d'aplicacions per a totes les vostres necessitats.
- Seguiu el principi "La infraestructura és codi".
- Enllaça Git a Docker.
- Regular l'ordre de llançament.
- Utilitzeu una plataforma ja feta (Kubernetes o una altra).
Vídeos i diapositives
Vídeo de l'actuació (aproximadament una hora) (l'informe en si comença a partir del minut 5; seguiu l'enllaç per jugar a partir d'aquest moment).
Presentació de l'informe:
PS
Altres informes sobre el tema al nostre blog:
- «» (Dmitry Stolyarov; 27 de maig de 2019 a DevOpsConf);
- «» (Dmitry Stolyarov; 8 de novembre de 2018 a HighLoad++);
- «» (Dmitry Stolyarov; 7 de novembre de 2017 a HighLoad++);
- «» (Dmitry Stolyarov; 6 de juny de 2017 a RootConf).
Font: www.habr.com