Utvecklings- och testprocess med Docker och Gitlab CI

Jag föreslår att du läser utskriften av rapporten av Alexander Sigachev från Inventos "Utvecklings- och testprocess med Docker + Gitlab CI"

De som precis har börjat implementera utvecklings- och testprocessen baserad på Docker + Gitlab CI ställer ofta grundläggande frågor. Var ska man starta? Hur organiserar man sig? Hur testar man?

Den här rapporten är bra eftersom den på ett strukturerat sätt talar om utvecklings- och testprocessen med Docker och Gitlab CI. Själva rapporten är från 2017. Jag tror att du från den här rapporten kan hämta grunderna, metodiken, idén och erfarenheten av användningen.

För alla intresserade, se katt.

Jag heter Alexander Sigachev. Jag jobbar för Inventos. Jag ska berätta om min erfarenhet av att använda Docker och hur vi gradvis implementerar det på projekt i företaget.

Rapportens ämne: Utvecklingsprocess med Docker och Gitlab CI.

Det här är mitt andra föredrag om Docker. Vid tidpunkten för den första rapporten använde vi Docker endast i utveckling på utvecklarmaskiner. Antalet anställda som använde Docker var cirka 2-3 personer. Efter hand fick vi erfarenhet och vi gick lite längre. Länk till vår första rapporten.

Vad kommer att stå i denna rapport? Vi kommer att dela med oss ​​av vår erfarenhet om vilka rakes vi samlade in, vilka problem vi löste. Det var inte vackert överallt, men det gjorde att vi kunde gå vidare.

Vårt motto: dockerisera allt vi får tag i.

Vilka problem löser vi?

När ett företag har flera team är programmeraren en delad resurs. Det finns stadier när en programmerare dras ur ett projekt och ges till ett annat projekt under en tid.

För att en programmerare snabbt ska förstå måste han ladda ner källkoden för projektet och starta en miljö så snabbt som möjligt, vilket gör det möjligt för honom att gå vidare med att lösa problemen med detta projekt.

Vanligtvis, om du börjar från noll, finns det lite dokumentation i projektet. Det är bara gamla som har information om hur man ställer in det. Anställda inrättar sin arbetsplats på egen hand på en eller två dagar. För att påskynda detta använde vi Docker.

Nästa anledning är standardiseringen av inställningar i utveckling. Min erfarenhet är att utvecklare alltid tar initiativet. I vart femte fall anges en anpassad domän, till exempel vasya.dev. Bredvid mig sitter min granne Petya, vars domän är petya.dev. De utvecklar en webbplats eller någon systemkomponent med detta domännamn.

När systemet växer och dessa domännamn börjar inkluderas i konfigurationen uppstår en konflikt i utvecklingsmiljöer och webbplatsens sökväg skrivs om.

Samma sak händer med databasinställningar. Vissa människor bryr sig inte om säkerhet och arbetar med ett tomt root-lösenord. Vid installationsstadiet bad MySQL någon om ett lösenord och lösenordet visade sig vara 123. Det händer ofta att databaskonfigurationen ständigt förändrades beroende på utvecklarens commit. Någon korrigerade, någon korrigerade inte konfigurationen. Det fanns knep när vi satte in några testkonfigurationer .gitignore och varje utvecklare var tvungen att installera databasen. Detta gjorde startprocessen svårare. Du behöver bland annat komma ihåg om databasen. Databasen måste initieras, ett lösenord måste registreras, en användare måste vara registrerad, en skylt måste skapas och så vidare.

Ett annat problem är olika versioner av bibliotek. Det händer ofta att en utvecklare arbetar med olika projekt. Det finns ett Legacy-projekt, som startade för fem år sedan (från 2017 – reds. anm.). I början började vi med MySQL 5.5. Det finns även moderna projekt där vi försöker implementera mer moderna versioner av MySQL, till exempel 5.7 eller äldre (2017 – reds. anm.)

Alla som arbetar med MySQL vet att dessa bibliotek har beroenden. Det är ganska problematiskt att köra 2 databaser tillsammans. Åtminstone är det problematiskt att koppla gamla klienter till den nya databasen. Detta ger i sin tur upphov till flera problem.

