We beginnen onze blog met publicaties gebaseerd op de laatste toespraken van onze technisch directeur (Dmitri Stolyarov). Ze vonden allemaal plaats in 2016 op verschillende professionele evenementen en waren gewijd aan het onderwerp DevOps en Docker. Eén video van de Docker Moskou-bijeenkomst op het Badoo-kantoor hebben we al Online. Nieuwe zullen vergezeld gaan van artikelen die de essentie van de rapporten overbrengen. Dus…
31 mei op de conferentie , gehouden als onderdeel van het festival “Russische Internet Technologieën” (RIT++ 2016), opende de sectie “Continuous Deployment and Deployment” met het rapport “Best Practices of Continuous Delivery with Docker”. Het vatte en systematiseerde de best practices samen voor het bouwen van een Continuous Delivery (CD)-proces met behulp van Docker en andere Open Source-producten. Wij werken met deze oplossingen in de productie, waardoor wij kunnen vertrouwen op praktijkervaring.
Als je de mogelijkheid hebt om een uurtje door te brengen , raden we aan om deze volledig te bekijken. Anders vindt u hieronder de hoofdsamenvatting in tekstvorm.
Continue levering met Docker
onder Continue levering we begrijpen de keten van gebeurtenissen waardoor de applicatiecode uit de Git-repository eerst in productie komt, en vervolgens in het archief terechtkomt. Ze ziet er zo uit: Git → Bouwen → Testen → Vrijgeven → Bedienen.
Het grootste deel van het rapport is gewijd aan de bouwfase (applicatie-assemblage), en de onderwerpen release en operate worden kort besproken. We zullen het hebben over problemen en patronen waarmee u ze kunt oplossen, en de specifieke implementaties van deze patronen kunnen verschillen.
Waarom is Docker hier überhaupt nodig? Het is niet voor niets dat we besloten om te praten over Continuous Delivery-praktijken in de context van deze Open Source-tool. Hoewel het hele rapport aan het gebruik ervan is gewijd, komen er veel redenen naar voren als we kijken naar het belangrijkste patroon van de uitrol van applicatiecode.
Belangrijkste uitrolpatroon
Wanneer we dus nieuwe versies van de applicatie uitrollen, worden we daar zeker mee geconfronteerd stilstand probleem, gegenereerd tijdens het schakelen van de productieserver. Verkeer van de oude versie van de applicatie naar de nieuwe kan niet onmiddellijk overschakelen: eerst moeten we ervoor zorgen dat de nieuwe versie niet alleen succesvol wordt gedownload, maar ook wordt "opgewarmd" (d.w.z. volledig klaar om verzoeken te verwerken).
Beide versies van de applicatie (oude en nieuwe) zullen dus enige tijd gelijktijdig werken. Wat automatisch leidt tot conflict over gedeelde bronnen: netwerk, bestandssysteem, IPC, enz. Met Docker is dit probleem eenvoudig op te lossen door verschillende versies van de applicatie in aparte containers te draaien, waarbij resource-isolatie binnen dezelfde host (server/virtuele machine) gegarandeerd is. Natuurlijk kun je met wat trucjes rondkomen zonder isolatie, maar als er een kant-en-klaar en handig hulpmiddel is, dan is er de tegenovergestelde reden: om het niet te verwaarlozen.
Containerisatie biedt bij implementatie nog veel meer voordelen. Elke toepassing is afhankelijk van specifieke versie (of versiebereik) tolk, beschikbaarheid van modules/uitbreidingen, enz., evenals hun versies. En dit geldt niet alleen voor de onmiddellijke uitvoerbare omgeving, maar ook voor de gehele omgeving, inclusief systeem software en de versie ervan (tot aan de gebruikte Linux-distributie). Omdat containers niet alleen applicatiecode bevatten, maar ook vooraf geïnstalleerde systeem- en applicatiesoftware van de vereiste versies, kunt u problemen met afhankelijkheden vergeten.
Laten we het samenvatten belangrijkste uitrolpatroon nieuwe versies waarbij rekening wordt gehouden met de volgende factoren:
- In eerste instantie draait de oude versie van de applicatie in de eerste container.
- Vervolgens wordt de nieuwe versie uitgerold en “opgewarmd” in een tweede container. Het is opmerkelijk dat deze nieuwe versie zelf niet alleen bijgewerkte applicatiecode kan bevatten, maar ook alle afhankelijkheden ervan, evenals systeemcomponenten (bijvoorbeeld een nieuwe versie van OpenSSL of de volledige distributie).
- Wanneer de nieuwe versie volledig klaar is om verzoeken te verwerken, schakelt het verkeer over van de eerste container naar de tweede.
- De oude versie kan nu worden gestopt.
Deze aanpak waarbij verschillende versies van de applicatie in afzonderlijke containers worden geïmplementeerd, biedt nog een ander gemak: snel terugdraaien naar de oude versie (het is immers voldoende om verkeer naar de gewenste container te schakelen).
De laatste eerste aanbeveling klinkt als iets waar zelfs de kapitein geen fout in kon vinden: “[bij het organiseren van Continuous Delivery met Docker] Gebruik Docker [en begrijp wat het geeft]" Bedenk dat dit geen wondermiddel is dat elk probleem oplost, maar een hulpmiddel dat een prachtige basis biedt.
Reproduceerbaarheid
Met ‘reproduceerbaarheid’ bedoelen we een algemene reeks problemen die men tegenkomt bij het bedienen van applicaties. We hebben het over dergelijke gevallen:
- Scripts die door de kwaliteitsafdeling worden gecontroleerd op enscenering, moeten nauwkeurig worden gereproduceerd in de productie.
- Applicaties worden gepubliceerd op servers die pakketten kunnen ontvangen van verschillende repository-mirrors (na verloop van tijd worden ze bijgewerkt, en daarmee ook de versies van geïnstalleerde applicaties).
- “Alles werkt lokaal voor mij!” (...en ontwikkelaars mogen niet in productie.)
- Je moet iets controleren in de oude (gearchiveerde) versie.
- ...
Hun algemene essentie komt neer op het feit dat volledige naleving van de gebruikte omgevingen (evenals de afwezigheid van de menselijke factor) noodzakelijk is. Hoe kunnen we reproduceerbaarheid garanderen? Maak Docker-images gebaseerd op code uit Git, en deze vervolgens voor elke taak te gebruiken: op testsites, in productie, op lokale machines van programmeurs... Tegelijkertijd is het belangrijk om de acties die worden uitgevoerd te minimaliseren na het samenstellen van de afbeelding: hoe eenvoudiger het is, hoe kleiner de kans dat er fouten zijn.
Infrastructuur is code
Als de infrastructuurvereisten (beschikbaarheid van serversoftware, de versie ervan, enz.) niet geformaliseerd en “geprogrammeerd” zijn, kan de uitrol van welke applicatie-update dan ook desastreuze gevolgen hebben. Als je bij de staging bijvoorbeeld al bent overgestapt op PHP 7.0 en de code dienovereenkomstig hebt herschreven - dan zal de verschijning ervan in productie met wat oude PHP (5.5) zeker iemand verrassen. U mag een grote verandering in de tolkversie niet vergeten, maar “de duivel zit in de details”: de verrassing kan schuilen in een kleine update van elke afhankelijkheid.
Een aanpak om dit probleem op te lossen staat bekend als IaC (Infrastructuur als Code, “infrastructuur als code”) en omvat het opslaan van infrastructuurvereisten samen met de applicatiecode. Hiermee kunnen ontwikkelaars en DevOps-specialisten met dezelfde Git-applicatierepository werken, maar op verschillende delen ervan. Uit deze code wordt een Docker-image gemaakt in Git, waarin de applicatie wordt ingezet, rekening houdend met alle specifieke kenmerken van de infrastructuur. Simpel gezegd moeten de scripts (regels) voor het samenstellen van afbeeldingen zich in dezelfde repository bevinden als de broncode en worden samengevoegd.
In het geval van een applicatiearchitectuur met meerdere lagen - er is bijvoorbeeld nginx, die vóór een applicatie staat die al in een Docker-container draait - moeten voor elke laag Docker-images worden gemaakt op basis van code in Git. Dan zal de eerste afbeelding een applicatie bevatten met een tolk en andere “nauwe” afhankelijkheden, en de tweede afbeelding zal de upstream nginx bevatten.
Docker-images, communicatie met Git
We verdelen alle Docker-images die we van Git hebben verzameld in twee categorieën: tijdelijk en release. Tijdelijke afbeeldingen getagd met de naam van de branch in Git, kunnen worden overschreven door de volgende commit en worden alleen uitgerold voor preview (niet voor productie). Dit is het belangrijkste verschil met releaseversies: je weet nooit welke specifieke commit erin zit.
Het is zinvol om tijdelijke afbeeldingen te verzamelen: de master branch (je kunt deze automatisch uitrollen naar een aparte site om constant de huidige versie van de master te zien), branches met releases, branches van specifieke innovaties.
Nadat de preview van tijdelijke afbeeldingen de noodzaak van vertaling naar productie heeft bereikt, hebben de ontwikkelaars een bepaalde tag geplaatst. Automatisch verzameld per tag afbeelding loslaten (de tag komt overeen met de tag van Git) en wordt uitgerold naar staging. Als het met succes is geverifieerd door de kwaliteitsafdeling, gaat het naar productie.
Dapp
Alles wat beschreven wordt (uitrol, image-assemblage, daaropvolgend onderhoud) kan onafhankelijk worden geïmplementeerd met behulp van Bash-scripts en andere “geïmproviseerde” tools. Maar als je dit doet, leidt de implementatie op een gegeven moment tot grote complexiteit en slechte beheersbaarheid. Toen we dit begrepen, zijn we ons eigen gespecialiseerde Workflow-hulpprogramma gaan maken voor het bouwen van CI/CD - Dapp.
De broncode is geschreven in Ruby, open source en gepubliceerd op . Helaas is documentatie momenteel het zwakste punt van de tool, maar we werken eraan. En we zullen meer dan eens over de dapp schrijven en praten, omdat... We kunnen oprecht niet wachten om de mogelijkheden ervan met de hele geïnteresseerde gemeenschap te delen, maar stuur in de tussentijd uw problemen en pull-verzoeken en/of volg de ontwikkeling van het project op GitHub.
Bijgewerkt op 13 augustus 2019: momenteel een project Dapp hernoemd naar , is de code volledig herschreven in Go en is de documentatie aanzienlijk verbeterd.
Kubernetes
Een andere kant-en-klare Open Source-tool die al aanzienlijke erkenning heeft gekregen in de professionele omgeving is Kubernetes,een Docker-beheercluster. Het onderwerp van het gebruik ervan bij de werking van projecten die op Docker zijn gebouwd, valt buiten het bestek van het rapport, dus de presentatie is beperkt tot een overzicht van enkele interessante functies.
Voor uitrol biedt Kubernetes:
- gereedheidstest — het controleren van de gereedheid van een nieuwe versie van de applicatie (om er verkeer naartoe te sturen);
- rolling update - sequentiële image-update in een cluster van containers (afsluiten, update, voorbereiding voor lancering, verkeer wisselen);
- synchrone update - een afbeelding in een cluster bijwerken met een andere aanpak: eerst op de helft van de containers, daarna op de rest;
- canary releases - lancering van een nieuw image op een beperkt (klein) aantal containers om afwijkingen te monitoren.
Omdat Continuous Delivery niet alleen de release van een nieuwe versie is, beschikt Kubernetes over een aantal mogelijkheden voor daaropvolgend onderhoud van de infrastructuur: ingebouwde monitoring en logging voor alle containers, automatisch schalen, etc. Dit alles werkt al en wacht gewoon op een goede oplossing. implementatie in uw processen.
Laatste aanbevelingen
- Gebruik Docker.
- Maak Docker-images van applicaties voor al uw behoeften.
- Volg het principe ‘Infrastructuur is code’.
- Koppel Git aan Docker.
- Regel de volgorde van uitrol.
- Gebruik een kant-en-klaar platform (Kubernetes of een ander).
Video's en dia's
Video van de voorstelling (ongeveer een uur) (het verslag zelf begint vanaf de 5e minuut - volg de link om vanaf dit moment te spelen).
Presentatie van het rapport:
PS
Andere rapporten over dit onderwerp op onze blog:
- «» (Dmitry Stolyarov; 27 mei 2019 bij DevOpsConf);
- «» (Dmitry Stolyarov; 8 november 2018 op HighLoad++);
- «» (Dmitry Stolyarov; 7 november 2017 op HighLoad++);
- «» (Dmitry Stolyarov; 6 juni 2017 bij RootConf).
Bron: www.habr.com