Utviklings- og testprosess med Docker og Gitlab CI

Jeg foreslår å lese utskriften av rapporten av Alexander Sigachev fra Inventos "Utviklings- og testprosess med Docker + Gitlab CI"

De som akkurat har begynt å implementere utviklings- og testprosessen basert på Docker + Gitlab CI stiller ofte grunnleggende spørsmål. Hvor skal jeg begynne? Hvordan organisere? Hvordan teste?

Denne rapporten er bra fordi den snakker på en strukturert måte om utviklings- og testprosessen ved bruk av Docker og Gitlab CI. Selve rapporten er fra 2017. Jeg tror at fra denne rapporten kan du lære det grunnleggende, metodikk, idé, erfaring med bruk.

Hvem bryr seg, vær så snill under katten.

Mitt navn er Alexander Sigachev. Jeg jobber for Inventos. Jeg vil fortelle deg om min erfaring med å bruke Docker og hvordan vi gradvis implementerer det på prosjekter i selskapet.

Presentasjonsemne: Utviklingsprosess ved bruk av Docker og Gitlab CI.

Dette er mitt andre foredrag om Docker. På tidspunktet for den første rapporten brukte vi bare Docker i utvikling på utviklermaskiner. Antall ansatte som brukte Docker var ca 2-3 personer. Etter hvert ble det høstet erfaringer og vi rykket litt lenger. Link til vår første rapport.

Hva vil stå i denne rapporten? Vi vil dele vår erfaring om hvilken rake vi har samlet, hvilke problemer vi har løst. Ikke overalt var det vakkert, men lov til å gå videre.

Vårt motto er: dokke alt vi kan få tak i.

Hvilke problemer løser vi?

Når det er flere team i en bedrift, er programmereren en delt ressurs. Det er stadier når en programmerer trekkes ut av ett prosjekt og gis for en tid til et annet prosjekt.

For at programmereren raskt skal forstå, må han laste ned kildekoden til prosjektet og starte miljøet så snart som mulig, noe som vil tillate ham å gå videre med å løse problemene med dette prosjektet.

Vanligvis, hvis du starter fra scratch, så er det lite dokumentasjon i prosjektet. Informasjon om hvordan du setter opp er kun tilgjengelig for gammeldagse. Ansatte setter opp arbeidsplassen sin på egenhånd i løpet av en eller to dager. For å få fart på dette brukte vi Docker.

Den neste grunnen er standardisering av innstillinger i utvikling. Min erfaring er at utviklere alltid tar initiativet. I hvert femte tilfelle legges det inn et tilpasset domene, for eksempel vasya.dev. Ved siden av ham sitter naboen Petya, hvis domene er petya.dev. De utvikler et nettsted eller en del av systemet ved å bruke dette domenenavnet.

Når systemet vokser og disse domenenavnene begynner å komme inn i konfigurasjoner, oppstår en utviklingsmiljøkonflikt og nettstedstien skrives om.

Det samme skjer med databaseinnstillinger. Noen bryr seg ikke om sikkerhet og jobber med et tomt root-passord. På installasjonsstadiet spurte MySQL noen om et passord, og passordet viste seg å være 123. Det hender ofte at databasekonfigurasjonen stadig endres avhengig av utviklerens forpliktelse. Noen korrigerte, noen korrigerte ikke konfigurasjonen. Det var triks når vi tok ut en slags testkonfigurasjon .gitignore og hver utvikler måtte installere databasen. Dette gjorde det vanskelig å komme i gang. Det er nødvendig blant annet å huske på databasen. Databasen må initialiseres, et passord må angis, en bruker må være registrert, en tabell må opprettes, og så videre.

Et annet problem er forskjellige versjoner av biblioteker. Det hender ofte at en utvikler jobber med ulike prosjekter. Det er et Legacy-prosjekt som startet for fem år siden (fra 2017 – red.anm.). På lanseringstidspunktet startet vi med MySQL 5.5. Det finnes også moderne prosjekter hvor vi prøver å implementere mer moderne versjoner av MySQL, for eksempel 5.7 eller eldre (i 2017 – red.anm.)

Alle som jobber med MySQL vet at disse bibliotekene tar med seg avhengigheter. Det er ganske problematisk å kjøre 2 baser sammen. I det minste er gamle klienter problematiske å koble til den nye databasen. Dette skaper igjen flere problemer.