Nästa problem är när en utvecklare arbetar på en lokal maskin, han använder lokala resurser, lokala filer, lokalt RAM. All interaktion vid tidpunkten för utveckling av en lösning på problem sker inom ramen för att det fungerar på en maskin. Ett exempel skulle vara när vi har backend-servrar i produktion 3, och utvecklaren sparar filer till rotkatalogen och därifrån tar nginx filerna för att svara på begäran. När sådan kod kommer in i produktion visar det sig att filen finns på en av tre servrar.

Inriktningen för mikrotjänster utvecklas för närvarande. När vi delar upp våra stora applikationer i några små komponenter som interagerar med varandra. Detta låter dig välja teknik för en specifik uppgiftsstack. Detta gör att du också kan dela upp arbetet och ansvarsområdet mellan utvecklare.

En frontend-utvecklare, som utvecklar i JS, har praktiskt taget inget inflytande på backend. Backend-utvecklaren i sin tur utvecklar, i vårt fall, Ruby on Rails och stör inte Frondend. Interaktion utförs med hjälp av API.

Som en bonus kunde vi genom att använda Docker återvinna resurser på Staging. Varje projekt, på grund av dess särdrag, krävde vissa inställningar. Fysiskt var det nödvändigt att tilldela antingen en virtuell server och konfigurera dem separat, eller dela upp någon form av variabel miljö och projekt kunde påverka varandra, beroende på versionen av biblioteken.

Verktyg. Vad använder vi?

• Docker själv. En dockerfil beskriver beroenden för en enskild applikation.
• Docker-compose är ett paket som samlar flera av våra Docker-applikationer.
• Vi använder GitLab för att lagra källkod.
• Vi använder GitLab-CI för systemintegration.

Rapporten består av två delar.

Den första delen kommer att berätta hur du kör Docker på utvecklarnas maskiner.

Den andra delen kommer att prata om hur man interagerar med GitLab, hur vi kör tester och hur vi rullar ut till Staging.

Docker är en teknik som gör det möjligt (med ett deklarativt tillvägagångssätt) att beskriva de nödvändiga komponenterna. Detta är ett exempel på Dockerfile. Här förklarar vi att vi ärver från den officiella Docker-bilden av Ruby:2.3.0. Den innehåller Ruby version 2.3 installerad. Vi installerar nödvändiga monteringsbibliotek och NodeJS. Vi beskriver att vi skapar en katalog /app. Vi tilldelar appkatalogen som arbetskatalog. I den här katalogen placerar vi minsta nödvändiga Gemfile och Gemfile.lock. Sedan bygger vi projekt som installerar denna beroendebild. Vi anger att behållaren kommer att vara redo att lyssna på extern port 3000. Det sista kommandot är kommandot som direkt startar vår applikation. Om vi ​​kör kommandot projekt kör kommer programmet att försöka köra och köra det angivna kommandot.

Detta är ett minimalt exempel på en docker-compose-fil. I det här fallet visar vi att det finns ett samband mellan två containrar. Detta är direkt in i databastjänsten och webbtjänsten. Våra webbapplikationer kräver i de flesta fall någon form av databas som backend för att lagra data. Eftersom vi använder MySQL är exemplet med MySQL - men ingenting hindrar oss från att använda någon annan databas (PostgreSQL, Redis).

Vi tar MySQL 5.7.14-bilden utan ändringar från den officiella källan från Docker-hubben. Vi hämtar bilden som är ansvarig för vår webbapplikation från den aktuella katalogen. Under den första lanseringen samlar han en bild åt oss. Sedan kör den kommandot som vi kör här. Om vi ​​går tillbaka kommer vi att se att startkommandot definierades genom Puma. Puma är en tjänst skriven i Ruby. I det andra fallet åsidosätter vi. Detta kommando kan vara godtyckligt beroende på våra behov eller uppgifter.

Vi beskriver också att vi måste vidarebefordra porten på vår utvecklarvärddator från 3000 till 3000 containerportar. Detta görs automatiskt med hjälp av iptables och en egen mekanism, som är direkt inbäddad i Docker.

