Ek stel voor om die transkripsie van die verslag deur Alexander Sigachev van Inventos "Ontwikkelings- en toetsproses met Docker + Gitlab CI" te lees
Diegene wat net begin om die ontwikkelings- en toetsproses gebaseer op Docker + Gitlab CI te implementeer, vra dikwels basiese vrae. Waar om te begin? Hoe om te organiseer? Hoe om te toets?
Hierdie verslag is goed omdat dit op 'n gestruktureerde manier praat oor die ontwikkelings- en toetsproses deur Docker en Gitlab CI te gebruik. Die verslag self is van 2017. Ek dink dat jy uit hierdie verslag die basiese beginsels, metodologie, idee, ervaring van gebruik kan leer.
Wie gee om, asseblief onder die kat.
My naam is Alexander Sigachev. Ek werk vir Inventos. Ek sal jou vertel van my ervaring met die gebruik van Docker en hoe ons dit geleidelik op projekte in die maatskappy implementeer.
Aanbiedingsonderwerp: Ontwikkelingsproses deur Docker en Gitlab CI te gebruik.
Dit is my tweede praatjie oor Docker. Ten tyde van die eerste verslag het ons slegs Docker in Ontwikkeling op ontwikkelaarmasjiene gebruik. Die aantal werknemers wat Docker gebruik het, was ongeveer 2-3 mense. Geleidelik is ondervinding opgedoen en ons het 'n entjie verder getrek. Skakel na ons .
Wat sal in hierdie verslag wees? Ons sal ons ervaring deel oor watter hark ons ingesamel het, watter probleme ons opgelos het. Nie oral was dit mooi nie, maar toegelaat om aan te beweeg.
Ons leuse is: dok alles wat ons in die hande kan kry.
Watter probleme los ons op?
Wanneer daar verskeie spanne in 'n maatskappy is, is die programmeerder 'n gedeelde hulpbron. Daar is stadiums wanneer 'n programmeerder uit een projek getrek word en vir 'n geruime tyd aan 'n ander projek gegee word.
Om die programmeerder vinnig te verstaan, moet hy die bronkode van die projek aflaai en die omgewing so gou as moontlik begin, wat hom in staat sal stel om verder te beweeg om die probleme van hierdie projek op te los.
Gewoonlik, as jy van voor af begin, dan is daar min dokumentasie in die projek. Inligting oor hoe om op te stel is slegs beskikbaar vir outydse mense. Werknemers rig hul werkplek binne een of twee dae op hul eie op. Om dit te bespoedig, het ons Docker gebruik.
Die volgende rede is die standaardisering van instellings in Ontwikkeling. In my ervaring neem ontwikkelaars altyd die inisiatief. In elke vyfde geval word 'n pasgemaakte domein ingevoer, byvoorbeeld vasya.dev. Langs hom sit sy buurvrou Petya, wie se domein petya.dev is. Hulle ontwikkel 'n webwerf of 'n komponent van die stelsel deur hierdie domeinnaam te gebruik.
Wanneer die stelsel groei en hierdie domeinname begin om in konfigurasies te kom, ontstaan 'n Ontwikkelingsomgewingskonflik en word die werfpad herskryf.
Dieselfde gebeur met databasisinstellings. Iemand steur hom nie aan sekuriteit nie en werk met 'n leë wortelwagwoord. By die installasie stadium het MySQL iemand vir 'n wagwoord gevra en die wagwoord blyk 123 te wees. Dit gebeur dikwels dat die databasiskonfigurasie voortdurend verander, afhangende van die ontwikkelaar se commit. Iemand het reggestel, iemand het nie die konfigurasie reggestel nie. Daar was truuks toe ons 'n soort toetskonfigurasie uitgehaal het .gitignore en elke ontwikkelaar moes die databasis installeer. Dit het dit moeilik gemaak om te begin. Dit is onder andere nodig om te onthou van die databasis. Die databasis moet geïnisialiseer word, 'n wagwoord moet ingevoer word, 'n gebruiker moet geregistreer word, 'n tabel moet geskep word, ensovoorts.
Nog 'n probleem is verskillende weergawes van biblioteke. Dit gebeur dikwels dat 'n ontwikkelaar met verskillende projekte werk. Daar is 'n Legacy-projek wat vyf jaar gelede begin het (vanaf 2017 - red. nota). Ten tyde van die bekendstelling het ons begin met MySQL 5.5. Daar is ook moderne projekte waar ons probeer om meer moderne weergawes van MySQL te implementeer, byvoorbeeld 5.7 of ouer (in 2017 - red. let wel)
Enigiemand wat met MySQL werk, weet dat hierdie biblioteke afhanklikhede saambring. Dit is nogal problematies om 2 basisse saam te hardloop. Ten minste is ou kliënte problematies om aan die nuwe databasis te koppel. Dit skep weer verskeie probleme.
Die volgende probleem is wanneer 'n ontwikkelaar op 'n plaaslike masjien werk, hy gebruik plaaslike hulpbronne, plaaslike lêers, plaaslike RAM. Alle interaksie ten tyde van die ontwikkeling van 'n oplossing vir probleme word uitgevoer binne die raamwerk van die feit dat dit op een masjien werk. 'n Voorbeeld is wanneer ons backend-bedieners in Produksie 3 het, en die ontwikkelaar stoor lêers in die wortelgids en van daar af neem nginx lêers om op die versoek te reageer. Wanneer so 'n kode in Produksie kom, blyk dit dat die lêer op een van die 3 bedieners teenwoordig is.
Die rigting van mikrodienste ontwikkel nou. Wanneer ons ons groot toepassings verdeel in 'n paar klein komponente wat met mekaar in wisselwerking is. Dit laat jou toe om tegnologieë vir 'n spesifieke stapel take te kies. Dit laat jou ook toe om werk en verantwoordelikhede tussen ontwikkelaars te deel.
Frondend-ontwikkelaar, wat op JS ontwikkel, het amper geen invloed op Backend nie. Die backend-ontwikkelaar ontwikkel op sy beurt, in ons geval, Ruby on Rails en meng nie met Frondend in nie. Die interaksie word uitgevoer met behulp van die API.
As 'n bonus, met die hulp van Docker, kon ons hulpbronne op Staging herwin. Elke projek het, as gevolg van sy besonderhede, sekere instellings vereis. Fisies was dit nodig om óf 'n virtuele bediener toe te ken en dit afsonderlik te konfigureer, óf om 'n soort veranderlike omgewing te deel en projekte kon, afhangend van die weergawe van die biblioteke, mekaar beïnvloed.
Gereedskap. Wat gebruik ons?
- Docker self. Die Dockerfile beskryf die afhanklikhede van 'n enkele toepassing.
- Docker-compose is 'n bundel wat 'n paar van ons Docker-toepassings bymekaarbring.
- Ons gebruik GitLab om die bronkode te stoor.
- Ons gebruik GitLab-CI vir stelselintegrasie.
Die verslag bestaan uit twee dele.
Die eerste deel sal praat oor hoe Docker op ontwikkelaars se masjiene uitgevoer is.
Die tweede deel sal praat oor hoe om met GitLab om te gaan, hoe ons toetse uitvoer en hoe ons uitrol na Staging.
Docker is 'n tegnologie wat dit moontlik maak (met 'n verklarende benadering) om die nodige komponente te beskryf. Dit is 'n voorbeeld Dockerfile. Hier verklaar ons dat ons van die amptelike Ruby:2.3.0 Docker-beeld erf. Dit bevat Ruby weergawe 2.3 geïnstalleer. Ons installeer die vereiste boubiblioteke en NodeJS. Ons beskryf dat ons 'n gids skep /app. Stel die toepassinggids as die werkgids. In hierdie gids plaas ons die vereiste minimale Gemfile en Gemfile.lock. Ons bou dan die projekte wat hierdie afhanklikheidsbeeld installeer. Ons dui aan dat die houer gereed sal wees om te luister op eksterne poort 3000. Die laaste opdrag is die opdrag wat ons toepassing direk begin. As ons die projek begin opdrag uitvoer, sal die toepassing probeer om die gespesifiseerde opdrag uit te voer en uit te voer.
Dit is 'n minimale voorbeeld van 'n docker-compose-lêer. In hierdie geval wys ons dat daar 'n verband tussen twee houers is. Dit is direk in die databasisdiens en die webdiens. Ons webtoepassings benodig in die meeste gevalle 'n soort databasis as 'n backend vir die stoor van data. Aangesien ons MySQL gebruik, is die voorbeeld met MySQL - maar niks verhoed ons om 'n ander databasis (PostgreSQL, Redis) te gebruik nie.
Ons neem die beeld van MySQL 5.7.14 sonder veranderinge uit die amptelike bron van die Docker-hub. Ons versamel die beeld wat verantwoordelik is vir ons webtoepassing uit die huidige gids. Dit versamel 'n beeld vir ons tydens die eerste bekendstelling. Dan loop dit die opdrag wat ons hier uitvoer. As ons teruggaan, sal ons sien dat die beginopdrag via Puma gedefinieer is. Puma is 'n diens wat in Ruby geskryf is. In die tweede geval ignoreer ons. Hierdie opdrag kan arbitrêr wees, afhangende van ons behoeftes of take.
Ons beskryf ook dat ons 'n poort op ons ontwikkelaargasheermasjien van 3000 na 3000 op die houerpoort moet aanstuur. Dit word outomaties gedoen met behulp van iptables en sy meganisme, wat direk in Docker ingebed is.
Die ontwikkelaar kan ook, soos voorheen, toegang verkry tot enige beskikbare IP-adres, byvoorbeeld, 127.0.0.1 is die plaaslike of eksterne IP-adres van die masjien.
Die laaste reël sê dat die webhouer afhang van die db-houer. Wanneer ons die begin van die webhouer oproep, sal docker-compose eers die databasis vir ons begin. Reeds aan die begin van die databasis (in werklikheid, na die bekendstelling van die houer! Dit waarborg nie die gereedheid van die databasis nie) sal die toepassing, ons backend, begin.
Dit vermy foute wanneer die databasis nie op is nie en spaar hulpbronne wanneer ons die databasishouer stop, en sodoende word hulpbronne vir ander projekte vrygestel.
Wat gee ons die gebruik van databasisdoktering op die projek. Ons maak die weergawe van MySQL vir alle ontwikkelaars reg. Dit vermy sommige foute wat kan voorkom wanneer weergawes verskil, wanneer die sintaksis, konfigurasie, verstekinstellings verander. Dit laat jou toe om 'n algemene gasheernaam vir die databasis, login, wagwoord te spesifiseer. Ons beweeg weg van die dieretuin van name en konflikte in die konfigurasielêers wat ons vroeër gehad het.
Ons het die geleentheid om 'n meer optimale konfigurasie vir die Ontwikkelingsomgewing te gebruik, wat sal verskil van die verstek. MySQL is by verstek opgestel vir swak masjiene en sy werkverrigting buite die boks is baie swak.
Docker laat jou toe om die Python, Ruby, NodeJS, PHP tolk van die verlangde weergawe te gebruik. Ons raak ontslae van die behoefte om 'n soort weergawebestuurder te gebruik. Voorheen het Ruby 'n rpm-pakket gebruik wat jou toegelaat het om die weergawe te verander na gelang van die projek. Dit laat ook toe, danksy die Docker-houer, om die kode glad te migreer en dit saam met afhanklikhede weer te gee. Ons het geen probleem om die weergawe van beide die tolk en die kode te verstaan nie. Om die weergawe op te dateer, verlaag die ou houer en verhoog die nuwe houer. As iets verkeerd geloop het, kan ons die nuwe houer laat sak, die ou houer lig.
Nadat die beeld gebou is, sal die houers in beide Ontwikkeling en Produksie dieselfde wees. Dit geld veral vir groot installasies.
Op Frontend gebruik ons JavaScipt en NodeJS.
Nou het ons die laaste projek op ReacJS. Die ontwikkelaar het alles in die houer laat loop en ontwikkel met behulp van warm herlaai.
Vervolgens word die JavaScipt-samestellingstaak geloods en die kode wat in statika saamgestel is, word gegee deur middel van nginx-besparingsbronne.
Hier het ek die skema van ons laaste projek gegee.
Watter take is opgelos? Ons het 'n behoefte gehad om 'n stelsel te bou waarmee mobiele toestelle interaksie het. Hulle ontvang data. Een moontlikheid is om stootkennisgewings na hierdie toestel te stuur.
Wat het ons hiervoor gedoen?
Ons het in die toepassing komponente verdeel soos: die admin-deel op JS, die agterkant, wat deur die REST-koppelvlak onder Ruby on Rails werk. Die backend is in wisselwerking met die databasis. Die resultaat wat gegenereer word, word aan die kliënt gegee. Die administrasiepaneel is in wisselwerking met die backend en die databasis via die REST-koppelvlak.
Ons het ook 'n behoefte gehad om stootkennisgewings te stuur. Voor dit het ons 'n projek gehad wat 'n meganisme geïmplementeer het wat verantwoordelik is vir die lewering van kennisgewings aan mobiele platforms.
Ons het die volgende skema ontwikkel: 'n operateur van die blaaier het interaksie met die administrasiepaneel, die administrasiepaneel is in wisselwerking met die agterkant, die taak is om Push-kennisgewings te stuur.
Stootkennisgewings werk in wisselwerking met 'n ander komponent wat in NodeJS geïmplementeer is.
Toue word gebou en dan word kennisgewings volgens hul meganisme gestuur.
Twee databasisse word hier geteken. Op die oomblik, met die hulp van Docker, gebruik ons 2 onafhanklike databasisse wat op geen manier met mekaar verband hou nie. Daarbenewens het hulle 'n gemeenskaplike virtuele netwerk, en fisiese data word in verskillende dopgehou op die ontwikkelaar se masjien gestoor.
Dieselfde maar in getalle. Dit is waar kode hergebruik belangrik is.
As ons vroeër gepraat het oor die hergebruik van kode in die vorm van biblioteke, dan word ons diens wat reageer op Push-kennisgewings in hierdie voorbeeld as 'n volledige bediener hergebruik. Dit bied 'n API. En ons nuwe ontwikkeling is reeds in wisselwerking daarmee.
Op daardie tydstip het ons weergawe 4 van NodeJS gebruik. Nou (in 2017 - red. let wel) in onlangse ontwikkelings gebruik ons weergawe 7 van NodeJS. Daar is geen probleem in nuwe komponente om nuwe weergawes van biblioteke te betrek nie.
Indien nodig, kan u die NodeJS-weergawe van die Push-kennisgewingdiens herfaktoreer en verhoog.
En as ons API-versoenbaarheid kan handhaaf, sal dit moontlik wees om dit te vervang met ander projekte wat voorheen gebruik is.
Wat het jy nodig om Docker by te voeg? Ons voeg 'n Dockerfile by ons bewaarplek, wat die nodige afhanklikhede beskryf. In hierdie voorbeeld word die komponente logies afgebreek. Dit is die minimum stel van 'n backend-ontwikkelaar.
Wanneer 'n nuwe projek geskep word, skep ons 'n Dockerfile, beskryf die gewenste ekosisteem (Python, Ruby, NodeJS). In docker-compose beskryf dit die nodige afhanklikheid - die databasis. Ons beskryf dat ons 'n databasis van so en so 'n weergawe nodig het, stoor data daar en daar.
Ons gebruik 'n aparte derde houer met nginx om staties te bedien. Dit is moontlik om foto's op te laai. Backend plaas hulle in 'n vooraf voorbereide volume, wat ook in 'n houer met nginx gemonteer is, wat die statiese gee.
Om die nginx, mysql-konfigurasie te stoor, het ons 'n Docker-lêergids bygevoeg waarin ons die nodige konfigurasies stoor. Wanneer 'n ontwikkelaar 'n git-kloon van 'n bewaarplek op sy masjien doen, het hy reeds 'n projek gereed vir plaaslike ontwikkeling. Daar is geen twyfel watter poort of watter instellings om toe te pas nie.
Vervolgens het ons verskeie komponente: admin, inform-API, stootkennisgewings.
Om dit alles te begin, het ons 'n ander bewaarplek geskep, wat ons dockerized-app genoem het. Op die oomblik gebruik ons verskeie bewaarplekke voor elke komponent. Hulle is net logies anders - in GitLab lyk dit soos 'n gids, maar op die ontwikkelaar se masjien, 'n gids vir 'n spesifieke projek. Een vlak af is die komponente wat gekombineer sal word.
Dit is 'n voorbeeld van net die inhoud van gedokteriseerde toepassing. Ons bring ook die Docker-gids hierheen, waarin ons die konfigurasies invul wat nodig is vir die interaksies van alle komponente. Daar is 'n README.md wat kortliks beskryf hoe om die projek te bestuur.
Hier het ons twee docker-compose-lêers toegepas. Dit word gedoen om in stappe te kan hardloop. Wanneer 'n ontwikkelaar met die kern werk, het hy nie stootkennisgewings nodig nie, hy loods bloot 'n docker-compose-lêer en dienooreenkomstig word die hulpbron gestoor.
As daar 'n behoefte is om met stootkennisgewings te integreer, word docker-compose.yaml en docker-compose-push.yaml geloods.
Aangesien docker-compose.yaml en docker-compose-push.yaml in 'n vouer is, word 'n enkele virtuele netwerk outomaties geskep.
Beskrywing van komponente. Dit is 'n meer gevorderde lêer wat verantwoordelik is vir die versameling van komponente. Wat is hier merkwaardig? Hier stel ons die balanseerder-komponent bekend.
Dit is 'n klaargemaakte Docker-beeld wat nginx laat loop en 'n toepassing wat op die Docker-sok luister. Dinamies, soos houers aan- en afgeskakel word, herstel dit die nginx-konfigurasie. Ons versprei die hantering van komponente deur derdevlak-domeinname.
Vir die ontwikkelingsomgewing gebruik ons die .dev-domein - api.informer.dev. Toepassings met 'n .dev-domein is beskikbaar op die ontwikkelaar se plaaslike masjien.
Verder word konfigurasies na elke projek oorgedra en alle projekte word gelyktydig saam van stapel gestuur.
Grafies blyk dit dat die kliënt ons blaaier is of een of ander hulpmiddel waarmee ons versoeke aan die balanseerder rig.
Die domeinnaam-balanseerder bepaal watter houer om te kontak.
Dit kan nginx wees, wat die admin JS gee. Dit kan nginx wees, wat die API gee, of statiese lêers wat aan nginx gegee word in die vorm van beeldoplaaie.
Die diagram toon dat die houers deur 'n virtuele netwerk verbind is en agter 'n instaanbediener versteek is.
Op die ontwikkelaar se masjien kan jy toegang tot die houer kry met kennis van die IP, maar in beginsel gebruik ons dit nie. Daar is feitlik geen behoefte aan direkte toegang nie.
Watter voorbeeld om na te kyk om jou aansoek te dokteriseer? Na my mening is 'n goeie voorbeeld die amptelike docker-beeld vir MySQL.
Dit is nogal uitdagend. Daar is baie weergawes. Maar die funksionaliteit daarvan laat jou toe om baie behoeftes te dek wat in die proses van verdere ontwikkeling kan ontstaan. As jy tyd spandeer en uitvind hoe dit alles in wisselwerking is, dan dink ek jy sal geen probleme hê met selfimplementering nie.
Hub.docker.com bevat gewoonlik skakels na github.com, wat rou data direk bevat waaruit jy self die prent kan bou.
Verder in hierdie bewaarplek is daar 'n docker-endpoint.sh script, wat verantwoordelik is vir die aanvanklike inisialisering en vir verdere verwerking van die toepassing bekendstelling.
Ook in hierdie voorbeeld is daar die vermoë om te konfigureer deur omgewingsveranderlikes te gebruik. Deur 'n omgewingsveranderlike te definieer wanneer 'n enkele houer uitgevoer word of deur docker-compose, kan ons sê dat ons 'n leë wagwoord vir docker moet stel om op MySQL te wortel of wat ons ook al wil hê.
Daar is 'n opsie om 'n ewekansige wagwoord te skep. Ons sê dat ons 'n gebruiker nodig het, ons moet 'n wagwoord vir die gebruiker stel, en ons moet 'n databasis skep.
In ons projekte het ons die Dockerfile, wat verantwoordelik is vir inisialisering, effens verenig. Daar het ons dit reggestel na ons behoeftes om dit net 'n uitbreiding te maak van die gebruikersregte wat die toepassing gebruik. Dit het ons in staat gestel om later eenvoudig 'n databasis vanaf die toepassingskonsole te skep. Ruby-toepassings het 'n opdrag om databasisse te skep, te wysig en uit te vee.
Dit is 'n voorbeeld van hoe 'n spesifieke weergawe van MySQL op github.com lyk. U kan die Dockerfile oopmaak en sien hoe die installasie daar aangaan.
docker-endpoint.sh is die skrif wat verantwoordelik is vir die toegangspunt. Tydens die aanvanklike inisialisering word 'n paar voorbereidingstappe vereis, en al hierdie aksies word net in die inisialiseringskrip geneem.
Kom ons gaan aan na die tweede deel.
Om die bronkodes te stoor, het ons na gitlab oorgeskakel. Dit is 'n redelik kragtige stelsel wat 'n visuele koppelvlak het.
Een van die komponente van Gitlab is Gitlab CI. Dit laat jou toe om 'n reeks opdragte te beskryf wat later gebruik sal word om 'n kode-afleweringstelsel te organiseer of outomatiese toetse uit te voer.
Gitlab CI 2 praatjie - verslag van Ruby Russia-klub - redelik gedetailleerd en miskien sal dit jou interesseer.
Nou sal ons kyk na wat nodig is om Gitlab CI te aktiveer. Om Gitlab CI te begin, hoef ons net die .gitlab-ci.yml-lêer in die wortel van die projek te plaas.
Hier beskryf ons dat ons 'n reeks toestande wil uitvoer soos 'n toets, ontplooi.
Ons voer skrifte uit wat docker-compose direk roep om ons toepassing te bou. Dit is net 'n backend voorbeeld.
Vervolgens sê ons dat dit nodig is om migrasies uit te voer om die databasis te verander en toetse uit te voer.
As die skrifte korrek uitgevoer word en nie 'n foutkode terugstuur nie, gaan die stelsel voort na die tweede fase van die ontplooiing.
Die ontplooiingstadium word tans vir opvoering geïmplementeer. Ons het nie 'n nul-stilstand-herbegin gereël nie.
Ons blus alle houers met geweld, en dan lig ons weer al die houers op, wat in die eerste stadium tydens toetsing versamel is.
Ons hardloop vir die huidige omgewingsveranderlike die databasismigrasies wat deur die ontwikkelaars geskryf is.
Daar is 'n nota dat dit slegs van toepassing is op die meestertak.
By die verandering van ander takke word nie uitgevoer nie.
Dit is moontlik om ontplooiings volgens takke te organiseer.
Om dit verder te organiseer, moet ons Gitlab Runner installeer.
Hierdie program is in Golang geskryf. Dit is 'n enkele lêer, soos algemeen in die Golang-wêreld, wat geen afhanklikhede vereis nie.
Met die opstart registreer ons die Gitlab Runner.
Ons kry die sleutel in die Gitlab-webkoppelvlak.
Dan roep ons die inisialiseringsbevel op die opdragreël.
Stel Gitlab Runner interaktief op (Shell, Docker, VirtualBox, SSH)
Die kode op Gitlab Runner sal op elke commit uitgevoer word, afhangende van die .gitlab-ci.yml instelling.
Hoe dit visueel in Gitlab in die webkoppelvlak lyk. Nadat ons GItlab CI gekoppel het, het ons 'n vlag wat die toestand van die gebou op die oomblik wys.
Ons sien dat 'n commit 4 minute gelede gemaak is, wat al die toetse geslaag het en geen probleme veroorsaak het nie.
Ons kan die bouwerk van nader bekyk. Hier sien ons dat twee state reeds geslaag het. Toetsstatus en ontplooiingstatus op verhoog.
As ons op 'n spesifieke bou klik, sal daar 'n konsole-uitvoer wees van die opdragte wat in die proses uitgevoer is volgens .gitlab-ci.yml.
Dit is hoe ons produkgeskiedenis lyk. Ons sien dat daar suksesvolle pogings was. Wanneer toetse ingedien word, gaan dit nie voort na die volgende stap nie en die opstelkode word nie opgedateer nie.
Watter take het ons tydens opvoering opgelos toe ons docker geïmplementeer het? Ons stelsel bestaan uit komponente en ons het 'n behoefte gehad om te herbegin, slegs 'n deel van die komponente wat in die bewaarplek opgedateer is, en nie die hele stelsel nie.
Om dit te doen, moes ons alles in afsonderlike dopgehou verpletter.
Nadat ons dit gedoen het, het ons 'n probleem gehad met die feit dat Docker-compose sy eie netwerkspasie vir elke pappa skep en nie die buurman se komponente sien nie.
Om rond te kom, het ons die netwerk in Docker met die hand geskep. Dit is in Docker-compose geskryf dat jy so 'n netwerk vir hierdie projek gebruik.
Dus, elke komponent wat met hierdie mesh begin, sien komponente in ander dele van die stelsel.
Die volgende uitgawe is om die verhoog oor verskeie projekte te verdeel.
Aangesien dit alles mooi en so na as moontlik aan produksie kan lyk, is dit goed om poort 80 of 443 te gebruik, wat oral in die WEB gebruik word.
Hoe het ons dit opgelos? Ons het een Gitlab Runner aan alle groot projekte toegewys.
Gitlab laat jou toe om verskeie verspreide Gitlab Runners te hardloop, wat eenvoudig al die take om die beurt op 'n chaotiese manier sal neem en dit sal uitvoer.
Sodat ons nie 'n huis het nie, het ons die groep van ons projekte beperk tot een Gitlab Runner, wat sonder probleme met ons volumes klaarkom.
Ons het nginx-proxy na 'n aparte opstartskrif geskuif en roosters bygevoeg vir alle projekte daarin.
Ons projek het een rooster, en die balanseerder het verskeie roosters volgens projekname. Dit kan verder deur domeinname instaan.
Ons versoeke kom deur die domein op poort 80 en word opgelos in 'n houergroep wat hierdie domein bedien.
Watter ander probleme was daar? Dit is wat alle houers by verstek as wortel loop. Dit is wortel ongelyk aan die wortelgasheer van die stelsel.
As jy egter die houer ingaan, sal dit wortel wees en die lêer wat ons in hierdie houer skep, kry wortelregte.
As die ontwikkelaar die houer ingegaan het en 'n paar opdragte daar gedoen het wat lêers genereer, dan die houer verlaat het, dan het hy 'n lêer in sy werksgids waartoe hy nie toegang het nie.
Hoe kan dit opgelos word? Jy kan gebruikers byvoeg wat in die houer sal wees.
Watter probleme het ontstaan toe ons die gebruiker bygevoeg het?
Wanneer 'n gebruiker geskep word, het ons dikwels nie dieselfde groep-ID (UID) en gebruikers-ID (GID) nie.
Om hierdie probleem in die houer op te los, gebruik ons gebruikers met ID 1000.
In ons geval het dit saamgeval met die feit dat byna alle ontwikkelaars die Ubuntu-bedryfstelsel gebruik. En op Ubuntu het die eerste gebruiker 'n ID van 1000.
Het ons planne?
Lees die Docker-dokumentasie. Die projek ontwikkel aktief, die dokumentasie is besig om te verander. Die data wat twee of drie maande gelede ontvang is, raak reeds stadigaan verouderd.
Sommige van die probleme wat ons opgelos het, is heel moontlik reeds met standaardmetodes opgelos.
So ek wil al verder gaan om direk na die orkestrasie te gaan.
Een voorbeeld is Docker se ingeboude meganisme genaamd Docker Swarm, wat uit die boks kom. Ek wil iets in produksie bedryf gebaseer op Docker Swarm-tegnologie.
Kuithouers maak dit ongerieflik om met stompe te werk. Nou is die stompe geïsoleer. Hulle is oor houers versprei. Een van die take is om maklike toegang tot die logs deur die webkoppelvlak te maak.
Bron: will.com