Det neste problemet er når en utvikler jobber på en lokal maskin, han bruker lokale ressurser, lokale filer, lokal RAM. All interaksjon på tidspunktet for utvikling av en løsning på problemer utføres innenfor rammen av at den fungerer på én maskin. Et eksempel er når vi har backend-servere i produksjon 3, og utvikleren lagrer filer til rotkatalogen og derfra tar nginx filer for å svare på forespørselen. Når en slik kode kommer inn i produksjon, viser det seg at filen finnes på en av de 3 serverne.

Retningen til mikrotjenester utvikler seg nå. Når vi deler opp våre store applikasjoner i noen små komponenter som samhandler med hverandre. Dette lar deg velge teknologier for en spesifikk stabel med oppgaver. Det lar deg også dele arbeid og ansvar mellom utviklere.

Frondend-utvikler, som utvikler på JS, har nesten ingen innflytelse på Backend. Backend-utvikleren utvikler på sin side, i vårt tilfelle, Ruby on Rails og forstyrrer ikke Frondend. Interaksjonen utføres ved hjelp av API.

Som en bonus, ved hjelp av Docker, var vi i stand til å resirkulere ressurser på Staging. Hvert prosjekt, på grunn av dets spesifikasjoner, krevde visse innstillinger. Fysisk var det nødvendig å tildele enten en virtuell server og konfigurere dem separat, eller å dele et slags variabelt miljø og prosjekter kunne, avhengig av versjonen av bibliotekene, påvirke hverandre.

Verktøy. Hva bruker vi?

• Docker selv. Dockerfilen beskriver avhengighetene til en enkelt applikasjon.
• Docker-compose er en pakke som samler noen av våre Docker-applikasjoner.
• Vi bruker GitLab til å lagre kildekoden.
• Vi bruker GitLab-CI for systemintegrasjon.

Rapporten består av to deler.

Den første delen vil snakke om hvordan Docker ble kjørt på utviklernes maskiner.

Den andre delen vil snakke om hvordan man samhandler med GitLab, hvordan vi kjører tester og hvordan vi ruller ut til Staging.

Docker er en teknologi som tillater (ved å bruke en deklarativ tilnærming) å beskrive de nødvendige komponentene. Dette er et eksempel på Dockerfile. Her erklærer vi at vi arver fra det offisielle Ruby:2.3.0 Docker-bildet. Den inneholder Ruby versjon 2.3 installert. Vi installerer de nødvendige byggebibliotekene og NodeJS. Vi beskriver at vi lager en katalog /app. Angi appkatalogen som arbeidskatalogen. I denne katalogen plasserer vi den nødvendige minimale Gemfile og Gemfile.lock. Vi bygger deretter prosjektene som installerer dette avhengighetsbildet. Vi indikerer at containeren vil være klar til å lytte på ekstern port 3000. Den siste kommandoen er kommandoen som direkte starter applikasjonen vår. Hvis vi utfører prosjektstart-kommandoen, vil applikasjonen prøve å kjøre og kjøre den angitte kommandoen.

Dette er et minimalt eksempel på en docker-compose-fil. I dette tilfellet viser vi at det er en sammenheng mellom to containere. Dette er direkte inn i databasetjenesten og webtjenesten. Våre nettapplikasjoner krever i de fleste tilfeller en slags database som backend for lagring av data. Siden vi bruker MySQL, er eksemplet med MySQL - men ingenting hindrer oss i å bruke en annen database (PostgreSQL, Redis).

Vi tar fra den offisielle kilden fra Docker-huben bildet av MySQL 5.7.14 uten endringer. Vi samler bildet som er ansvarlig for vår nettapplikasjon fra gjeldende katalog. Den samler et bilde for oss under den første lanseringen. Deretter kjører den kommandoen som vi kjører her. Hvis vi går tilbake, vil vi se at lanseringskommandoen via Puma er definert. Puma er en tjeneste skrevet i Ruby. I det andre tilfellet overstyrer vi. Denne kommandoen kan være vilkårlig avhengig av våre behov eller oppgaver.

Vi beskriver også at vi må videresende en port på utviklervertsmaskinen vår fra 3000 til 3000 på containerporten. Dette gjøres automatisk ved hjelp av iptables og dens mekanisme, som er direkte innebygd i Docker.