Utvecklaren kan, som tidigare, komma åt vilken tillgänglig IP-adress som helst, till exempel 127.0.0.1 lokal eller extern IP-adress för maskinen.

Den sista raden säger att webbbehållaren beror på db-behållaren. När vi anropar webbbehållaren för att starta, kommer docker-compose först att starta databasen åt oss. Redan vid starten av databasen (i själva verket efter lanseringen av behållaren! Detta garanterar inte databasens beredskap) kommer den att starta vår applikation, vår backend.

Detta gör att vi kan undvika fel när databasen inte är uppe och gör att vi kan spara resurser när vi stoppar databascontainern, vilket frigör resurser för andra projekt.

Vad ger oss att använda databasdockning i ett projekt? Vi spelar in MySQL-versionen för alla utvecklare. Detta gör att du kan undvika vissa fel som kan uppstå när versioner avviker, när syntax, konfiguration och standardinställningar ändras. Detta låter dig ange ett gemensamt värdnamn för databasen, inloggning, lösenord. Vi går bort från djurparken av namn och konflikter i konfigurationsfiler som fanns tidigare.

Vi har möjlighet att använda en mer optimal konfiguration för utvecklingsmiljön, som kommer att skilja sig från standard. MySQL är konfigurerat som standard för svaga maskiner och dess prestanda ur lådan är mycket låg.

Docker låter dig använda Python, Ruby, NodeJS, PHP-tolken för den önskade versionen. Vi slipper behovet av att använda någon form av versionshanterare. Tidigare användes ett rpm-paket för Ruby, vilket gjorde att du kunde ändra version beroende på projekt. Tack vare Docker-behållaren låter detta dig också smidigt migrera kod och versionera den tillsammans med beroenden. Vi har inga problem att förstå versionen av både tolken och koden. För att uppdatera versionen måste du sänka den gamla behållaren och höja den nya behållaren. Om något går fel kan vi sänka den nya containern, höja den gamla containern.

Efter att ha byggt bilden kommer behållarna i både utveckling och produktion att vara desamma. Detta gäller särskilt för stora installationer.

På Frontend använder vi JavaScipt och NodeJS.

Nu har vi vårt sista projekt på ReacJS. Utvecklaren lanserade allt i behållaren och utvecklade med hjälp av hot-reload.

Därefter startar uppgiften att sätta ihop JavaScipt och den statiskt sammansatta koden skickas via nginx, vilket sparar resurser.

Här har jag tillhandahållit ett diagram över vårt senaste projekt.

Vilka problem löste du? Vi hade ett behov av att bygga ett system som mobila enheter interagerar med. De tar emot data. En av möjligheterna är att skicka push-meddelanden till den här enheten.

Vad har vi gjort för detta?

Vi delade upp applikationen i följande komponenter: en admindel i JS, en backend som fungerar genom ett REST-gränssnitt under Ruby on Rails. Backend interagerar med databasen. Resultatet som genereras ges till klienten. Administratörspanelen interagerar med backend och databasen via ett REST-gränssnitt.

Vi hade också ett behov av att skicka push-aviseringar. Innan detta hade vi ett projekt där en mekanism implementerades som ansvarade för att leverera aviseringar till mobila plattformar.

Vi har utvecklat följande schema: operatören från webbläsaren interagerar med adminpanelen, adminpanelen interagerar med backend, uppgiften är att skicka push-meddelanden.

Push-meddelanden interagerar med en annan komponent som är implementerad i NodeJS.

Köer byggs och aviseringar skickas enligt sin egen mekanism.

Här ritas två databaser. För närvarande använder vi Docker 2 oberoende databaser som inte på något sätt är kopplade till varandra. Förutom det faktum att de har ett gemensamt virtuellt nätverk, och fysisk data lagras i olika kataloger på utvecklarens maskin.

Samma sak men i antal. Återanvändning av kod är viktigt här.

Om vi ​​tidigare pratat om att återanvända kod i form av bibliotek, så återanvänds i detta exempel vår tjänst, som svarar på push-meddelanden, som en komplett server. Det tillhandahåller ett API. Och vår nya utveckling interagerar med den.

