Jeg vil gerne præsentere transskriptionen af Alexander Sigachevs foredrag fra Inventos «Udviklings- og testprocessen 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 starte? Hvordan organiserer man det? Hvordan tester man?
Dette foredrag er værdifuldt, da det struktureret fortæller om udvikling og test med brug af Docker og Gitlab CI. Selve foredraget er fra 2017. Jeg tror, at man kan hente grundlæggende viden, metodologi, idé og erfaring fra dette foredrag.
Hvis nogen er interesseret, så kom ind under kat.
Mit navn er Alexander Sigachev. Jeg arbejder i virksomheden Inventos. Jeg vil fortælle om min erfaring med Docker og hvordan vi langsomt implementerer det i projekter i virksomheden.
Emnet for foredraget: Udviklingsprocessen med brug af Docker og Gitlab CI.
Dette er mit andet foredrag om Docker. På tidspunktet for det første foredrag brugte vi Docker kun i udviklingen på udviklernes maskiner. Antallet af medarbejdere, der brugte Docker, var omkring 2-3 personer. Gradvis har vi opnået erfaring, og vi er kommet lidt videre. Link til vores .
Hvad vil der være i dette foredrag? Vi vil dele vores erfaring omkring hvilke udfordringer vi har samlet, hvilke problemer vi har løst. Det har ikke altid været smukt, men det har gjort det muligt at komme videre.
Vores motto: dockeriser alt, hvad vores hænder rækker ud efter.
Hvilke problemer løser vi?
Når der er flere teams i virksomheden, er programmøren en delt ressource. Der er tidspunkter, hvor programmøren trækkes ud af et projekt og gives til et andet projekt i en periode.
For at programmøren hurtigt kan sætte sig ind i det, er det nødvendigt at downloade koden fra projektet og så hurtigt som muligt starte et miljø, der gør det muligt for ham at fortsætte med at løse opgaverne i dette projekt.
Normalt, hvis man starter fra bunden, er der ikke meget dokumentation i projektet. Oplysninger om, hvordan man konfigurerer, findes kun hos de erfarne. Medarbejdere opsætter selv deres arbejdsplads på en til to dage. For at fremskynde dette har vi anvendt Docker.
Den næste årsag er standardiseringen af indstillinger i udviklingen. Efter min erfaring tager udviklerne altid initiativ. I hver femte sag introduceres et brugerdefineret domæne, for eksempel vasya.dev. Ved siden af sidder naboen Petja, der har domænet petya.dev. De udvikler en hjemmeside eller et systemkomponent ved at bruge dette domænenavn.
Når systemet vokser, og disse domænenavne begynder at komme ind i konfigurationerne, opstår der konflikter i udviklingsmiljøerne, og stien til hjemmesiden bliver overskrevet.
Det samme sker med databaseindstillingerne. Nogen tænker ikke over sikkerheden og arbejder med root-adgangskoden som tom. For nogen, da MySQL blev installeret, blev der krævet en adgangskode, og den viste sig at være 123. Det sker ofte, at databasekonfigurationen konstant bliver ændret afhængigt af udviklerens commit. Nogen har rettet det, nogen har ikke rettet konfigureringen. Der var tricks, hvor vi tog en testkonfiguration og .gitignore hver udvikler skulle installere databasen. Det gjorde opstartsprocessen mere kompliceret. Udover alt andet skal man huske på databasen. Databasen skal initialiseres, adgangskoden skal angives, brugeren skal angives, tabellen skal oprettes og så videre.
En anden af problemerne er de forskellige versioner af bibliotekerne. Det sker ofte, at udvikleren arbejder med forskellige projekter. Der er et Legacy-projekt, som blev påbegyndt for fem år siden (fra 2017 — bemærk red.). På tidspunktet for starten, blev der startet 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 nyere (i 2017 — bemærk red.).
Den, der arbejder med MySQL, ved, at disse biblioteker medfører afhængigheder. Det er ret problematisk at køre to databaser sammen. I det mindste er det problematisk at forbinde gamle klienter til den nye database. Dette skaber i sin tur flere problemer.
Det næste problem er, at når udvikleren arbejder på sin lokale maskine, bruger han lokale ressourcer, lokale filer, lokal RAM. Al interaktion under udviklingen af løsningen foregår inden for rammerne af, at det kører på én maskine. Et eksempel kunne være, når vi har 3 backend-servere i produktion, og udvikleren gemmer filer i roden, som nginx henter for at svare på forespørgsler. Når sådan en kode går i produktion, får vi, at filen kun er tilgængelig på en af de 3 servere.
I øjeblikket udvikles retningen mod mikrotjenester. Når vi opdeler vores store applikationer i mindre komponenter, der interagerer med hinanden. Dette muliggør at vælge teknologier specifikt til den givne opgave. Det gør også, at arbejdet og ansvarsområderne kan opdeles blandt udviklerne.
Frontend-udvikleren, der udvikler i JS, påvirker praktisk talt ikke Backend. Backend-udvikleren udvikler i vores tilfælde Ruby on Rails og forstyrrer ikke Frontend. Interaktionen sker via API.
Som en bonus har vi ved hjælp af Docker været i stand til at optimere ressourcerne på Staging. Hver projekt kræver bestemte indstillinger på grund af sin specifik. Fysisk skulle der allokeres enten en virtuel server, der skulle konfigureres hver for sig, eller man skulle dele et nært miljø, og projekterne kunne påvirke hinanden afhængigt af versionerne af bibliotekerne.
Værktøjer. Hvad bruger vi?
- Selve Docker. I Dockerfile beskrives afhængighederne for én applikation.
- Docker-compose er forbindelsen, der forener flere af vores Docker-applikationer.
- GitLab bruger vi til opbevaring af kildekoden.
- GitLab-CI bruger vi til systemintegration.
Præsentationen består af to dele.
Den første del vil fortælle om, hvordan vi kørte Docker på udviklernes maskiner.
Den anden del vil fortælle om, hvordan man interagerer med GitLab, hvordan vi kører tests og hvordan vi implementerer på Staging.
Docker er denne teknologi, der gør det muligt (ved at bruge en deklarativ tilgang) at beskrive de nødvendige komponenter. Dette er et eksempel på en Dockerfile. Her erklærer vi, at vi arver fra det officielle Docker-billede Ruby:2.3.0. Det indeholder den installerede Ruby version 2.3. Vi installerer de nødvendige biblioteker til opbygning og NodeJS. Vi beskriver, at vi opretter et bibliotek. /appVi udpeger app-katalogen som arbejdsmappen. I denne mappe placerer vi den nødvendige minimale Gemfile og Gemfile.lock. Derefter bygger vi projekterne, der installerer denne afhængighed. Vi angiver, at containeren skal være klar til at lytte på den eksterne port 3000. Den sidste kommando er den, der direkte starter vores applikation. Hvis vi udfører kommandoen for at starte projektet, vil applikationen forsøge at køre og udføre den angivne kommando.
Dette er et minimalt eksempel på en docker-compose-fil. I dette tilfælde viser vi, hvad der sker ved forbindelsen mellem to containere. Dette er direkte service til databasen og webtjenesten. Vores webapplikationer kræver i de fleste tilfælde en form for backend-database til opbevaring af data. Da vi bruger MySQL, er eksemplet med MySQL — men intet forhindrer os i at bruge en anden database (PostgreSQL, Redis).
Vi henter en uændret MySQL 5.7.14-billede fra den officielle kilde fra Docker Hub. Billedet, der er ansvarligt for vores webapplikation, opbygges fra den nuværende mappe. Ved første opstart bygger den billedet for os. Derefter kører den den kommando, vi her udfører. Hvis vi ser tilbage, vil vi se, at der blev fastlagt en opstartskommando via Puma. Puma er en service skrevet i Ruby. I det andet tilfælde ændrer vi. Denne kommando kan være vilkårlig alt efter vores behov eller opgaver.
Vi beskriver også, at vi skal videregive porten fra vores udviklerhjemmesystem fra port 3000 til containerens port 3000. Dette udføres automatisk ved hjælp af iptables og sin mekanisme, der er forankret i Docker.
Udvikleren kan som før tilgå enhver tilgængelig IP-adresse, for eksempel den lokale 127.0.0.1 eller maskinens eksterne IP-adresse.
Den sidste linje siger, at webcontaineren afhænger af db-containeren. Når vi kalder på at starte webcontaineren, vil docker-compose først starte databasen for os. Når databasen er startet (faktisk — efter containeren er startet! Dette garanterer ikke databasens klarhed) vil applikationen, vores backend, starte.
Dette hjælper med at undgå fejl, når databasen ikke er startet, og gør det muligt at spare ressourcer, når vi stopper databasecontaineren og dermed frigør ressourcer til andre projekter.
Hvad giver brugen af database-dockerisering os i projektet. Vi angiver versionen af MySQL for alle udviklere. Dette hjælper med at undgå visse fejl, der kan opstå ved versionsforskelle, når syntaks, konfiguration og standardindstillinger ændres. Det muliggør angivelse af fælles hostname for databasen, login og password. Vi fjerner os fra det kaos af navne og konflikter i konfigurationsfiler, som vi havde tidligere.
Vi har mulighed for at anvende en mere optimal konfiguration til udviklingsmiljøet, der adskiller sig fra standardkonfigurationen. MySQL er som standard indstillet til svage maskiner, og dens ydeevne er meget lav lige fra starten.
Docker gør det muligt at bruge den ønskede version af Python, Ruby, NodeJS, PHP. Vi slipper for behovet for at bruge en version manager. Tidligere brugte vi rpm-pakker til Ruby, som gjorde det muligt at ændre versionen afhængigt af projektet. Det muliggør også, takket være Docker-containeren, en glidende migrering af kode og versionering sammen med afhængigheder. Vi har ikke problemer med at forstå versionen af både interpreter og kode. For at opdatere versionen skal vi stoppe den gamle container og starte den nye container. Hvis noget går galt, kan vi stoppe den nye container og starte den gamle container.
Efter opbygningen af billedet vil containerne både i udvikling og produktion være identiske. Dette er særligt vigtigt for store installationer.
På frontend bruger vi JavaScript og NodeJS.
Vores seneste projekt er lavet med ReactJS. Udvikleren kørte alle containere og udviklede ved hjælp af hot-reload.
Derefter startes opgaven med at kompilere JavaScript, og den kompilerede kode leveres som statisk gennem nginx for at spare ressourcer.
Her præsenterer jeg skemaet for vores seneste projekt.
Hvilke opgaver løste vi? Vi havde behov for at opbygge et system, som mobile enheder interagerer med. De modtager data. En af mulighederne er at sende push-notifikationer til enheden.
Hvilke skridt tog vi for dette?
Vi delte applikationen i komponenter som: administrationsdelen i JS, backend, der fungerer gennem REST-interface under Ruby on Rails. Backend interagerer med databasen. Resultatet, der genereres, leveres til klienten. Admin-delen interagerer med backend og databasen gennem REST-interface.
Vi havde også behov for at sende Push-notifikationer. Tidligere havde vi et projekt, hvor der blev implementeret en mekanisme til at levere meddelelser til mobile platforme.
Vi udviklede en sådan ordning: operatøren interagerer med adminpanelet fra browseren, adminpanelet interagerer med backend, og der sættes en opgave til at sende Push-notifikationer.
Push-notifikationer interagerer med en anden komponent, der er implementeret på NodeJS.
Køer opbygges, og derefter sendes notifikationerne i henhold til deres mekanisme.
Her er to databaser tegnet. I øjeblikket bruger vi med Docker to uafhængige databaser, der ikke er forbundet med hinanden, bortset fra at de har et fælles virtuelt netværk, og de fysiske data gemmes i forskellige mapper på udviklerens maskine.
Det samme, men i tal. Her er genbrug af kode vigtigt.
Hvis vi tidligere talte om genbrug af kode i form af biblioteker, så genbruges vores service, der håndterer Push-notifikationer, her som en komplet server. Den tilbyder et API, og vores nye udvikling interagerer med det.
På det tidspunkt brugte vi version 4 af NodeJS. I dag (i 2017 — red. anm.) bruger vi version 7 af NodeJS i nye projekter. Der er ingen problemer med at trække nye versioner af biblioteker ind i nye komponenter.
Ved behov kan vi refaktorere og opgradere NodeJS-versionen for Push-notifikationsservicen.
Og hvis vi kan bevare API-kompatibilitet, kan den erstattes i andre projekter, der blev brugt tidligere.
Hvad er nødvendigt 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 efter logik. Dette er et minimumssæt for backend-udvikleren.
Når vi opretter et nyt projekt, opretter vi en Dockerfile, der beskriver den nødvendige økosystem (Python, Ruby, NodeJS). I docker-compose beskriver vi den nødvendige afhængighed — databasen. Vi beskriver, at vi har brug for en database af en bestemt version og at gemme data der.
Vi bruger en separat tredje container med nginx til at servere statiske filer. Der er mulighed for at uploade billeder. Backend'en placerer dem i et forberedt volumen, som også er monteret i nginx containeren, som serverer statiske filer.
For storing the configuration of nginx and mysql, we added a Docker folder where we keep the necessary configs. When a developer clones the repository to their machine, they receive a project that is ready for local development. There’s no question about which port or which settings to apply.
Next, we have several components: admin, inform-API, push notifications.
To launch all of this, we created another repository called dockerized-app. Currently, we are using several repositories for each component. They simply differ logically — in GitLab, it appears as a folder, and on the developer's machine, it is a folder for a specific project. At a lower level are the components that will be unified.
This is an example of the contents of dockerized-app. We also take out the Docker directory here, where we fill in the configurations required for interactions of all components. There is a README.md that gives a brief description of how to run the project.
Here, we applied two docker-compose files. This is done to have the option to launch stepwise. When a developer works with the core, they do not need Push notifications, so they just launch the docker-compose file, saving resources accordingly.
If there is a need for integration with Push notifications, then docker-compose.yaml and docker-compose-push.yaml are started.
Since docker-compose.yaml and docker-compose-push.yaml are in the folder, a single virtual network is automatically created.
Description of the components. This is a more detailed file that is responsible for gathering the components. What’s notable here? We are introducing the load balancer component.
This is a ready-made Docker image that runs nginx and the application that listens to the Docker socket. It dynamically regenerates the nginx config as containers are started and stopped. We distribute interactions with components across third-level domain names.
For the Development environment, we use the domain .dev — api.informer.dev. Applications with the .dev domain are accessible on the developer's local machine.
Next, the configs are transferred to each project and all the projects are started simultaneously.
If we were to visualize it, the client would be our browser or some tool through which we make requests to the load balancer.
The load balancer determines which container to contact based on the domain name.
Dette kan være nginx, der leverer JS-administrationsgrænseflade. Det kan være nginx, der leverer API'er eller statiske filer, som nginx leverer som billeddownloads.
På diagrammet kan man se, at containerne er forbundet til et virtuelt netværk og skjult bag en proxy.
På udviklerens maskine kan man få adgang til containeren, hvis man kender IP-adressen, men vi bruger det grundlæggende ikke. Behovet for direkte adgang opstår næsten aldrig.
Hvilket eksempel skal man se for at dockerisere sin applikation? Efter min mening er det officielle Docker-billede til MySQL et godt eksempel.
Det er ret komplekst. Der er mange versioner. Men dens funktionalitet kan dække mange behov, der kan opstå under den videre udvikling. Hvis du bruger tid på at forstå, hvordan alt det her interagerer, så tror jeg, at du ikke vil have problemer med at implementere det selv.
På hub.docker.com er der normalt links til github.com, hvor de rå data er angivet, som man kan samle billedet fra selv.
Derudover findes der i dette repository et script kaldet docker-endpoint.sh, som er ansvarligt for den første initialization og for den videre behandling ved opstart af applikationen.
I dette eksempel er der også mulighed for konfiguration ved hjælp af miljøvariabler. Ved at angive miljøvariabler ved opstart af en enkelt container eller gennem docker-compose kan man sige, at vi skal angive en tom adgangskode for docker for root-brugeren i MySQL eller en hvilken som helst, som vi ønsker.
Der er mulighed for at oprette en tilfældig adgangskode. Vi siger, at vi har brug for en bruger, at vi skal installere en adgangskode for brugeren, og at vi skal oprette en database.
I vores projekter har vi lidt standardiseret Dockerfile, som er ansvarlig for initialization. Der har vi tilpasset det til vores behov og lavet en simpel udvidelse af brugerens rettigheder, som applikationen bruger. Dette gjorde det muligt senere at oprette databasen fra applikationens konsol. I Ruby-applikationer er der 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. Dockerfile kan åbnes, og man kan se, hvordan installationen foregår.
docker-endpoint.sh er et script, der fungerer som indgangspunkt. Ved den indledende initiering kræves der nogle forberedende skridt, som alle er inkluderet i scriptet til initiering.
Vi går videre til den anden del.
Til opbevaring af kildekoder er vi skiftet til gitlab. Det er et kraftfuldt system, der har et visuelt interface.
En af komponenterne i Gitlab er Gitlab CI. Det tillader at beskrive en sekvens af kommandoer, som senere vil blive brugt til at organisere systemet for kodetransport eller kørsel af automatiserede tests.
Præsentation om Gitlab CI 2 — en præsentation fra Ruby Russia club — den er temmelig detaljeret, og måske vil den interessere dig.
Lad os nu se på, hvad der kræves for at aktivere Gitlab CI. For at starte Gitlab CI er det tilstrækkeligt at placere filen .gitlab-ci.yml i roden af projektet.
Her beskriver vi, hvad vi ønsker at udføre i sekventielle tilstande som test og deployment.
Vi kører scripts, der direkte kalder docker-compose til at bygge vores applikation. Dette er et eksempel fra backend.
Derefter angiver vi, at det er nødvendigt at køre migrationer til ændring af databasen og udføre tests.
Hvis scriptsene kører korrekt og ikke returnerer en fejlkode, vil systemet derfor gå videre til den anden fase af deployment.
Deploymentfasen er i øjeblikket implementeret for staging. Vi har ikke organiseret en nulventet genstart.
Vi slukker alle containere tvangsmæssigt og derefter starter vi alle containere op igen, samlet i det første trin under testen.
Vi kører allerede migrationer til databaserne for det aktuelle miljø, som udviklerne har skrevet.
Der er en anmærkning om, at dette kun skal anvendes til master branch.
Ved ændring af andre grene vil det ikke blive udført.
Der er mulighed for at organisere udrulninger pr. branch.
For at gøre dette, skal vi installere Gitlab Runner.
Dette er et værktøj skrevet i Golang. Det er en enkelt fil, som det er sædvanligt i Golang-verdenen, og det kræver ingen afhængigheder.
Ved opstart registrerer vi Gitlab Runner.
Vi får en nøgle i Gitlab's web-interface.
Derefter kalder vi initialiseringskommandoen i kommandoprompten.
Vi konfigurerer Gitlab Runner i dialogtilstand (Shell, Docker, VirtualBox, SSH)
Koden på Gitlab Runner vil blive udført ved hver commit afhængigt af indstillingerne i .gitlab-ci.yml.
Hvordan det visuelt ser ud i Gitlab i webinterfacet. Efter at vi har tilsluttet Gitlab CI, får vi et flag, der viser, hvilken status bygget er i på nuværende tidspunkt.
Vi kan se, at der for 4 minutter siden blev lavet et commit, som har bestået alle tests uden problemer.
Vi kan se nærmere på bygningerne. Her ser vi, at der allerede er gået igennem to tilstande. Testtilstand og deployment til staging.
Hvis vi klikker på et specifikt byg, vil der være en konsoludgang af de kommandoer, der blev kørt i processen ifølge .gitlab-ci.yml.
Sådan ser historien for vores produkt ud. Vi kan se, at der har været vellykkede forsøg. Når testene fejler, går det ikke videre til næste trin, og koden på staging opdateres ikke.
Hvilke opgaver løste vi på staging, da vi implementerede docker? Vores system består af komponenter, og vi havde behov for kun at genstarte de opdaterede komponenter i repository i stedet for hele systemet.
For at gøre dette måtte vi opdele alt i separate mapper.
Efter vi havde gjort dette, opstod der et problem med, at Docker-compose skaber sit eget netværk for hver mappe og ikke ser naboens komponenter.
For at omgå dette, oprettede vi manuelt et netværk i Docker. I Docker-compose definerede vi, at dette projekt skulle bruge det pågældende netværk.
Dermed ser hver komponent, der starter med dette netværk, komponenter i andre dele af systemet.
Næste problem er opdelingen af staging mellem flere projekter.
For at det hele ser pænt og så tæt på production som muligt, er det godt at bruge port 80 eller 443, som er almindeligt anvendt i WEB.
Hvordan løste vi dette? Vi tildelte én Gitlab Runner til alle store projekter.
Gitlab tillader at starte flere distribuerede Gitlab Runners, som simpelthen i vilkårlig rækkefølge henter alle opgaver og kører dem.
For at undgå kaos begrænsede vi gruppen af vores projekter til én Gitlab Runner, som fungerer problemfrit med vores volumen.
Vi har flyttet nginx-proxy til et separat opstartsscript, hvor vi har angivet netværkene for alle projekter.
Vores projekt har ét netværk, mens balancereren har flere netværk navngivet efter projekterne. Den kan proxy videre baseret på domænenavne.
Vi modtager anmodninger på domænet på port 80, som ledes til en gruppe containere, der håndterer dette domæne.
Hvilke andre problemer har der været? Det er sådan, at alle containere som standard kører som bruger root. Denne root er ikke den samme som systemets root.
Men hvis man logger ind i containeren, vil det være root, og den fil, vi opretter i denne container, får root-rettigheder.
Hvis udvikleren logger ind i containeren og udfører nogle kommandoer, der genererer filer, og derefter logger ud af containeren, vil han i sin arbejdsmappe have en fil, som han ikke har adgang til.
Hvordan kan vi løse dette? Man kan tilføje brugere, som vil være i containeren.
Hvilke problemer opstod, da vi tilføjede brugeren?
Når vi opretter en bruger, har vi ofte ikke matchende gruppe-ID (UID) og bruger-ID (GID).
For at løse dette problem bruger vi brugere med ID 1000 i containeren.
I vores tilfælde stemte det overens med, at de fleste udviklere bruger Ubuntu OS. Og i Ubuntu OS har den første bruger ID 1000.
Hvad er vores planer?
At læse dokumentationen om Docker igen. Projektet udvikler sig aktivt, og dokumentationen ændrer sig. Oplysningerne, der blev fået for to-tre måneder siden, er allerede langsomt forældede.
Nogle af de problemer, vi har løst, er sandsynligvis allerede løst med standardværktøjer.
Det ville være rart at komme videre og direkte gå til orkestrering.
Et eksempel er den indbyggede mekanisme i Docker kaldet Docker Swarm, som leveres out-of-the-box. Man ønsker at køre noget produktion baseret på Docker Swarm-teknologi.
At generere containere gør arbejdet med logs besværligt. Lige nu er logs isolerede. De er spredt over containere. En opgave er at gøre adgangen til logs mere bekvem gennem et webinterface.
Kilde: habr.com