Utvikleren kan også, som før, få tilgang til enhver tilgjengelig IP-adresse, for eksempel er 127.0.0.1 den lokale eller eksterne IP-adressen til maskinen.

Den siste linjen sier at nettbeholderen er avhengig av db-beholderen. Når vi kaller starten av nettbeholderen, starter docker-compose først databasen for oss. Allerede ved starten av databasen (faktisk, etter lanseringen av containeren! Dette garanterer ikke beredskapen til databasen) vil starte applikasjonen, vår backend.

Dette unngår feil når databasen ikke er hentet og sparer ressurser når vi stopper databasebeholderen, og frigjør dermed ressurser til andre prosjekter.

Hva gir oss bruk av databasedokking på prosjektet. Vi fikser versjonen av MySQL for alle utviklere. Dette unngår noen feil som kan oppstå når versjoner avviker, når syntaks, konfigurasjon, standardinnstillinger endres. Dette lar deg spesifisere et felles vertsnavn for databasen, pålogging, passord. Vi beveger oss bort fra dyrehagen av navn og konflikter i konfigurasjonsfilene som vi hadde tidligere.

Vi har muligheten til å bruke en mer optimal konfigurasjon for utviklingsmiljøet, som vil avvike fra standard. MySQL er konfigurert for svake maskiner som standard, og ytelsen ut av boksen er svært dårlig.

Docker lar deg bruke Python, Ruby, NodeJS, PHP-tolken til ønsket versjon. Vi slipper behovet for å bruke en slags versjonsbehandler. Tidligere brukte Ruby en rpm-pakke som tillot deg å endre versjonen avhengig av prosjektet. Den tillater også, takket være Docker-beholderen, å jevnt migrere koden og versjonere den sammen med avhengigheter. Vi har ingen problemer med å forstå versjonen av både tolken og koden. For å oppdatere versjonen, senk den gamle beholderen og hev den nye beholderen. Hvis noe gikk galt, kan vi senke den nye beholderen, heve den gamle beholderen.

Etter å ha bygget bildet vil beholderne i både utvikling og produksjon være de samme. Dette gjelder spesielt for store installasjoner.

På Frontend bruker vi JavaScipt og NodeJS.

Nå har vi det siste prosjektet på ReacJS. Utvikleren kjørte alt i containeren og utviklet ved hjelp av hot-reload.

Deretter lanseres JavaScipt-monteringsoppgaven og koden kompilert til statikk gis gjennom nginx-lagringsressurser.

Her har jeg gitt opplegget til vårt siste prosjekt.

Hvilke oppgaver ble løst? Vi hadde et behov for å bygge et system som mobile enheter samhandler med. De mottar data. En mulighet er å sende push-varsler til denne enheten.

Hva har vi gjort for dette?

Vi delte inn i applikasjonen slike komponenter som: admin-delen på JS, backend, som fungerer gjennom REST-grensesnittet under Ruby on Rails. Backend samhandler med databasen. Resultatet som genereres gis til klienten. Administrasjonspanelet samhandler med backend og databasen via REST-grensesnittet.

Vi hadde også behov for å sende push-varsler. Før det hadde vi et prosjekt som implementerte en mekanisme som er ansvarlig for å levere varsler til mobile plattformer.

Vi har utviklet følgende opplegg: en operatør fra nettleseren samhandler med adminpanelet, adminpanelet samhandler med backend, oppgaven er å sende push-varsler.

Push-varsler samhandler med en annen komponent som er implementert i NodeJS.

Køer bygges og deretter sendes varsler i henhold til deres mekanisme.

To databaser er tegnet her. For øyeblikket bruker vi ved hjelp av Docker 2 uavhengige databaser som ikke er relatert til hverandre på noen måte. I tillegg har de et felles virtuelt nettverk, og fysiske data lagres i ulike kataloger på utviklerens maskin.

Det samme, men i antall. Det er her gjenbruk av kode er viktig.

Hvis vi tidligere har snakket om gjenbruk av kode i form av biblioteker, så blir tjenesten vår som svarer på Push-varsler i dette eksempelet gjenbrukt som en komplett server. Det gir en API. Og vår nye utvikling samhandler allerede med den.