Vid den tiden använde vi version 4 av NodeJS. Nu (2017 - reds. anm.) i vår senaste utveckling använder vi version 7 av NodeJS. Det är inga problem i nya komponenter att involvera nya versioner av bibliotek.

Om det behövs kan du refaktorera och höja NodeJS-versionen av Push-meddelandetjänsten.

Och om vi kan upprätthålla API-kompatibilitet kommer det att vara möjligt att ersätta det med andra projekt som användes tidigare.

Vad behöver du för att lägga till Docker? Vi lägger till en Dockerfile till vårt arkiv, som beskriver nödvändiga beroenden. I det här exemplet är komponenterna logiskt uppdelade. Detta är minimisatsen för en backend-utvecklare.

När vi skapar ett nytt projekt skapar vi en Dockerfil och beskriver det önskade ekosystemet (Python, Ruby, NodeJS). I docker-compose beskriver den det nödvändiga beroendet - databasen. Vi beskriver att vi behöver en databas med en sådan och en version, för att lagra data där och där.

Vi använder en separat tredje behållare med nginx för att visa statiskt innehåll. Det är möjligt att ladda upp bilder. Backend lägger dem i en förberedd volym, som också är monterad i en container med nginx, som ger statisk data.

För att lagra nginx- och mysql-konfigurationen lade vi till en Docker-mapp där vi lagrar nödvändiga konfigurationer. När en utvecklare gör en git-klon av ett arkiv på sin maskin har han redan ett projekt redo för lokal utveckling. Det är ingen fråga om vilken port eller vilka inställningar som ska tillämpas.

Därefter har vi flera komponenter: admin, info-API, push-meddelanden.

För att starta allt detta skapade vi ett annat förråd som heter dockerized-app. Vi använder för närvarande flera arkiv för varje komponent. De är helt enkelt logiskt olika - i GitLab ser det ut som en mapp, men på utvecklarens maskin ser det ut som en mapp för ett specifikt projekt. En nivå under är de komponenter som kommer att kombineras.

Detta är ett exempel på innehållet i dockeriserade appar. Vi placerar också en Docker-katalog här, där vi fyller i de konfigurationer som krävs för interaktionen mellan alla komponenter. Det finns en README.md som kort beskriver hur man startar projektet.

Här har vi använt två docker-compose-filer. Detta görs för att kunna sjösätta i etapper. När en utvecklare arbetar med kärnan behöver han inga push-meddelanden, han startar helt enkelt docker-compose-filen och följaktligen sparas resurser.

Om det finns ett behov av integration med Push-meddelanden, så lanseras docker-compose.yaml och docker-compose-push.yaml.

Eftersom docker-compose.yaml och docker-compose-push.yaml finns i mappen skapas ett enda virtuellt nätverk automatiskt.

Beskrivning av komponenter. Detta är en mer avancerad fil som ansvarar för att samla in komponenter. Vad är anmärkningsvärt här? Här introducerar vi balanseringskomponenten.

Detta är en färdig Docker-bild som kör nginx och ett program som lyssnar på Docker-uttaget. Dynamiskt, när behållare slås på och av, återskapas nginx-konfigurationen. Vi distribuerar hanteringen av komponenter med hjälp av domännamn på tredje nivå.

För utvecklingsmiljön använder vi .dev-domänen - api.informer.dev. Applikationer med en .dev-domän är tillgängliga på utvecklarens lokala dator.

Sedan överförs konfigurationerna till varje projekt och alla projekt startas samtidigt.

Om vi ​​avbildar det grafiskt visar det sig att klienten är vår webbläsare eller något slags verktyg som vi gör förfrågningar med till balansören.

Balanseraren bestämmer vilken behållare som behöver nås baserat på domännamnet.

Detta kan vara nginx, som tillhandahåller JS till adminpanelen. Detta kan göras av nginx, som tillhandahåller API:t, eller statiska filer, som tillhandahålls av nginx i form av att ladda bilder.

Diagrammet visar att behållarna är anslutna till ett virtuellt nätverk och gömda bakom en proxy.

På utvecklarens maskin kan du komma åt behållaren med kunskap om IP, men i princip använder vi inte detta. Det finns praktiskt taget inget behov av direktkontakt.

