Mir starten eise Blog mat Publikatiounen op Basis vun de leschte Rieden vun eisem techneschen Direkter (Dmitry Stolyarov). All vun hinnen sinn am Joer 2016 bei verschiddene berufflechen Eventer stattfonnt a waren dem Thema DevOps an Docker gewidmet. Ee Video vun der Docker Moskau Reunioun am Badoo Büro, hu mir schonn Online. Neier wäerte vun Artikelen begleet ginn, déi d'Essenz vun de Berichter vermëttelen. Also…
31. Mee op der Konferenz , am Kader vum Festival "Russian Internet Technologies" (RIT ++ 2016) ofgehalen, huet d'Sektioun "Continuous Deployment and Deployment" mam Bericht "Best Practices of Continuous Delivery with Docker" opgemaach. Et huet déi bescht Praktiken zesummegefaasst a systematiséiert fir e Continuous Delivery (CD) Prozess mat Docker an aner Open Source Produkter ze bauen. Mir schaffen mat dëse Léisungen an der Produktioun, wat eis erlaabt op praktesch Erfahrung ze vertrauen.
Wann Dir d'Méiglechkeet hutt eng Stonn ze verbréngen , Mir recommandéieren et voll ze kucken. Soss, hei ënnen ass den Haaptresumé an Textform.
Kontinuéierlech Liwwerung mat Docker
By Kontinuéierlech Liwwerung mir verstinn d'Kette vun Eventer als Resultat vun deem den Applikatiounscode vum Git Repository fir d'éischt an d'Produktioun kënnt, an dann am Archiv endet. Si gesäit esou aus: Git → Build → Test → Fräisetzung → Operéieren.
De gréissten Deel vum Bericht ass fir d'Baustadium gewidmet (Uwendungsversammlung), an d'Themen Verëffentlechung an Operatioun gi kuerz beréiert. Mir schwätzen iwwer Probleemer a Musteren déi Iech erlaben se ze léisen, an déi spezifesch Implementatioune vun dëse Mustere kënnen ënnerschiddlech sinn.
Firwat gëtt Docker iwwerhaapt hei gebraucht? Et ass net fir näischt datt mir beschloss hunn iwwer Continuous Delivery Praktiken am Kontext vun dësem Open Source Tool ze schwätzen. Och wann de ganze Bericht fir seng Notzung gewidmet ass, gi vill Grënn opgedeckt wann Dir d'Haaptmuster vun der Ausrollung vun der Applikatiounscode berücksichtegt.
Main Rollout Muster
Also, wa mir nei Versioune vun der Applikatioun ausrollen, si mir sécherlech konfrontéiert Downtime Problem, entsteet während dem Wiessel vum Produktiounsserver. Traffic vun der aler Versioun vun der Applikatioun op déi nei kann net direkt wiesselen: als éischt musse mir sécher sinn datt déi nei Versioun net nëmmen erfollegräich erofgeluede gëtt, awer och "opgewiermt" (dh komplett prett fir Ufroen ze déngen).
Also fir eng Zäit wäerte béid Versioune vun der Applikatioun (al an nei) gläichzäiteg funktionnéieren. Wat automatesch féiert zu gemeinsame Ressource Konflikt: Netzwierk, Dateisystem, IPC, etc. Mat Docker gëtt dëse Problem einfach geléist andeems verschidde Versioune vun der Applikatioun an getrennten Container lafen, fir déi Ressourcenisolatioun am selwechte Host (Server / virtuell Maschinn) garantéiert ass. Natierlech kënnt Dir mat e puer Tricken ouni Isolatioun iwwerhaapt kommen, awer wann et e fäerdegt a praktescht Tool ass, da gëtt et de Géigendeel Grond - net ze vernoléissegen.
Containeriséierung bitt vill aner Virdeeler wann se ofgesat ginn. All Applikatioun hänkt dovun of spezifesch Versioun (oder Versioun Gamme) Dolmetscher, Disponibilitéit vu Moduler / Extensiounen, etc., souwéi hir Versiounen. An dat gëllt net nëmme fir dat direkt ausféierbar Ëmfeld, mee och fir dat ganzt Ëmfeld, inklusiv System Software a seng Versioun (bis zur Linux Verdeelung benotzt). Wéinst der Tatsaach, datt Container net nëmmen Applikatioun Code enthalen, mä och Pre-installéiert System an Applikatioun Software vun der néideg Versiounen, kënnt Dir iwwer Problemer mat Ofhängegkeet vergiessen.
Resumé Haaptrollmuster nei Versiounen déi folgend Faktoren berücksichtegen:
- Am Ufank leeft déi al Versioun vun der Applikatioun am éischte Container.
- Déi nei Versioun gëtt dann ausgerullt an an engem zweete Container "opgewiermt". Et ass bemierkenswäert datt dës nei Versioun selwer net nëmmen den aktualiséierten Applikatiounscode kann droen, awer och all seng Ofhängegkeeten, souwéi Systemkomponenten (zum Beispill eng nei Versioun vun OpenSSL oder déi ganz Verdeelung).
- Wann déi nei Versioun komplett prett ass fir Ufroen ze déngen, wiesselt de Verkéier vum éischte Container op den zweeten.
- Déi al Versioun kann elo gestoppt ginn.
Dës Approche fir verschidde Versioune vun der Applikatioun an getrennten Container z'installéieren bitt eng aner Komfort - séier Réckroll op déi al Versioun (schliisslech ass et genuch fir de Verkéier op de gewënschten Container ze wiesselen).
Déi lescht éischt Empfehlung kléngt wéi eppes mat deem och de Kapitän kee Feeler konnt fannen: "[wann Dir Kontinuéierlech Liwwerung mat Docker organiséiert] Benotzt Docker [a verstinn wat et gëtt]" Denkt drun, dëst ass net eng Sëlwerkugel déi all Problem léist, awer e Tool dat e wonnerschéine Fundament gëtt.
Reproducibilitéit
Mat "Reproducibilitéit" bedeite mir e generaliséierte Set vu Probleemer déi bei der Operatioun vun Uwendungen opgetruede sinn. Mir schwätzen iwwer esou Fäll:
- Skripte, déi vum Qualitéitsdepartement fir d'Inszenéierung gepréift ginn, musse präzis an der Produktioun reproduzéiert ginn.
- Uwendungen ginn op Serveren publizéiert, déi Pakete vu verschiddene Repositoryspigelen kréien (mat der Zäit gi se aktualiséiert, a mat hinnen d'Versioune vun installéierten Uwendungen).
- "Alles funktionnéiert fir mech lokal!" (...an Entwéckler sinn net an d'Produktioun erlaabt.)
- Dir musst eppes an der aler (archivéierter) Versioun kontrolléieren.
- ...
Hir allgemeng Essenz dréit op d'Tatsaach, datt voll Konformitéit vun den Ëmfeld benotzt (wéi och d'Feele vum mënschleche Faktor) néideg ass. Wéi kënne mir Reproduktioun garantéieren? Maacht Docker Biller baséiert op Code vum Git, a benotzt se dann fir all Aufgab: op Testplazen, an der Produktioun, op lokalen Maschinnen vu Programméierer ... Zur selwechter Zäit ass et wichteg d'Aktiounen ze minimiséieren déi ausgefouert ginn после d'Bild montéieren: wat et méi einfach ass, wat manner wahrscheinlech et Feeler gëtt.
Infrastruktur ass Code
Wann d'Infrastruktur Ufuerderunge (Disponibilitéit vun Server Software, seng Versioun, etc.) sinn net formaliséiert an "programméiert", da kann d'Rollout vun all Applikatioun Aktualiséierung opgetrueden zu katastrofal Konsequenzen. Zum Beispill, an der Inszenéierung hutt Dir schonn op PHP 7.0 gewiesselt an de Code deementspriechend nei geschriwwen - da wäert seng Erscheinung an der Produktioun mat e puer alen PHP (5.5) sécherlech een iwwerraschen. Dir kënnt net iwwer eng grouss Ännerung an der Dolmetscher Versioun vergiessen, awer "den Däiwel ass an den Detailer": d'Iwwerraschung kann an engem klengen Update vun all Ofhängegkeet sinn.
Eng Approche fir dëse Problem ze léisen ass bekannt als IaC (Infrastruktur als Code, "Infrastruktur als Code") a beinhalt d'Späichere vun Infrastrukturfuerderunge zesumme mam Applikatiounscode. Benotzt et, Entwéckler an DevOps Spezialisten kënne mam selwechte Git Applikatiounsrepository schaffen, awer op verschiddenen Deeler dovun. Vun dësem Code gëtt e Docker-Bild am Git erstallt, an deem d'Applikatioun ofgebaut gëtt andeems Dir all d'Spezifizitéite vun der Infrastruktur berücksichtegt. Einfach gesot, d'Skripte (Reegelen) fir d'Biller ze sammelen sollten am selwechte Repository mam Quellcode sinn a fusionéiert sinn.
Am Fall vun enger Multi-Layer Applikatiounsarchitektur - zum Beispill gëtt et nginx, déi virun enger Applikatioun steet déi schonn an engem Docker Container leeft - Docker Biller mussen aus Code am Git fir all Layer erstallt ginn. Dann enthält dat éischt Bild eng Applikatioun mat engem Dolmetscher an aner "no" Ofhängegkeeten, an dat zweet Bild enthält den Upstream nginx.
Docker Biller, Kommunikatioun mam Git
Mir trennen all Docker Biller gesammelt vu Git an zwou Kategorien: temporär a Verëffentlechung. Temporär Biller markéiert mam Numm vun der Branche am Git, kënne vum nächste Verpflichtung iwwerschriwwe ginn a ginn nëmme fir Virschau ausgerullt (net fir d'Produktioun). Dëst ass hire Schlësselunterscheed vu Verëffentlechungen: Dir wësst ni wéi eng spezifesch Verpflichtung an hinnen ass.
Et mécht Sënn fir temporär Biller ze sammelen: d'Meeschterzweig (Dir kënnt automatesch op eng separat Säit ausrollen fir stänneg déi aktuell Versioun vum Master ze gesinn), Filialen mat Verëffentlechungen, Branchen vu spezifesche Innovatiounen.
Nodeems d'Virschau vun temporäre Biller op d'Bedierfnes fir Iwwersetzung an d'Produktioun kënnt, hunn d'Entwéckler e gewëssen Tag gesat. Automatesch duerch Tag gesammelt Fräisetzung Bild (säi Tag entsprécht dem Tag vum Git) a gëtt op d'Staging ausgerullt. Wann et erfollegräich vun der Qualitéit Departement verifizéiert ass, geet et zu Produktioun.
Dapp
Alles beschriwwen (Rollout, Bildmontage, spéider Ënnerhalt) kann onofhängeg mat Bash Scripten an aner "improviséiert" Tools ëmgesat ginn. Awer wann Dir dëst maacht, da wäert d'Ëmsetzung iergendwann zu grousser Komplexitéit a schlechter Kontrollbarkeet féieren. Dëst ze verstoen, si mir komm fir eisen eegene spezialiséierte Workflow Utility ze kreéieren fir CI / CD ze bauen - Dapp.
Säi Quellcode ass a Rubin geschriwwen, Open Source a publizéiert op . Leider ass d'Dokumentatioun momentan de schwaachste Punkt vum Tool, awer mir schaffen drun. A mir wäerte méi wéi eemol iwwer den Dapp schreiwen a schwätzen, well ... Mir kënnen éierlech net waarden fir seng Fäegkeeten mat der ganzer interesséierter Gemeinschaft ze deelen, awer an der Tëschenzäit, schéckt Är Themen an zitt Ufroen an / oder verfollegt d'Entwécklung vum Projet op GitHub.
Aktualiséiert August 13, 2019: aktuell e Projet Dapp ëmbenannt zu , säi Code gouf am Go komplett nei geschriwwe ginn, a seng Dokumentatioun gouf wesentlech verbessert.
Kubernetes
En anert fäerdeg Open Source Tool dat scho bedeitend Unerkennung am professionelle Ëmfeld kritt huet ass Kubernetes, en Docker Management Cluster. D'Thema vu senger Notzung an der Operatioun vu Projeten, déi op Docker gebaut sinn, ass iwwer den Ëmfang vum Bericht, sou datt d'Presentatioun limitéiert ass op en Iwwerbléck iwwer e puer interessant Features.
Fir Ausrollung bitt Kubernetes:
- Bereetschaft Sonde - Iwwerpréiwung vun der Bereetschaft vun enger neier Versioun vun der Applikatioun (fir de Verkéier ze wiesselen);
- Rolling Update - sequenziell Bildaktualiséierung an engem Cluster vu Container (Shutdown, Update, Virbereedung fir Start, Traffic Switching);
- Synchron-Aktualiséierung - d'Aktualiséierung vun engem Bild an engem Cluster mat enger anerer Approche: éischt op d'Halschent vun de Container, dann op de Rescht;
- Kanaresch Verëffentlechungen - lancéiert en neit Bild op enger limitéierter (kleng) Unzuel vu Container fir Anomalien ze iwwerwaachen.
Well Continuous Delivery net nëmmen d'Verëffentlechung vun enger neier Versioun ass, huet Kubernetes eng Rei vu Fäegkeeten fir spéider Infrastrukturenhaltung: agebaute Iwwerwaachung a Logbuch fir all Container, automatesch Skaléieren, asw.. All dëst funktionnéiert scho a waart just op richteg. Ëmsetzung an Äre Prozesser.
Finale Recommandatiounen
- Benotzt Docker.
- Erstellt Docker Biller vun Uwendungen fir all Är Bedierfnesser.
- Follegt de Prinzip "Infrastruktur ass Code."
- Link Git zu Docker.
- Regelt d'Uerdnung vun der Ausrollung.
- Benotzt eng fäerdeg Plattform (Kubernetes oder eng aner).
Videoen a Rutschen
Video vun der Leeschtung (ongeféier eng Stonn) (de Bericht selwer fänkt vun der 5. Minutt un - befollegt de Link fir ab dësem Moment ze spillen).
Presentatioun vum Rapport:
PS
Aner Berichter zum Thema op eisem Blog:
- «» (Dmitry Stolyarov; Mee 27, 2019 bei DevOpsConf);
- «» (Dmitry Stolyarov; 8. November 2018 op HighLoad++);
- «» (Dmitry Stolyarov; 7. November 2017 op HighLoad++);
- «» (Dmitry Stolyarov; Juni 6, 2017 bei RootConf).
Source: will.com