På den tiden brukte vi versjon 4 av NodeJS. Nå (i 2017 – red.anm.) i nyere utvikling bruker vi versjon 7 av NodeJS. Det er ikke noe problem i nye komponenter å involvere nye versjoner av biblioteker.

Om nødvendig kan du refaktorere og heve NodeJS-versjonen fra Push-varslingstjenesten.

Og hvis vi kan opprettholde API-kompatibilitet, vil det være mulig å erstatte det med andre prosjekter som tidligere ble brukt.

Hva trenger du for å legge til Docker? Vi legger til en Dockerfile i vårt depot, som beskriver de nødvendige avhengighetene. I dette eksemplet er komponentene brutt ned logisk. Dette er minimumssettet til en backend-utvikler.

Når vi oppretter et nytt prosjekt, lager vi en Dockerfile, beskriver ønsket økosystem (Python, Ruby, NodeJS). I docker-compose beskriver den den nødvendige avhengigheten - databasen. Vi beskriver at vi trenger en database med en slik og en versjon, lagrer data der og der.

Vi bruker en separat tredje beholder med nginx for å tjene statisk. Det er mulig å laste opp bilder. Backend legger dem i et forhåndsforberedt volum, som også er montert i en beholder med nginx, som gir det statiske.

For å lagre nginx, mysql-konfigurasjonen, la vi til en Docker-mappe der vi lagrer de nødvendige konfigurasjonene. Når en utvikler gjør en git-kloning av et depot på maskinen sin, har han allerede et prosjekt klart for lokal utvikling. Det er ingen tvil om hvilken port eller hvilke innstillinger som skal brukes.

Deretter har vi flere komponenter: admin, inform-API, push-varsler.

For å starte alt dette opprettet vi et annet depot, som vi kalte dockerized-app. For øyeblikket bruker vi flere depoter før hver komponent. De er bare logisk forskjellige - i GitLab ser det ut som en mappe, men på utviklerens maskin, en mappe for et spesifikt prosjekt. Ett nivå ned er komponentene som skal kombineres.

Dette er et eksempel på bare innholdet i dockerisert app. Vi tar også med Docker-katalogen her, der vi fyller ut konfigurasjonene som kreves for samhandlingen til alle komponentene. Det er en README.md som kort beskriver hvordan du kjører prosjektet.

Her har vi brukt to docker-compose-filer. Dette gjøres for å kunne kjøre i trinn. Når en utvikler jobber med kjernen, trenger han ikke push-varsler, han starter ganske enkelt en docker-compose-fil og følgelig lagres ressursen.

Hvis det er behov for å integrere med push-varsler, lanseres docker-compose.yaml og docker-compose-push.yaml.

Siden docker-compose.yaml og docker-compose-push.yaml er i en mappe, opprettes et enkelt virtuelt nettverk automatisk.

Beskrivelse av komponenter. Dette er en mer avansert fil som er ansvarlig for innsamlingen av komponenter. Hva er bemerkelsesverdig her? Her introduserer vi balanseringskomponenten.

Dette er et ferdig Docker-bilde som kjører nginx og et program som lytter på Docker-kontakten. Dynamisk, når beholdere slås av og på, regenererer den nginx-konfigurasjonen. Vi distribuerer håndteringen av komponenter etter domenenavn på tredje nivå.

For utviklingsmiljøet bruker vi .dev-domenet - api.informer.dev. Applikasjoner med et .dev-domene er tilgjengelig på utviklerens lokale maskin.

Videre overføres konfigurasjoner til hvert prosjekt og alle prosjekter lanseres samtidig.

Grafisk viser det seg at klienten er nettleseren vår eller et verktøy som vi sender forespørsler til balansereren med.

Domenenavnsbalanseren bestemmer hvilken beholder som skal kontaktes.

Det kan være nginx, som gir admin JS. Dette kan være nginx, som gir API, eller statiske filer, som gis til nginx i form av bildeopplastinger.

Diagrammet viser at containerne er koblet sammen med et virtuelt nettverk og skjult bak en proxy.

På utviklerens maskin kan du få tilgang til containeren og vite IP-en, men i prinsippet bruker vi ikke dette. Det er praktisk talt ikke behov for direkte tilgang.

Hvilket eksempel skal du se på for å dokke applikasjonen din? Etter min mening er et godt eksempel det offisielle docker-bildet for MySQL.