Vilket exempel ska jag titta på för att dockerisera min applikation? Enligt min mening är ett bra exempel den officiella docker-bilden för MySQL.

Det är ganska komplicerat. Det finns många versioner. Men dess funktionalitet gör att du kan täcka många behov som kan uppstå i processen med vidareutveckling. Om du tar dig tid och förstår hur det hela samverkar, så tror jag att du inte kommer att ha några problem att implementera det själv.

Hub.docker.com innehåller vanligtvis länkar till github.com, där rådata tillhandahålls direkt från vilken du själv kan bygga en bild.

Längre in i detta förråd finns ett skript docker-endpoint.sh, som är ansvarigt för den initiala initieringen och vidarebearbetningen av applikationsstart.

Även i detta exempel finns möjligheten att konfigurera med hjälp av miljövariabler. Genom att definiera en miljövariabel när man kör en enskild behållare eller genom docker-compose kan vi säga att vi måste ställa in ett tomt lösenord för docker för root på MySQL eller vad vi nu vill.

Det finns ett alternativ att skapa ett slumpmässigt lösenord. Vi säger att vi behöver en användare, vi måste ställa in ett lösenord för användaren och vi måste skapa en databas.

I våra projekt har vi något enat Dockerfilen, som ansvarar för initiering. Där anpassade vi det efter våra behov för att helt enkelt utöka de användarrättigheter som applikationen använder. Detta gjorde det möjligt att helt enkelt skapa en databas från applikationskonsolen i framtiden. Ruby-applikationer har kommandon för att skapa, ändra och ta bort databaser.

Det här är ett exempel på hur en specifik version av MySQL ser ut på github.com. Du kan öppna Dockerfilen och se hur installationen sker där.

docker-endpoint.sh skript ansvarigt för ingångspunkten. Under initial initiering krävs vissa förberedande åtgärder och alla dessa åtgärder ingår i initieringsskriptet.

Låt oss gå vidare till den andra delen.

Vi bytte till gitlab för att lagra källkoder. Detta är ett ganska kraftfullt system som har ett visuellt gränssnitt.

En av Gitlab-komponenterna är Gitlab CI. Det låter dig beskriva en serie kommandon som sedan kommer att användas för att organisera ett kodleveranssystem eller köra automatiserade tester.

Rapport om Gitlab CI 2 https://goo.gl/uohKjI — Rapporten från klubben Ruby Russia är ganska detaljerad och kan vara av intresse för dig.

Nu ska vi titta på vad som krävs för att aktivera Gitlab CI. För att kunna starta Gitlab CI behöver vi bara sätta filen .gitlab-ci.yml i roten av projektet.

Här beskriver vi att vi vill utföra en sekvens av tillstånd som test, deployment.

Vi kör skript som direkt anropar docker-compose-bygget för vår applikation. Detta är ett exempel på bara backend.

Därefter säger vi att det är nödvändigt att köra migreringar för att ändra databasen och köra tester.

Om skripten exekveras korrekt och inte returnerar en felkod, fortsätter systemet till det andra steget av distributionen.

Implementeringsstadiet är för närvarande implementerat för iscensättning. Vi organiserade ingen omstart utan driftstopp.

Vi tvångssläcker alla containrar och sedan lyfter vi upp alla containrar igen, samlade in i det första skedet under testningen.

Låt oss köra databasmigreringarna som skrevs av utvecklarna för den aktuella variabelmiljön.

Det finns en notering att detta endast ska tillämpas på mastergrenen.

Fungerar inte när man byter andra grenar.

Det är möjligt att organisera utrullningar längs grenar.

För att organisera detta ytterligare måste vi installera Gitlab Runner.

Detta verktyg är skrivet i Golang. Det är en enda fil som är vanligt i Golang-världen, som inte kräver några beroenden.

Vid uppstart registrerar vi Gitlab Runner.

Vi tar emot nyckeln i Gitlabs webbgränssnitt.

Sedan anropar vi initialiseringskommandot på kommandoraden.

Konfigurera Gitlab Runner i dialogläge (Shell, Docker, VirtualBox, SSH)

Koden på Gitlab Runner kommer att köras vid varje commit beroende på .gitlab-ci.yml-inställningen.

