Jeg foreslår at læse udskriften af rapporten af Alexander Sigachev fra Inventos "Udviklings- og testproces med Docker + Gitlab CI"
De, der lige er begyndt at implementere udviklings- og testprocessen baseret på Docker + Gitlab CI, stiller ofte grundlæggende spørgsmål. Hvor skal man begynde? Hvordan organiseres? Hvordan tester man?
Denne rapport er god, fordi den på en struktureret måde taler om udviklings- og testprocessen ved hjælp af Docker og Gitlab CI. Selve rapporten er fra 2017. Jeg tror, at du fra denne rapport kan lære det grundlæggende, metodologi, idé, brugsoplevelse.
Hvem bekymrer sig, venligst under katten.
Mit navn er Alexander Sigachev. Jeg arbejder for Inventos. Jeg vil fortælle om min erfaring med at bruge Docker og hvordan vi gradvist implementerer det på projekter i virksomheden.
Præsentationsemne: Udviklingsproces ved hjælp af Docker og Gitlab CI.
Dette er min anden snak om Docker. På tidspunktet for den første rapport brugte vi kun Docker i udvikling på udviklermaskiner. Antallet af medarbejdere, der brugte Docker, var omkring 2-3 personer. Efterhånden blev der høstet erfaringer, og vi rykkede lidt længere. Link til vores .
Hvad vil der stå i denne rapport? Vi vil dele vores erfaring om, hvilken rake vi har samlet, hvilke problemer vi har løst. Ikke alle steder var det smukt, men fik lov til at komme videre.
Vores motto er: læg alt, hvad vi kan få fat i.
Hvilke problemer løser vi?
Når der er flere teams i en virksomhed, er programmøren en delt ressource. Der er stadier, hvor en programmør trækkes ud af et projekt og gives i nogen tid til et andet projekt.
For at programmøren hurtigt kan forstå, skal han downloade kildekoden til projektet og starte miljøet så hurtigt som muligt, hvilket vil give ham mulighed for at gå videre med at løse problemerne med dette projekt.
Normalt, hvis du starter fra bunden, så er der lidt dokumentation i projektet. Oplysninger om opsætning er kun tilgængelig for oldtimere. Medarbejdere indretter deres arbejdsplads på egen hånd på en eller to dage. For at fremskynde dette brugte vi Docker.
Den næste grund er standardiseringen af indstillinger i udvikling. Min erfaring er, at udviklere altid tager initiativet. I hvert femte tilfælde indtastes et brugerdefineret domæne, for eksempel vasya.dev. Ved siden af ham sidder hans nabo Petya, hvis domæne er petya.dev. De udvikler et websted eller en komponent af systemet ved hjælp af dette domænenavn.
Når systemet vokser, og disse domænenavne begynder at komme ind i konfigurationer, opstår der en udviklingsmiljøkonflikt, og webstedsstien omskrives.
Det samme sker med databaseindstillinger. Nogen gider ikke sikkerheden og arbejder med en tom root-adgangskode. På installationsstadiet bad MySQL nogen om en adgangskode, og adgangskoden viste sig at være 123. Det sker ofte, at databasekonfigurationen konstant ændrer sig afhængigt af udviklerens commit. Nogen rettede, nogen rettede ikke konfigurationen. Der var tricks, da vi tog en form for testkonfiguration ud .gitignore og hver udvikler skulle installere databasen. Det gjorde det svært at komme i gang. Det er blandt andet nødvendigt at huske om databasen. Databasen skal initialiseres, en adgangskode skal indtastes, en bruger skal være registreret, en tabel skal oprettes og så videre.
Et andet problem er forskellige versioner af biblioteker. Det sker ofte, at en udvikler arbejder med forskellige projekter. Der er et Legacy-projekt, der startede for fem år siden (fra 2017 - red. anm.). På tidspunktet for lanceringen startede vi med MySQL 5.5. Der er også moderne projekter, hvor vi forsøger at implementere mere moderne versioner af MySQL, for eksempel 5.7 eller ældre (i 2017 - red. anm.)
Enhver, der arbejder med MySQL, ved, at disse biblioteker bringer afhængigheder med sig. Det er ret problematisk at køre 2 baser sammen. I det mindste er gamle klienter problematiske at forbinde til den nye database. Dette skaber igen flere problemer.
Det næste problem er, når en udvikler arbejder på en lokal maskine, han bruger lokale ressourcer, lokale filer, lokal RAM. Al interaktion på tidspunktet for udvikling af en løsning på problemer udføres inden for rammerne af, at det fungerer på én maskine. Et eksempel er, når vi har backend-servere i produktion 3, og udvikleren gemmer filer i rodmappen og derfra tager nginx filer for at svare på anmodningen. Når sådan en kode kommer ind i produktionen, viser det sig, at filen findes på en af de 3 servere.
Retningen for mikrotjenester udvikler sig nu. Når vi deler vores store applikationer op i nogle små komponenter, der interagerer med hinanden. Dette giver dig mulighed for at vælge teknologier til en bestemt stak af opgaver. Det giver dig også mulighed for at dele arbejde og ansvar mellem udviklere.
Frondend-udvikler, der udvikler på JS, har næsten ingen indflydelse på Backend. Backend-udvikleren udvikler til gengæld, i vores tilfælde, Ruby on Rails og forstyrrer ikke Frondend. Interaktionen udføres ved hjælp af API.
Som en bonus var vi ved hjælp af Docker i stand til at genbruge ressourcer på Staging. Hvert projekt krævede på grund af dets detaljer visse indstillinger. Fysisk var det nødvendigt at allokere enten en virtuel server og konfigurere dem separat, eller at dele en form for variabelt miljø og projekter kunne, afhængigt af versionen af bibliotekerne, påvirke hinanden.
Værktøjer. Hvad bruger vi?
- Docker selv. Dockerfilen beskriver afhængighederne af en enkelt applikation.
- Docker-compose er et bundt, der samler et par af vores Docker-applikationer.
- Vi bruger GitLab til at gemme kildekoden.
- Vi bruger GitLab-CI til systemintegration.
Rapporten består af to dele.
Den første del vil fortælle om, hvordan Docker blev kørt på udviklernes maskiner.
Den anden del vil tale om, hvordan man interagerer med GitLab, hvordan vi kører test, og hvordan vi ruller ud til Staging.
Docker er en teknologi, der gør det muligt (ved hjælp af en deklarativ tilgang) at beskrive de nødvendige komponenter. Dette er et eksempel på Dockerfile. Her erklærer vi, at vi arver fra det officielle Ruby:2.3.0 Docker-billede. Den indeholder Ruby version 2.3 installeret. Vi installerer de nødvendige byggebiblioteker og NodeJS. Vi beskriver, at vi opretter en mappe /app. Indstil app-biblioteket som arbejdsbibliotek. I denne mappe placerer vi den nødvendige minimale Gemfile og Gemfile.lock. Vi bygger derefter de projekter, der installerer dette afhængighedsbillede. Vi angiver, at containeren vil være klar til at lytte på ekstern port 3000. Den sidste kommando er den kommando, der direkte starter vores applikation. Hvis vi udfører projektstartkommandoen, vil applikationen forsøge at køre og køre den angivne kommando.
Dette er et minimalt eksempel på en docker-compose-fil. I dette tilfælde viser vi, at der er en sammenhæng mellem to containere. Dette er direkte ind i databasetjenesten og webtjenesten. Vores webapplikationer kræver i de fleste tilfælde en form for database som backend til lagring af data. Da vi bruger MySQL, er eksemplet med MySQL - men intet forhindrer os i at bruge en anden database (PostgreSQL, Redis).
Vi tager fra den officielle kilde fra Docker-hubben billedet af MySQL 5.7.14 uden ændringer. Vi indsamler billedet, der er ansvarligt for vores webapplikation, fra den aktuelle mappe. Det samler et billede til os under den første lancering. Så kører den kommandoen, som vi udfører her. Hvis vi går tilbage, vil vi se, at startkommandoen via Puma er blevet defineret. Puma er en tjeneste skrevet i Ruby. I det andet tilfælde tilsidesætter vi. Denne kommando kan være vilkårlig afhængig af vores behov eller opgaver.
Vi beskriver også, at vi skal videresende en port på vores udviklerværtsmaskine fra 3000 til 3000 på containerporten. Dette gøres automatisk ved hjælp af iptables og dens mekanisme, som er direkte indlejret i Docker.
Udvikleren kan også, som før, få adgang til enhver tilgængelig IP-adresse, for eksempel er 127.0.0.1 maskinens lokale eller eksterne IP-adresse.
Den sidste linje siger, at webcontaineren afhænger af db containeren. Når vi kalder starten af webcontaineren, starter docker-compose først databasen for os. Allerede ved starten af databasen (faktisk efter lanceringen af containeren! Dette garanterer ikke databasens parathed) vil lancere applikationen, vores backend.
Dette undgår fejl, når databasen ikke bringes frem, og sparer ressourcer, når vi stopper databasecontaineren, og dermed frigøres ressourcer til andre projekter.
Hvad giver os brugen af databasedokkerisering på projektet. Vi retter versionen af MySQL for alle udviklere. Dette undgår nogle fejl, der kan opstå, når versioner divergerer, når syntaks, konfiguration, standardindstillinger ændres. Dette giver dig mulighed for at angive et fælles værtsnavn for databasen, login, adgangskode. Vi bevæger os væk fra den zoologiske have af navne og konflikter i konfigurationsfilerne, som vi havde tidligere.
Vi har mulighed for at bruge en mere optimal konfig til udviklingsmiljøet, som vil afvige fra standarden. MySQL er som standard konfigureret til svage maskiner, og dens ydeevne ud af boksen er meget dårlig.
Docker giver dig mulighed for at bruge Python, Ruby, NodeJS, PHP fortolkeren af den ønskede version. Vi slipper for behovet for at bruge en form for versionsmanager. Tidligere brugte Ruby en rpm-pakke, der tillod dig at ændre versionen afhængigt af projektet. Det tillader også, takket være Docker-beholderen, at migrere koden og versionere den sammen med afhængigheder. Vi har ingen problemer med at forstå versionen af både tolken og koden. For at opdatere versionen skal du sænke den gamle beholder og hæve den nye beholder. Hvis noget gik galt, kan vi sænke den nye container, hæve den gamle container.
Efter opbygning af billedet vil beholderne i både udvikling og produktion være de samme. Dette gælder især for store installationer.
På Frontend bruger vi JavaScipt og NodeJS.
Nu har vi det sidste projekt på ReacJS. Udvikleren kørte alt i containeren og udviklede ved hjælp af hot-reload.
Dernæst lanceres JavaScipt-samlingsopgaven, og koden, der er kompileret til statik, gives gennem nginx-lagringsressourcer.
Her har jeg givet skemaet for vores sidste projekt.
Hvilke opgaver blev løst? Vi havde et behov for at bygge et system, som mobile enheder interagerer med. De modtager data. En mulighed er at sende push-beskeder til denne enhed.
Hvad har vi gjort for dette?
Vi opdelte i applikationen sådanne komponenter som: admin-delen på JS, backend, som fungerer gennem REST-grænsefladen under Ruby on Rails. Backend interagerer med databasen. Resultatet, der genereres, gives til klienten. Adminpanelet interagerer med backend og databasen via REST-grænsefladen.
Vi havde også et behov for at sende push-beskeder. Før det havde vi et projekt, der implementerede en mekanisme, der er ansvarlig for at levere notifikationer til mobile platforme.
Vi har udviklet følgende skema: en operatør fra browseren interagerer med admin panelet, admin panelet interagerer med backend, opgaven er at sende Push notifikationer.
Push-meddelelser interagerer med en anden komponent, der er implementeret i NodeJS.
Køer bygges, og derefter sendes meddelelser i henhold til deres mekanisme.
Her er tegnet to databaser. I øjeblikket bruger vi ved hjælp af Docker 2 uafhængige databaser, som ikke er relateret til hinanden på nogen måde. Derudover har de et fælles virtuelt netværk, og fysiske data gemmes i forskellige mapper på udviklerens maskine.
Det samme, men i antal. Det er her genbrug af kode er vigtigt.
Hvis vi tidligere talte om at genbruge kode i form af biblioteker, så genbruges vores service, der reagerer på push-meddelelser i dette eksempel, som en komplet server. Det giver en API. Og vores nye udvikling interagerer allerede med det.
På det tidspunkt brugte vi version 4 af NodeJS. Nu (i 2017 - red. anm.) i den seneste udvikling bruger vi version 7 af NodeJS. Der er ikke noget problem i nye komponenter at involvere nye versioner af biblioteker.
Hvis det er nødvendigt, kan du refaktorere og hæve NodeJS-versionen fra Push-meddelelsestjenesten.
Og hvis vi kan opretholde API-kompatibilitet, så vil det være muligt at erstatte det med andre projekter, der tidligere blev brugt.
Hvad skal du bruge for at tilføje Docker? Vi tilføjer en Dockerfile til vores repository, som beskriver de nødvendige afhængigheder. I dette eksempel er komponenterne opdelt logisk. Dette er minimumssættet for en backend-udvikler.
Når vi opretter et nyt projekt, opretter vi en Dockerfile, beskriver det ønskede økosystem (Python, Ruby, NodeJS). I docker-compose beskriver den den nødvendige afhængighed - databasen. Vi beskriver, at vi har brug for en database med sådan en version, gemmer data der og der.
Vi bruger en separat tredje beholder med nginx til at tjene statisk. Det er muligt at uploade billeder. Backend lægger dem i et forud klargjort volumen, som også er monteret i en beholder med nginx, som giver det statiske.
For at gemme nginx, mysql-konfigurationen, tilføjede vi en Docker-mappe, hvori vi gemmer de nødvendige konfigurationer. Når en udvikler laver en git-kloning af et lager på sin maskine, har han allerede et projekt klar til lokal udvikling. Der er ingen tvivl om, hvilken port eller hvilke indstillinger der skal anvendes.
Dernæst har vi flere komponenter: admin, inform-API, push-meddelelser.
For at starte alt dette oprettede vi et andet lager, som vi kaldte dockerized-app. I øjeblikket bruger vi flere repositories før hver komponent. De er bare logisk forskellige - i GitLab ligner det en mappe, men på udviklerens maskine en mappe til et specifikt projekt. Et niveau ned er de komponenter, der vil blive kombineret.
Dette er et eksempel på blot indholdet af en dockeriseret app. Vi bringer også Docker-mappen her, hvor vi udfylder de konfigurationer, der kræves til interaktioner mellem alle komponenter. Der er en README.md, der kort beskriver, hvordan man kører projektet.
Her har vi anvendt to docker-compose filer. Dette gøres for at kunne køre i trin. Når en udvikler arbejder med kernen, har han ikke brug for push-meddelelser, han starter blot en docker-compose-fil, og ressourcen gemmes derfor.
Hvis der er behov for at integrere med push-meddelelser, så lanceres docker-compose.yaml og docker-compose-push.yaml.
Da docker-compose.yaml og docker-compose-push.yaml er i en mappe, oprettes der automatisk et enkelt virtuelt netværk.
Beskrivelse af komponenter. Dette er en mere avanceret fil, der er ansvarlig for indsamlingen af komponenter. Hvad er bemærkelsesværdigt her? Her introducerer vi balancer-komponenten.
Dette er et færdiglavet Docker-billede, der kører nginx og et program, der lytter på Docker-socket. Dynamisk, når containere tændes og slukkes, regenererer den nginx-konfigurationen. Vi distribuerer håndteringen af komponenter efter domænenavne på tredje niveau.
Til udviklingsmiljøet bruger vi .dev-domænet - api.informer.dev. Programmer med et .dev-domæne er tilgængelige på udviklerens lokale maskine.
Yderligere overføres konfigurationer til hvert projekt, og alle projekter lanceres sammen på samme tid.
Grafisk viser det sig, at klienten er vores browser eller et eller andet værktøj, som vi laver anmodninger med til balanceren.
Domænenavnsbalanceren bestemmer, hvilken container der skal kontaktes.
Det kan være nginx, som giver admin JS. Dette kan være nginx, som giver API'en, eller statiske filer, som gives til nginx i form af billeduploads.
Diagrammet viser, at containerne er forbundet med et virtuelt netværk og gemt bag en proxy.
På udviklerens maskine kan du tilgå containeren ved at kende IP, men i princippet bruger vi ikke dette. Der er praktisk talt ikke behov for direkte adgang.
Hvilket eksempel skal du se på for at dockerisere din applikation? Efter min mening er et godt eksempel det officielle docker-billede til MySQL.
Det er ret udfordrende. Der er mange versioner. Men dens funktionalitet giver dig mulighed for at dække mange behov, der kan opstå i processen med videreudvikling. Hvis du bruger tid og finder ud af, hvordan det hele hænger sammen, så tror jeg, at du ikke får problemer med selvimplementering.
Hub.docker.com indeholder normalt links til github.com, som indeholder rådata direkte, hvorfra du selv kan bygge billedet.
Længere i dette lager er der et docker-endpoint.sh script, som er ansvarligt for den indledende initialisering og for yderligere behandling af applikationslanceringen.
Også i dette eksempel er der mulighed for at konfigurere ved hjælp af miljøvariabler. Ved at definere en miljøvariabel, når man kører en enkelt container eller gennem docker-compose, kan vi sige, at vi skal indstille en tom adgangskode for docker til at roote på MySQL eller hvad vi nu vil.
Der er mulighed for at oprette en tilfældig adgangskode. Vi siger, at vi har brug for en bruger, vi skal sætte en adgangskode til brugeren, og vi skal oprette en database.
I vores projekter forenede vi en smule Dockerfilen, som er ansvarlig for initialisering. Der rettede vi det til vores behov for at gøre det blot en udvidelse af de brugerrettigheder, som applikationen bruger. Dette gjorde det muligt for os at oprette en database fra applikationskonsollen senere. Ruby-applikationer har en kommando til at oprette, ændre og slette databaser.
Dette er et eksempel på, hvordan en specifik version af MySQL ser ud på github.com. Du kan åbne Dockerfilen og se, hvordan installationen foregår der.
docker-endpoint.sh er scriptet, der er ansvarligt for indgangspunktet. Under den indledende initialisering kræves nogle forberedelsestrin, og alle disse handlinger udføres kun i initialiseringsscriptet.
Lad os gå videre til anden del.
For at gemme kildekoderne skiftede vi til gitlab. Dette er et ret kraftfuldt system, der har en visuel grænseflade.
En af komponenterne i Gitlab er Gitlab CI. Det giver dig mulighed for at beskrive en sekvens af kommandoer, som senere vil blive brugt til at organisere et kodeleveringssystem eller køre automatisk test.
Gitlab CI 2 snak - rapport fra Ruby Russia-klub - ret detaljeret og måske vil det interessere dig.
Nu vil vi se på, hvad der kræves for at aktivere Gitlab CI. For at starte Gitlab CI skal vi blot sætte filen .gitlab-ci.yml i projektets rod.
Her beskriver vi, at vi ønsker at udføre en sekvens af tilstande som en test, deploy.
Vi udfører scripts, der direkte kalder docker-compose for at bygge vores applikation. Dette er blot et backend-eksempel.
Dernæst siger vi, at det er nødvendigt at køre migreringer for at ændre databasen og køre test.
Hvis scripts udføres korrekt og ikke returnerer en fejlkode, fortsætter systemet til anden fase af implementeringen.
Implementeringsfasen er i øjeblikket implementeret til iscenesættelse. Vi organiserede ikke en genstart uden nedetid.
Vi tvangsslukker alle containere, og så hæver vi alle containerne op igen, indsamlet i første fase under test.
Vi kører for den aktuelle miljøvariabel databasemigreringerne, der blev skrevet af udviklerne.
Der er en bemærkning om, at dette kun gælder for mastergrenen.
Ved ændring af andre grene udføres ikke.
Det er muligt at organisere udrulninger efter filialer.
For at organisere dette yderligere skal vi installere Gitlab Runner.
Dette hjælpeprogram er skrevet i Golang. Det er en enkelt fil, som det er almindeligt i Golang-verdenen, som ikke kræver nogen afhængigheder.
Ved opstart registrerer vi Gitlab Runner.
Vi får nøglen i Gitlab-webgrænsefladen.
Så kalder vi initialiseringskommandoen på kommandolinjen.
Konfigurer Gitlab Runner interaktivt (Shell, Docker, VirtualBox, SSH)
Koden på Gitlab Runner udføres ved hver commit, afhængigt af .gitlab-ci.yml indstillingen.
Sådan ser det ud visuelt i Gitlab i webgrænsefladen. Efter at vi har tilsluttet GItlab CI, har vi et flag, der viser status for bygningen i øjeblikket.
Vi ser, at der blev lavet en commit for 4 minutter siden, som bestod alle testene og ikke voldte problemer.
Vi kan se nærmere på byggerierne. Her ser vi, at to stater allerede er bestået. Teststatus og implementeringsstatus på iscenesættelse.
Hvis vi klikker på en specifik build, så vil der være en konsoludgang af de kommandoer, der blev kørt i processen ifølge .gitlab-ci.yml.
Sådan ser vores produkthistorie ud. Vi ser, at der var succesfulde forsøg. Når test er indsendt, fortsætter det ikke til næste trin, og iscenesættelseskoden opdateres ikke.
Hvilke opgaver løste vi på iscenesættelse, da vi implementerede docker? Vores system består af komponenter, og vi havde et behov for at genstarte, kun en del af komponenterne, der blev opdateret i depotet, og ikke hele systemet.
For at gøre dette var vi nødt til at smadre alt i separate mapper.
Efter at vi gjorde dette, havde vi et problem med, at Docker-compose opretter sit eget netværksrum til hver far og ikke kan se naboens komponenter.
For at komme rundt oprettede vi netværket i Docker manuelt. Det blev skrevet i Docker-compose, at du bruger sådan et netværk til dette projekt.
Således ser hver komponent, der starter med denne mesh, komponenter i andre dele af systemet.
Næste nummer er at opdele scener på tværs af flere projekter.
Da for at alt dette skal se smukt ud og så tæt som muligt på produktionen, er det godt at bruge port 80 eller 443, som bruges overalt i WEB.
Hvordan løste vi det? Vi har tildelt én Gitlab Runner til alle større projekter.
Gitlab giver dig mulighed for at køre flere distribuerede Gitlab Runners, som ganske enkelt vil tage alle opgaverne på skift på en kaotisk måde og køre dem.
For at vi ikke har et hus, begrænsede vi gruppen af vores projekter til én Gitlab Runner, som klarer vores volumener uden problemer.
Vi flyttede nginx-proxy til et separat opstartsscript og tilføjede gitter til alle projekter i det.
Vores projekt har ét gitter, og balanceren har flere gitter efter projektnavne. Det kan proxy yderligere ved domænenavne.
Vores anmodninger kommer gennem domænet på port 80 og bliver løst til en containergruppe, der betjener dette domæne.
Hvilke andre problemer var der? Dette er hvad alle containere kører som root som standard. Dette er rod ulige med rodværten af systemet.
Men hvis du indtaster containeren, vil det være root, og den fil, vi opretter i denne container, får root-rettigheder.
Hvis udvikleren gik ind i containeren og lavede nogle kommandoer der, der genererer filer, og forlod containeren, så har han en fil i sin arbejdsmappe, som han ikke har adgang til.
Hvordan kan det løses? Du kan tilføje brugere, der vil være i containeren.
Hvilke problemer opstod, da vi tilføjede brugeren?
Når vi opretter en bruger, har vi ofte ikke samme gruppe-id (UID) og bruger-id (GID).
For at løse dette problem i containeren bruger vi brugere med ID 1000.
I vores tilfælde faldt dette sammen med det faktum, at næsten alle udviklere bruger Ubuntu OS. Og på Ubuntu har den første bruger et ID på 1000.
Har vi planer?
Læs Docker-dokumentationen. Projektet udvikler sig aktivt, dokumentationen ændrer sig. De data, der blev modtaget for to eller tre måneder siden, er allerede langsomt ved at være forældede.
Nogle af de problemer, vi løste, er muligvis allerede løst med standardmidler.
Så jeg vil allerede nu gå videre for at gå direkte til orkestreringen.
Et eksempel er Dockers indbyggede mekanisme kaldet Docker Swarm, som kommer ud af æsken. Jeg vil køre noget i produktion baseret på Docker Swarm-teknologi.
Gydebeholdere gør det ubelejligt at arbejde med træstammer. Nu er stokkene isoleret. De er spredt ud over containere. En af opgaverne er at give nem adgang til loggene via webgrænsefladen.
Kilde: www.habr.com