Det er ganske utfordrende. Det er mange versjoner. Men funksjonaliteten lar deg dekke mange behov som kan oppstå i prosessen med videre utvikling. Hvis du bruker tid og finner ut hvordan det hele virker sammen, så tror jeg du ikke vil ha noen problemer med selvimplementering.

Hub.docker.com inneholder vanligvis lenker til github.com, som inneholder rådata direkte som du kan bygge bildet selv fra.

Videre i dette depotet er det et docker-endpoint.sh-skript, som er ansvarlig for den første initialiseringen og for videre behandling av applikasjonsoppstarten.

Også i dette eksemplet er det muligheten til å konfigurere ved hjelp av miljøvariabler. Ved å definere en miljøvariabel når du kjører en enkelt container eller gjennom docker-compose, kan vi si at vi må sette et tomt passord for docker til å rote på MySQL eller hva vi måtte ønske.

Det er en mulighet for å lage et tilfeldig passord. Vi sier at vi trenger en bruker, vi må sette et passord for brukeren, og vi må lage en database.

I våre prosjekter har vi litt forenet Dockerfile, som er ansvarlig for initialisering. Der korrigerte vi det til våre behov for å gjøre det bare en utvidelse av brukerrettighetene som applikasjonen bruker. Dette tillot oss å ganske enkelt lage en database fra applikasjonskonsollen senere. Ruby-applikasjoner har en kommando for å lage, endre og slette databaser.

Dette er et eksempel på hvordan en spesifikk versjon av MySQL ser ut på github.com. Du kan åpne Dockerfilen og se hvordan installasjonen foregår der.

docker-endpoint.sh er skriptet som er ansvarlig for inngangspunktet. Under den første initialiseringen kreves noen forberedelsestrinn, og alle disse handlingene utføres bare i initialiseringsskriptet.

La oss gå videre til den andre delen.

For å lagre kildekodene byttet vi til gitlab. Dette er et ganske kraftig system som har et visuelt grensesnitt.

En av komponentene i Gitlab er Gitlab CI. Den lar deg beskrive en sekvens av kommandoer som senere vil bli brukt til å organisere et kodeleveringssystem eller kjøre automatisk testing.

Gitlab CI 2 talk https://goo.gl/uohKjI - rapport fra Ruby Russia-klubben - ganske detaljert og kanskje det vil interessere deg.

Nå skal vi se på hva som kreves for å aktivere Gitlab CI. For å starte Gitlab CI trenger vi bare å legge .gitlab-ci.yml-filen i roten til prosjektet.

Her beskriver vi at vi ønsker å utføre en sekvens av tilstander som en test, distribuere.

Vi kjører skript som direkte kaller docker-compose for å bygge applikasjonen vår. Dette er bare et backend-eksempel.

Deretter sier vi at det er nødvendig å kjøre migreringer for å endre databasen og kjøre tester.

Hvis skriptene kjøres riktig og ikke returnerer en feilkode, fortsetter systemet til andre trinn av distribusjonen.

Utrullingsstadiet er for øyeblikket implementert for iscenesettelse. Vi organiserte ikke en omstart uten nedetid.

Vi tvangsslukker alle beholdere, og så hever vi alle beholderne igjen, samlet på første trinn under testing.

Vi kjører for gjeldende miljøvariabel databasemigreringene som ble skrevet av utviklerne.

Det er en merknad om at dette kun gjelder hovedgrenen.

Ved endring av andre grener utføres ikke.

Det er mulig å organisere utrullinger etter filialer.

For å organisere dette videre, må vi installere Gitlab Runner.

Dette verktøyet er skrevet på Golang. Det er en enkelt fil, som er vanlig i Golang-verdenen, som ikke krever noen avhengigheter.

Ved oppstart registrerer vi Gitlab Runner.

Vi får nøkkelen i Gitlabs nettgrensesnitt.

Deretter kaller vi initialiseringskommandoen på kommandolinjen.

Sett opp Gitlab Runner interaktivt (Shell, Docker, VirtualBox, SSH)

Koden på Gitlab Runner vil kjøre på hver commit, avhengig av .gitlab-ci.yml-innstillingen.