Hur det visuellt ser ut i Gitlab i webbgränssnittet. Efter att ha anslutit GItlab CI har vi en flagga som visar vilket tillstånd byggnaden är i för tillfället.

Vi ser att för 4 minuter sedan gjordes en commit som klarade alla tester och inte orsakade några problem.

Vi kan titta på byggen mer i detalj. Här ser vi att två stater redan har passerat. Teststatus och driftsättningsstatus vid staging.

Om vi ​​klickar på en specifik build kommer det att finnas konsolutmatning av kommandona som lanserades i processen enligt .gitlab-ci.yml.

Så här ser historien om vår produkt ut. Vi ser att det har varit framgångsrika försök. När testerna är inlämnade går de inte vidare till nästa steg och iscensättningskoden uppdateras inte.

Vilka problem löste vi i iscensättningen när vi implementerade docker? Vårt system består av komponenter och vi behövde starta om endast några av de komponenter som uppdaterades i förvaret, och inte hela systemet.

För att göra detta var vi tvungna att dela upp allt i separata mappar.

Efter att vi gjort detta hade vi ett problem med att Docker-compose skapar sitt eget nätverksutrymme för varje mapp och inte ser komponenterna hos sin granne.

För att komma runt skapade vi nätverket manuellt i Docker. I Docker-compose skrevs det att man skulle använda ett sådant nätverk för detta projekt.

Således ser varje komponent som börjar med detta mesh komponenter i andra delar av systemet.

Nästa problem är att dela upp iscensättningen mellan flera projekt.

Eftersom för att allt detta ska se vackert ut och så nära produktionen som möjligt är det bra att använda port 80 eller 443, som används överallt i WEB.

Hur löste vi detta? Vi tilldelade en Gitlab Runner till alla stora projekt.

Gitlab låter dig lansera flera distribuerade Gitlab Runners, som helt enkelt tar alla uppgifter en efter en i en kaotisk ordning och kör dem.

För att undvika husproblem begränsade vi gruppen av våra projekt till en Gitlab Runner, som klarar våra volymer utan problem.

Vi flyttade nginx-proxy till ett separat lanseringsskript och skrev rutnäten för alla projekt i det.

Vårt projekt har ett rutnät och balanseraren har flera rutnät baserat på projektnamn. Det kan proxy ytterligare med domännamn.

Våra förfrågningar kommer via domänen på port 80 och löses till en grupp containrar som betjänar denna domän.

Vilka andra problem fanns det? Detta är vad alla behållare körs som root som standard. Detta är den ojämna rotvärden för systemet.

Men om du går in i behållaren blir det root och filen som vi skapar i den här behållaren får rooträttigheter.

Om en utvecklare gick in i behållaren och gjorde några kommandon där som genererade filer och sedan lämnade behållaren, så har han i sin arbetskatalog en fil som han inte har tillgång till.

Hur kan detta lösas? Du kan lägga till användare som kommer att finnas i behållaren.

Vilka problem uppstod när vi lade till användaren?

När du skapar en användare stämmer ofta inte grupp-ID (UID) och användar-ID (GID).

För att lösa detta problem i behållaren använder vi användare med ID 1000.

I vårt fall sammanföll detta med att nästan alla utvecklare använder Ubuntu OS. Och i Ubuntu OS har den första användaren ID 1000.

Har vi planer?

Läs Docker-dokumentationen igen. Projektet utvecklas aktivt, dokumentationen förändras. Data som erhölls för två eller tre månader sedan börjar långsamt bli inaktuella.

En del av de problem som vi löste kan mycket väl redan ha lösts med standardmetoder.

Jag vill verkligen gå vidare och gå direkt till orkestrering.

Ett exempel är Dockers inbyggda mekanism kallad Docker Swarm, som kommer ut ur lådan. Jag skulle vilja lansera något i produktion baserat på Docker Swarm-tekniken.

Lekbehållare gör det obekvämt att arbeta med stockar. Nu är stockarna isolerade. De är utspridda i containrar. En av uppgifterna är att göra bekväm åtkomst till loggar via ett webbgränssnitt.

Källa: will.com