Jag föreslÄr att du bekantar dig med sammanfattningen av Alexander Sigachevs föredrag frÄn Inventos "Utvecklings- och testprocessen med Docker + Gitlab CI"
De som just har börjat implementera utvecklings- och testprocessen baserad pÄ Docker + Gitlab CI stÀller ofta grundlÀggande frÄgor. Hur ska man börja? Hur ska man organisera det? Hur ska man testa?
Detta föredrag Àr bra eftersom det strukturerat beskriver utvecklings- och testprocessen med hjÀlp av Docker och Gitlab CI. SjÀlva föredraget Àr frÄn 2017. Jag tror att man kan hÀmta grundlÀggande principer, metodik, idéer och erfarenheter frÄn detta föredrag.
Den som Àr intresserad, vÀnligen lÀs vidare.
Jag heter Alexander Sigachev. Jag arbetar pÄ företaget Inventos. Jag kommer att berÀtta om min erfarenhet av att anvÀnda Docker och hur vi gradvis implementerar det i vÄra projekt.
Ămnet för föredraget: Utvecklingsprocessen med anvĂ€ndning av Docker och Gitlab CI.
Detta Àr mitt andra föredrag om Docker. Vid tidpunkten för det första föredraget anvÀnde vi Docker endast i utveckling pÄ utvecklarnas maskiner. Antalet anstÀllda som anvÀnde Docker var ungefÀr 2-3 personer. Successivt har vi samlat erfarenhet och gjort smÄ framsteg. LÀnk till vÄrt .
Vad kommer att tas upp i detta föredrag? Vi kommer att dela med oss av erfarenheter kring de fallgropar vi har stött pÄ, vilka problem vi har löst. Det var inte alltid vackert, men det har tillÄtit oss att gÄ vidare.
VĂ„r slogan: dockerisera allt vi kommer Ă„t.
Vilka problem löser vi?
NÀr det finns flera team i företaget sÄ Àr programmeraren en delad resurs. Det finns faser nÀr en programmerare dras ut frÄn ett projekt och tillfÀlligt ges till ett annat projekt.
För att en programmerare snabbt ska kunna sÀtta sig in i projektet behöver hen ladda ner projektets kÀllkod och sÄ snabbt som möjligt starta en miljö som gör att hen kan fortsÀtta och lösa uppgifterna i det aktuella projektet.
Vanligtvis, om man börjar frÄn början, finns det lite dokumentation i projektet. Informationen om hur man konfigurerar finns endast hos veteranerna. AnstÀllda stÀller oftast in sin arbetsplats pÄ en eller tvÄ dagar. För att snabba upp detta har vi anvÀnt Docker.
Den nÀsta anledningen Àr standardisering av instÀllningar i Development. UtifrÄn min erfarenhet visar utvecklarna alltid initiativ. I vart femte fall införs en anpassad domÀn, som vasya.dev. Bredvid sitter grannen Petya, som har domÀnen petya.dev. De utvecklar en webbplats eller nÄgon komponent av systemet med hjÀlp av detta domÀnnamn.
NÀr systemet vÀxer och dessa domÀnnamn börjar dyka upp i konfigurationerna, uppstÄr det en konflikt i Development-miljöer och sökvÀgen till webbplatsen skrivs om.
Detsamma hÀnder med instÀllningarna för databasen. NÄgon bekymrar sig inte för sÀkerheten och arbetar med ett tomt root-lösenord. NÄgon annan, vid installationen av MySQL, krÀvdes lösenord och det blev 123. Det hÀnder ofta att databasens konfiguration stÀndigt Àndras beroende pÄ utvecklarens commit. NÄgon har fixat, nÄgon har inte fixat konfigurationen. Det fanns knep för att vi tog ut en testkonfiguration i .gitignore och varje utvecklare var tvungen att installera databasen. Det försvÄrade startprocessen. Förutom allt annat mÄste man komma ihÄg databasen. Databasen behöver initieras, man mÄste ange lösenord, man mÄste ange anvÀndare, skapa tabeller och sÄ vidare.
Ett annat problem Àr olika versioner av bibliotek. Det Àr ofta sÄ att utvecklaren arbetar med olika projekt. Det finns ett Legacy-projekt som startades för fem Är sedan (frÄn 2017 - anm. red.). Vid starten anvÀnde vi MySQL 5.5. Det finns Àven moderna projekt dÀr vi strÀvar efter att införa mer moderna versioner av MySQL, till exempel 5.7 eller senare (frÄn 2017 - anm. red.)
Den som arbetar med MySQL vet att dessa bibliotek tar med sig beroenden. Det Àr ganska problematiskt att köra tvÄ databaser samtidigt. à tminstone Àr det problematiskt att fÄ gamla kunder att ansluta till den nya databasen. Detta ger i sin tur upphov till flera problem.
Ett vanligt problem Àr nÀr utvecklaren arbetar pÄ en lokal maskin och anvÀnder lokala resurser, lokala filer och lokalt RAM. All interaktion under utvecklingen av lösningar sker pÄ grundval av att allt fungerar pÄ en och samma maskin. Ett exempel kan vara nÀr vi har tre backend-servrar i produktion, men utvecklaren sparar filer i rotkatalogen och dÀrifrÄn hÀmtar nginx filerna för att svara pÄ förfrÄgningar. NÀr denna kod hamnar i produktion, visar det sig att filen finns pÄ en av de tre servrarna.
För nÀrvarande utvecklas mikrotjÀnster. NÀr vi delar upp vÄra stora applikationer i mindre komponenter som interagerar med varandra. Detta gör det möjligt att vÀlja teknologier specifikt för den uppgiftstablett. Det gör det ocksÄ möjligt att dela arbete och ansvarsomrÄden mellan utvecklarna.
En frontend-utvecklare, som utvecklar i JS, pÄverkar i stort sett inte backend. Backend-utvecklaren arbetar i sin tur med Ruby on Rails i vÄrt fall och stör inte frontend. Interaktionen sker via API.
Som en bonus har vi kunnat optimera resurser pÄ Staging med hjÀlp av Docker. Varje projekt krÀvde pÄ grund av sin specifika karaktÀr vissa instÀllningar. Fysiskt behövdes det antingen att avsÀtta en virtuell server och konfigurera den separat, eller att dela nÄgra tillfÀlliga miljöer, och projekten kunde pÄverka varandra beroende pÄ versionerna av biblioteken.
Verktyg. Vad anvÀnder vi?
- SjÀlva Docker. I Dockerfile beskrivs beroenden för en applikation.
- Docker-compose Àr en sammansÀttning som förenar flera av vÄra Docker-applikationer.
- Vi anvÀnder GitLab för lagring av kÀllkoden.
- Vi anvÀnder GitLab-CI för systemintegration.
Rapporten bestÄr av tvÄ delar.
Den första delen handlar om hur vi körde Docker pÄ utvecklarnas maskiner.
Den andra delen handlar om hur vi interagerar med GitLab, hur vi kör tester och hur vi distribuerar till Staging.
Docker Àr en teknologi som gör det möjligt att (med hjÀlp av ett deklarativt tillvÀgagÄngssÀtt) beskriva nödvÀndiga komponenter. Detta Àr ett exempel pÄ en Dockerfile. HÀr deklarerar vi att vi gÄr frÄn den officiella Docker-bilden Ruby:2.3.0. Den innehÄller Ruby version 2.3 installerad. Vi installerar nödvÀndiga byggbibliotek och NodeJS. Vi beskriver att vi skapar en katalog. /app. Vi tilldelar katalogen app som arbetskatalog. I denna katalog placerar vi den nödvÀndiga minimala Gemfile och Gemfile.lock. DÀrefter utför vi byggen av projekt som installerar detta beroendeavbild. Vi anger att containern kommer att vara redo att lyssna pÄ extern port 3000. Sista kommandot Àr det som direkt startar vÄr applikation. Om vi kör kommandot för att starta projektet, kommer applikationen att försöka köra sig och köra det angivna kommandot.
Detta Ă€r ett minimalt exempel pĂ„ en docker-compose-fil. HĂ€r visar vi hur tvĂ„ containrar Ă€r kopplade. Det handlar om databastjĂ€nsten och webbtjĂ€nsten. VĂ„ra web-applikationer krĂ€ver oftast en 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 en annan databas (PostgreSQL, Redis).
Vi tar officiella bilden frÄn Docker hub av MySQL 5.7.14 utan Àndringar. Bilden som ansvarar för vÄr web-applikation bygger vi frÄn den aktuella katalogen. Den bygger bilden vid första körningen. Efter det körs kommandot vi hÀr utför. Om vi gÄr tillbaka, kommer vi att se att startkommandot definierades via 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 behöver vidarebefordra porten pÄ vÄr utvecklarvÀrdmaskin frÄn 3000 till 3000-porten pÄ containern. Detta görs automatiskt med hjÀlp av iptables och sin egen mekanism, som direkt Àr inbÀddad i Docker.
Utvecklaren kan ocksÄ som tidigare rikta in sig pÄ vilken tillgÀnglig IP-adress som helst, till exempel 127.0.0.1 lokal eller den externa IP-adressen pÄ maskinen.
Den sista raden sĂ€ger att webcontainern beror pĂ„ db-containern. NĂ€r vi anropar för att starta webcontainern, kommer docker-compose först att starta databasen. NĂ€r databasen startar (i sjĂ€lva verket â efter att containern körs! Databasens beredskap garanterar inte detta), kommer vĂ„r applikation, vĂ„r backend, att startas.
Detta förhindrar fel, nÀr databasen inte har startats och sparar resurser nÀr vi stoppar databaskontainern, vilket frigör resurserna för andra projekt.
Vad ger oss anvÀndningen av databas-dockerisering i projektet? Vi faststÀller MySQL-versionen för alla utvecklare. Detta hjÀlper till att undvika vissa fel som kan uppstÄ vid versionsavvikelser, nÀr syntax, konfiguration och standardinstÀllningar Àndras. Detta gör det möjligt att ange gemensamma vÀrdnamn för databasen, inloggning och lösenord. Vi lÀmnar det kaos av namn och konflikter i konfigurationsfiler som tidigare fanns.
Vi har möjlighet att anvÀnda en mer optimal konfiguration för utvecklingsmiljön, som skiljer sig frÄn den standardkonfiguration som finns. MySQL Àr som standard instÀllt för svaga maskiner och dess prestanda Àr ganska lÄg direkt ur kartongen.
Docker gör det möjligt att anvÀnda den nödvÀndiga versionen av Python, Ruby, NodeJS, PHP. Vi slipper behovet av att anvÀnda nÄgon versionshanterare. Tidigare anvÀnde vi ett RPM-paket för Ruby som gjorde att vi kunde Àndra version beroende pÄ projektet. Dessutom gör det möjligt att smidigt migrera kod och versionera den tillsammans med beroenden tack vare Docker-containern. Vi fÄr inga problem med att förstÄ versionen av bÄde tolk och kod. För att uppdatera versionen mÄste vi sÀnka den gamla containern och starta en ny. Om nÄgot gÄr fel kan vi sÀnka den nya containern och starta den gamla.
Efter byggandet av bilden kommer containrarna, bÄde i utvecklings- och produktionsmiljö, att vara identiska. Detta Àr sÀrskilt viktigt för stora installationer.
PÄ frontend anvÀnder vi JavaScript och NodeJS.
Just nu Àr vÄrt senaste projekt baserat pÄ ReactJS. Utvecklaren körde alla containrar och utvecklade med hjÀlp av hot-reload.
DÀrefter startas en uppgift för att bygga JavaScript och den samlade koden levereras som statisk via nginx för att spara resurser.
HÀr har jag lagt fram en skiss av vÄrt senaste projekt.
Vilka uppgifter löste vi? Vi fick behov av att bygga ett system som interagerar med mobila enheter. De fÄr data. En av funktionerna Àr att skicka push-notiser till denna enhet.
Vad gjorde vi för detta?
Vi delade upp applikationen i komponenter som: administrationsdelen pÄ JS, backend som fungerar via REST-API under Ruby on Rails. Backend interagerar med databasen. Resultaten som genereras skickas till kunden. Administrationssystemet interagerar med backend och databasen via REST-API.
Vi behövde ocksÄ skicka Push-notiser. Tidigare hade vi ett projekt dÀr en mekanism implementerades för att leverera meddelanden till mobila plattformar.
Vi utvecklade ett schema: operatören frÄn webblÀsaren interagerar med administrationspanelen, administrationspanelen interagerar med backend, och en uppgift stÀlls för att skicka Push-notiser.
Push-notiser interagerar med en annan komponent som Àr implementerad i NodeJS.
Köer byggs och sedan sker leveransen av meddelanden enligt mekanismen.
HÀr visas tvÄ databaser. För nÀrvarande anvÀnder vi med hjÀlp av Docker tvÄ oberoende databaser som inte Àr kopplade till varandra. Den enda kopplingen Àr att de har ett gemensamt virtuellt nÀtverk, medan de fysiska datalagringarna finns i olika kataloger pÄ utvecklarens maskin.
Samma sak men i siffror. HÀr Àr ÄteranvÀndning av koden viktig.
Om vi tidigare talade om ÄteranvÀndning av kod i form av bibliotek, sÄ i det hÀr exemplet ÄteranvÀnds vÄr tjÀnst för Push-notiser som en komplett server. Den tillhandahÄller API. Och vÄr nya utveckling interagerar med den.
Vid den tidpunkten anvÀnde vi version 4 av NodeJS. Nu (Är 2017) i nya utvecklingar anvÀnder vi version 7 av NodeJS. Det Àr inga problem att anvÀnda nya versioner av bibliotek i nya komponenter.
Vid behov kan vi genomföra en omstrukturering och uppgradera versionen av NodeJS i tjÀnsten för Push-notiser.
Och om vi kan behÄlla API-kompatibilitet kan den ersÀttas i andra projekt som anvÀnts tidigare.
Vad behövs för att lÀgga till Docker? Vi lÀgger till en Dockerfile i vÄrt repository, som beskriver nödvÀndiga beroenden. I det hÀr exemplet Àr komponenterna uppdelade efter logik. Detta Àr en minimiset av vad en backend-utvecklare behöver.
NĂ€r vi skapar ett nytt projekt skapar vi en Dockerfile, beskriver den nödvĂ€ndiga ekosystemet (Python, Ruby, NodeJS). I docker-compose beskriver vi nödvĂ€ndiga beroenden â databasen. Vi specificerar vilken version av databasen som behövs och var data ska lagras.
Vi anvÀnder en separat tredje container med nginx för att hantera statisk innehÄll. Möjlighet att ladda upp bilder Àr förutsedd. Backend placerar dem i en förberedd volym, som ocksÄ Àr monterad i containern med nginx, som hanterar den statiska innehÄll.
För att lagra konfigurationen av nginx och mysql har vi lagt till en Docker-mapp dÀr vi sparar de nödvÀndiga konfigurationerna. NÀr utvecklaren gör en git clone av repot till sin maskin fÄr han ett projekt som redan Àr klart för lokal utveckling. Det uppstÄr inga frÄgor om vilken port eller vilken instÀllning som ska tillÀmpas.
Sedan har vi flera komponenter: admin, inform-API, push-notifikationer.
För att starta allt detta har vi skapat ytterligare ett repo som vi kallade dockerized-app. För nĂ€rvarande anvĂ€nder vi flera repos för varje komponent. De skiljer sig logiskt â i GitLab ser det ut som en mapp, och pĂ„ utvecklarens maskin finns en mapp för det specifika projektet. PĂ„ en lĂ€gre nivĂ„ finns komponenter som kommer att samlas.
Detta Àr ett exempel pÄ innehÄllet i dockerized-app. Vi för ocksÄ ut en Docker-katalog hÀr, dÀr vi fyller pÄ med konfigurationer som krÀvs för interaktionerna 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. Det Àr gjort för att kunna starta stegvis. NÀr utvecklaren arbetar med kÀrnan behöver han inte push-notifikationer, sÄ han startar bara docker-compose-filen och dÀrmed besparar resurser.
Om det behövs en integration med push-notifikationer startas docker-compose.yaml och docker-compose-push.yaml.
Eftersom docker-compose.yaml och docker-compose-push.yaml ligger i en mapp, skapas automatiskt ett gemensamt virtuell nÀtverk.
Beskrivning av komponenterna. Detta Àr en mer uttömmande fil som ansvarar för sammanstÀllningen av komponenterna. Vad Àr anmÀrkningsvÀrt hÀr? HÀr introducerar vi komponentbalanseraren.
Detta Àr en fÀrdig Docker-bild dÀr nginx och en applikation körs, som lyssnar pÄ Docker-socket. Dynamiskt, nÀr containrar slÄs pÄ och av, regenereras nginx-konfigurationen. Vi distribuerar hanteringen av komponenterna efter tredjepartsdomÀner.
För utvecklingsmiljön anvĂ€nder vi domĂ€nen .dev â api.informer.dev. Applikationerna med domĂ€nen .dev Ă€r tillgĂ€ngliga pĂ„ utvecklarens lokala maskin.
Vidare överförs konfigurationerna till varje projekt och alla projekt startas tillsammans samtidigt.
Om man grafiskt visar det fÄr vi klienten som vÄr webblÀsare eller nÄgot verktyg som vi anvÀnder för att göra anrop till balanceraren.
Balanceraren avgör enligt domÀnnamnet vilken container den ska kontakta.
Det kan vara nginx som levererar JS för adminpanelen. Det kan vara nginx som levererar API eller statiska filer som levereras av nginx i form av bilduppladdningar.
I diagrammet syns att containrarna Àr sammanlÀnkade i ett virtuellt nÀtverk och dolda bakom en proxy.
PÄ utvecklarmaskinen kan man nÄ containern om man kÀnner till IP-adressen, men vi anvÀnder faktiskt inte detta. Det finns sÀllan behov av direkt Ätkomst.
Vilket exempel ska man titta pÄ för att dockerisera sin applikation? Enligt min Äsikt Àr det officiella Docker-image för MySQL ett bra exempel.
Det Àr ganska komplext. Det finns mÄnga versioner. Men dess funktionalitet tÀcker mÄnga behov som kan uppstÄ under vidare utveckling. Om du tar dig tid att förstÄ hur allt detta interagerar, tror jag att du kommer att slippa problem med sjÀlvintegration.
PÄ hub.docker.com finns vanligtvis lÀnkar till github.com, dÀr rÄdata finns direkt, sÄ att man sjÀlv kan samla en image.
I det hÀr arkivet finns ocksÄ skriptet docker-endpoint.sh, som ansvarar för den initiala konfigurationen och för vidare behandling av applikationens start.
I det hÀr exemplet finns Àven möjlighet till konfiguration med hjÀlp av miljövariabler. Genom att definiera miljövariabler vid start av en enskild container eller genom docker-compose kan man ange att vi behöver sÀtta ett tomt lösenord för docker eller ett som vi vill ha för root pÄ MySQL.
Det finns ett alternativ att skapa ett slumpmÀssigt lösenord. Vi sÀger att vi behöver en anvÀndare, vi behöver sÀtta en anvÀndares lösenord och vi behöver skapa en databas.
I vÄra projekt har vi lite standardiserat Dockerfile som ansvarar för initialisering. DÀr har vi gjort Àndringar för vÄra behov för att enkelt ge anvÀndaren rÀttigheter som applikationen anvÀnder. Detta möjliggjorde senare att enkelt skapa en databas frÄn applikationens konsol. I Ruby-applikationer finns det kommandon för att skapa, Àndra och ta bort databaser.
Detta Àr ett exempel pÄ hur en specifik version av MySQL ser ut pÄ github.com. Dockerfile kan öppnas och man kan se hur installationen gÄr till.
docker-endpoint.sh Àr ett skript som ansvarar för ingÄngspunkten. Vid första initialiseringen krÀvs vissa förberedande ÄtgÀrder, och alla dessa ÄtgÀrder har flyttats till skriptet för initialisering.
Vi gÄr vidare till del tvÄ.
För att lagra kÀllkoden har vi övergÄtt till gitlab. Detta Àr ett kraftfullt system med ett visuellt grÀnssnitt.
En av komponenterna i Gitlab Àr Gitlab CI. Den gör det möjligt att beskriva sekvenser av kommandon som senare anvÀnds för att organisera kodleverans eller köra automatiserade tester.
Rapport om Gitlab CI 2 â en presentation frĂ„n Ruby Russia club â ganska detaljerad och kanske intressant för er.
Nu kommer vi att titta pÄ vad som krÀvs för att aktivera Gitlab CI. För att starta Gitlab CI rÀcker det med att placera filen .gitlab-ci.yml i projektets rotkatalog.
HÀr beskriver vi vad vi vill utföra, en sekvens av tillstÄnd av typen test, distribution.
Vi kör skripten som direkt anropar docker-compose för att bygga vÄr applikation. Detta Àr ett exempel pÄ backend.
DÀrefter sÀger vi att vi mÄste köra migrationerna för att Àndra databasen och utföra tester.
Om skripten körs korrekt och inte returnerar en felkod, gÄr systemet vidare till den andra fasen av distribution.
Distributionens fas Àr för nÀrvarande implementerad för staging. Vi har inte organiserat en sömlös omstart.
Vi slÀcker alla containrar och startar sedan upp dem igen, de som byggdes under den första testfasen.
Vi kör migrationerna för den aktuella miljön som har skrivits av utvecklarna.
Det finns en notering om att detta endast ska tillÀmpas pÄ master-branschen.
Vid Àndringar i andra branscher utförs det inte.
Det finns möjlighet att organisera distributioner per bransch.
För att gÄ vidare med detta behöver vi installera Gitlab Runner.
Detta verktyg Àr skrivet i Golang. Det Àr en enkel fil som Àr typiskt för Golang-vÀrlden, och det krÀvs inga beroenden.
Vid start registrerar vi Gitlab Runner.
Vi fÄr en nyckel i Gitlabs webbgrÀnssnitt.
Sedan anropar vi kommandot för initialisering i kommandoraden.
Vi konfigurerar Gitlab Runner i dialoglÀge (Shell, Docker, VirtualBox, SSH)
Koden pÄ Gitlab Runner kommer att köras vid varje commit beroende pÄ instÀllningarna i .gitlab-ci.yml.
Hur det visuellt ser ut i Gitlab i webgrÀnssnittet. Efter att vi kopplat pÄ Gitlab CI fÄr vi en flagga som visar i vilket tillstÄnd bygget befinner sig för tillfÀllet.
Vi ser att ett commit gjordes för 4 minuter sedan, och den klarade alla tester utan problem.
Vi kan titta mer detaljerat pÄ byggen. HÀr ser vi att tvÄ tillstÄnd redan har passerats. TesttillstÄndet och distribueringslÀget pÄ staging.
Om vi klickar pÄ ett specifikt bygge kommer vi att se konsolutmatningen av de kommandon som kördes i processen enligt .gitlab-ci.yml.
SÄ hÀr ser historiken för vÄr produkt ut. Vi ser att det har funnits lyckade försök. NÀr testerna faller avancerar det inte till nÀsta steg, och koden pÄ staging uppdateras inte.
Vilka uppgifter löste vi pÄ staging nÀr vi implementerade Docker? VÄrt system bestÄr av komponenter och vi behövde bara starta om de komponenter som hade uppdaterats i arkivet, snarare Àn hela systemet.
För detta var vi tvungna att separera allt i olika mappar.
Efter att vi gjort detta stötte vi pÄ ett problem dÀr Docker-compose skapar ett eget nÀtverksutrymme för varje mapp och inte ser grannkomponenterna.
För att omgÄ detta skapade vi ett nÀtverk i Docker manuellt. I Docker-compose angav vi att anvÀnda detta nÀtverk för projektet.
PÄ sÄ sÀtt ser varje komponent som startar med detta nÀtverk komponenter i andra delar av systemet.
Det nÀstföljande problemet Àr att dela upp staging mellan flera projekt.
Eftersom allt detta ska se bra ut och vara sÄ nÀra produktion som möjligt Àr det bra att anvÀnda port 80 eller 443, som anvÀnds allmÀnt i WEB.
Hur löste vi detta? Vi tilldelade en Gitlab Runner till alla stora projekt.
Gitlab tillÄter att köra flera distribuerade Gitlab Runners som helt enkelt turas om att slumpmÀssigt ta alla uppgifter och köra dem.
För att vi inte skulle fÄ kaos begrÀnsade vi gruppen av vÄra projekt till en Gitlab Runner, som klarar av vÄra volymer utan problem.
Vi har flyttat nginx-proxy till ett eget startskript och angav nÀtverken för alla projekt dÀr.
VÄrt projekt har ett nÀtverk, och belastningsbalanseraren har flera nÀtverk enligt projektnamn. Den kan proxy vidare baserat pÄ domÀnnamn.
Vi fÄr förfrÄgningar som kommer in via domÀnen pÄ port 80 och hanteras i en behÄllargrupp som Àr kopplad till denna domÀn.
Vilka andra problem fanns det? Det Àr sÄ att alla behÄllare som standard körs som anvÀndaren root. Detta root Àr inte samma som root i systemets vÀrd.
Men om man gÄr in i behÄllaren sÄ Àr det root, och filen som vi skapar i denna behÄllare fÄr root-behörighet.
Om utvecklaren gick in i behÄllaren och utförde kommandon som skapade filer, och sedan lÀmnade behÄllaren, sÄ har han en fil i sin arbetskatalog som han inte har tillgÄng till.
Hur kan vi lösa detta? Vi kan lÀgga till anvÀndare som kommer att vara i behÄllaren.
Vilka problem uppstod nÀr vi lade till en anvÀndare?
NÀr vi skapar en anvÀndare stÀmmer ofta inte grupp-ID (UID) och anvÀndar-ID (GID) överens.
För att lösa detta problem anvÀnder vi anvÀndare med ID 1000 i behÄllaren.
I vÄrt fall matchade det med att nÀstan alla utvecklare anvÀnder Ubuntu OS. I Ubuntu har den första anvÀndaren ID 1000.
Vad har vi för planer?
LÀsa dokumentationen för Docker igen. Projektet utvecklas aktivt och dokumentationen Àndras. Information som ficks för tvÄ eller tre mÄnader sedan börjar bli gammal.
En del av problemen vi har löst Àr sannolikt redan lösta med standardverktyg.
Det skulle vara roligt att gÄ vidare och fokusera pÄ orkestrering.
Ett exempel pÄ detta Àr den inbyggda mekanismen i Docker som kallas Docker Swarm, som kommer direkt ur lÄdan. Vi vill kunna köra nÄgot i produktion baserat pÄ Docker Swarm-teknologin.
Skapandet av behÄllare gör att det blir besvÀrligt att arbeta med loggar. Just nu Àr loggarna isolerade. De Àr spridda över olika behÄllare. En av uppgifterna Àr att skapa bekvÀm tillgÄng till loggar genom ett webgrÀnssnitt.
KĂ€lla: habr.com