Hvordan det ser ut visuelt i Gitlab i nettgrensesnittet. Etter at vi har koblet til GItlab CI, har vi et flagg som viser tilstanden til bygget for øyeblikket.

Vi ser at det ble gjort en commit for 4 minutter siden, som besto alle testene og ikke skapte noen problemer.

Vi kan se nærmere på byggene. Her ser vi at to stater allerede har passert. Teststatus og distribusjonsstatus på iscenesettelse.

Hvis vi klikker på et spesifikt bygg, vil det være en konsollutgang av kommandoene som ble kjørt i prosessen i henhold til .gitlab-ci.yml.

Slik ser produkthistorien vår ut. Vi ser at det var vellykkede forsøk. Når tester sendes inn, fortsetter den ikke til neste trinn, og oppsamlingskoden blir ikke oppdatert.

Hvilke oppgaver løste vi på iscenesettelse da vi implementerte docker? Systemet vårt består av komponenter og vi hadde et behov for å starte på nytt, kun deler av komponentene som ble oppdatert i depotet, og ikke hele systemet.

For å gjøre dette, måtte vi knuse alt i separate mapper.

Etter at vi gjorde dette, hadde vi et problem med at Docker-compose lager sitt eget nettverksrom for hver pappa og ikke ser naboens komponenter.

For å komme oss rundt opprettet vi nettverket i Docker manuelt. Det ble skrevet i Docker-compose at du bruker et slikt nettverk for dette prosjektet.

Dermed ser hver komponent som starter med dette nettet komponenter i andre deler av systemet.

Den neste utgaven er å dele opp scenen på tvers av flere prosjekter.

Siden for at alt dette skal se vakkert ut og så nært produksjonen som mulig, er det greit å bruke port 80 eller 443, som brukes overalt i WEB.

Hvordan løste vi det? Vi har tildelt én Gitlab Runner til alle større prosjekter.

Gitlab lar deg kjøre flere distribuerte Gitlab-løpere, som ganske enkelt tar alle oppgavene etter tur på en kaotisk måte og kjører dem.

For at vi ikke har et hus, begrenset vi gruppen av prosjektene våre til én Gitlab Runner, som takler volumene våre uten problemer.

Vi flyttet nginx-proxy til et eget oppstartsskript og la til rutenett for alle prosjekter i det.

Prosjektet vårt har ett rutenett, og balanseren har flere rutenett etter prosjektnavn. Det kan proxy videre ved domenenavn.

Våre forespørsler kommer gjennom domenet på port 80 og blir løst til en containergruppe som betjener dette domenet.

Hvilke andre problemer var det? Dette er hva alle containere kjører som root som standard. Dette er rotulik med rotverten til systemet.

Men hvis du går inn i beholderen, vil det være root og filen vi oppretter i denne beholderen får root-rettigheter.

Hvis utvikleren gikk inn i beholderen og gjorde noen kommandoer der som genererer filer, og forlot beholderen, så har han en fil i arbeidskatalogen han ikke har tilgang til.

Hvordan kan det løses? Du kan legge til brukere som skal være i beholderen.

Hvilke problemer oppsto da vi la til brukeren?

Når vi oppretter en bruker, har vi ofte ikke samme gruppe-ID (UID) og bruker-ID (GID).

For å løse dette problemet i containeren bruker vi brukere med ID 1000.

I vårt tilfelle falt dette sammen med det faktum at nesten alle utviklere bruker Ubuntu OS. Og på Ubuntu har den første brukeren en ID på 1000.

Har vi planer?

Les Docker-dokumentasjonen. Prosjektet utvikler seg aktivt, dokumentasjonen er i endring. Dataene som ble mottatt for to eller tre måneder siden er allerede sakte i ferd med å bli utdaterte.

Noen av problemene vi løste er muligens allerede løst med standard midler.

Så jeg ønsker å gå videre allerede for å gå direkte til orkestreringen.

Et eksempel er Dockers innebygde mekanisme kalt Docker Swarm, som kommer ut av esken. Jeg vil kjøre noe i produksjon basert på Docker Swarm-teknologi.

Gytebeholdere gjør det upraktisk å jobbe med tømmerstokker. Nå er stokkene isolert. De er spredt utover containere. En av oppgavene er å gi enkel tilgang til loggene gjennom nettgrensesnittet.

Kilde: www.habr.com