Þróunar- og prófunarferli með Docker og Gitlab CI

Ég legg til að þú lesir afrit skýrslu Alexanders Sigachev frá Inventos „Þróunar- og prófunarferli með Docker + Gitlab CI“

Þeir sem eru að byrja að innleiða þróunar- og prófunarferlið byggt á Docker + Gitlab CI spyrja oft grunnspurninga. Hvar á að byrja? Hvernig á að skipuleggja? Hvernig á að prófa?

Þessi skýrsla er góð vegna þess að hún talar á skipulegan hátt um þróunar- og prófunarferlið með því að nota Docker og Gitlab CI. Skýrslan sjálf er frá 2017. Ég held að úr þessari skýrslu sé hægt að tína til grunnatriði, aðferðafræði, hugmynd og reynslu af notkun.

Fyrir áhugasama, vinsamlegast sjáið kött.

Ég heiti Alexander Sigachev. Ég vinn hjá Inventos. Ég mun segja þér frá reynslu minni af því að nota Docker og hvernig við erum smám saman að innleiða það á verkefnum í fyrirtækinu.

Efni skýrslunnar: Þróunarferli með Docker og Gitlab CI.

Þetta er önnur ræða mín um Docker. Þegar fyrstu skýrslan kom fram notuðum við Docker aðeins í þróun á þróunarvélum. Fjöldi starfsmanna sem notuðu Docker var um 2-3 manns. Smám saman fékkst reynsla og við færðum okkur aðeins lengra. Tengill á okkar fyrstu skýrslu.

Hvað verður í þessari skýrslu? Við munum deila reynslu okkar um hvaða hrífur við söfnuðum, hvaða vandamál við leystum. Það var ekki fallegt alls staðar, en það gerði okkur kleift að halda áfram.

Einkunnarorð okkar: gera allt sem við fáum í hendurnar.

Hvaða vandamál erum við að leysa?

Þegar fyrirtæki hefur nokkur teymi er forritarinn sameiginleg auðlind. Það eru stig þegar forritari er dreginn út úr einu verkefni og gefið öðru verkefni í nokkurn tíma.

Til þess að forritari skilji fljótt þarf hann að hlaða niður frumkóða verkefnisins og setja af stað umhverfi eins fljótt og auðið er, sem gerir honum kleift að komast lengra í að leysa vandamál þessa verkefnis.

Venjulega, ef þú byrjar frá grunni, er lítið um skjöl í verkefninu. Aðeins gamalmenni hafa upplýsingar um hvernig eigi að setja það upp. Starfsmenn koma sér upp vinnustað á eigin vegum á einum eða tveimur dögum. Til að flýta fyrir þessu notuðum við Docker.

Næsta ástæða er stöðlun stillinga í þróun. Mín reynsla er að verktaki taka alltaf frumkvæði. Í fimmta hvert tilvik er sérsniðið lén slegið inn, til dæmis vasya.dev. Við hliðina á mér situr nágranni minn Petya, en lénið hennar er petya.dev. Þeir þróa vefsíðu eða einhvern kerfishluta með því að nota þetta lén.

Þegar kerfið stækkar og þessi lén byrja að vera með í uppsetningunni, myndast átök í þróunarumhverfi og slóð vefsvæðisins er endurskrifuð.

Það sama gerist með gagnagrunnsstillingar. Sumir nenna ekki öryggi og vinna með tómt rót lykilorð. Á uppsetningarstigi bað MySQL einhvern um lykilorð og lykilorðið reyndist vera 123. Það kemur oft fyrir að gagnagrunnsstillingin var stöðugt að breytast eftir því hvernig forritarinn skuldbindur sig. Einhver leiðrétti, einhver leiðrétti ekki stillinguna. Það voru brellur þegar við settum einhverja prófstillingu inn í .gitignore og hver þróunaraðili þurfti að setja upp gagnagrunninn. Þetta gerði upphafsferlið erfiðara. Meðal annars þarf að muna um gagnagrunninn. Gagnagrunnurinn þarf að frumstilla, skrá lykilorð, skrá notanda, búa til skilti og svo framvegis.

Annað vandamál er mismunandi útgáfur af bókasöfnum. Það kemur oft fyrir að verktaki vinnur að mismunandi verkefnum. Það er Legacy verkefni, sem hófst fyrir fimm árum (frá 2017 - ritstj.). Í upphafi byrjuðum við með MySQL 5.5. Það eru líka nútímaleg verkefni þar sem við erum að reyna að innleiða nútímalegri útgáfur af MySQL, til dæmis 5.7 eða eldri (árið 2017 - ritstj.)

Allir sem vinna með MySQL vita að þessi bókasöfn bera ósjálfstæði. Það er frekar erfitt að keyra 2 gagnagrunna saman. Að minnsta kosti er erfitt að tengja gamla viðskiptavini við nýja gagnagrunninn. Þetta leiðir aftur til nokkurra vandamála.

Næsta vandamál er þegar verktaki vinnur á staðbundinni vél, hann notar staðbundnar auðlindir, staðbundnar skrár, staðbundið vinnsluminni. Öll samskipti á þeim tíma sem lausn á vandamálum er þróað fer fram innan ramma þess að hún virkar á einni vél. Dæmi væri þegar við erum með bakendaþjóna í framleiðslu 3 og verktaki vistar skrár í rótarskrána og þaðan tekur nginx skrárnar til að svara beiðninni. Þegar slíkur kóði kemst inn í framleiðslu kemur í ljós að skráin er til staðar á einum af 3 netþjónum.

Stefna örþjónustu er nú að þróast. Þegar við skiptum stórum forritum okkar í nokkra litla hluti sem hafa samskipti sín á milli. Þetta gerir þér kleift að velja tækni fyrir ákveðinn verkefnastafla. Þetta gerir þér einnig kleift að skipta vinnu og ábyrgðarsviði milli þróunaraðila.

Framenda verktaki, sem þróar í JS, hefur nánast engin áhrif á bakenda. Bakendinn þróar aftur á móti, í okkar tilviki, Ruby on Rails og truflar ekki Frondend. Samskipti eru framkvæmd með því að nota API.

Sem bónus, með því að nota Docker, gátum við endurunnið auðlindir á Staging. Hvert verkefni, vegna sérstöðu þess, krafðist ákveðinna stillinga. Líkamlega var nauðsynlegt að úthluta annað hvort sýndarþjóni og stilla hann sérstaklega, eða skipta einhvers konar breytilegu umhverfi og verkefni gætu haft áhrif á hvert annað, allt eftir útgáfu bókasöfnanna.

Verkfæri. Hvað notum við?

• Docker sjálfur. Dockerfile lýsir ósjálfstæði eins forrits.
• Docker-compose er búnt sem sameinar nokkur af Docker forritunum okkar.
• Við notum GitLab til að geyma frumkóða.
• Við notum GitLab-CI fyrir kerfissamþættingu.

Skýrslan er í tveimur hlutum.

Fyrsti hlutinn mun segja þér hvernig á að keyra Docker á vélum þróunaraðila.

Í seinni hlutanum verður fjallað um hvernig á að hafa samskipti við GitLab, hvernig við keyrum próf og hvernig við rúllum út í Staging.

Docker er tækni sem gerir (með því að nota yfirlýsandi nálgun) að lýsa nauðsynlegum íhlutum. Þetta er dæmi um Dockerfile. Hér lýsum við því yfir að við séum að erfa frá opinberu Docker myndinni af Ruby:2.3.0. Það inniheldur Ruby útgáfu 2.3 uppsett. Við setjum upp nauðsynleg samsetningarsöfn og NodeJS. Við lýsum því að við erum að búa til möppu /app. Við úthlutum forritaskránni sem vinnuskrá. Í þessa möppu setjum við nauðsynlega lágmarks Gemfile og Gemfile.lock. Síðan byggjum við verkefni sem setja upp þessa ávanamynd. Við gefum til kynna að gámurinn verði tilbúinn til að hlusta á ytri höfn 3000. Síðasta skipunin er skipunin sem ræsir forritið okkar beint. Ef við keyrum verkefnið keyra skipunina mun forritið reyna að keyra og keyra tilgreinda skipun.

Þetta er lágmarksdæmi um docker-compose skrá. Í þessu tilviki sýnum við að það er tenging á milli tveggja gáma. Þetta er beint inn í gagnagrunnsþjónustuna og vefþjónustuna. Vefforritin okkar þurfa í flestum tilfellum einhvers konar gagnagrunn sem bakenda til að geyma gögn. Þar sem við notum MySQL er dæmið með MySQL - en ekkert kemur í veg fyrir að við notum einhvern annan gagnagrunn (PostgreSQL, Redis).

Við tökum MySQL 5.7.14 myndina án breytinga frá opinberu upprunanum frá Docker miðstöðinni. Við söfnum myndinni sem ber ábyrgð á vefforritinu okkar úr núverandi skrá. Við fyrstu kynningu safnar hann mynd fyrir okkur. Síðan keyrir það skipunina sem við erum að keyra hér. Ef við förum til baka munum við sjá að ræsingarskipunin var skilgreind í gegnum Puma. Puma er þjónusta skrifuð í Ruby. Í öðru tilvikinu hnekkum við. Þessi skipun getur verið handahófskennd eftir þörfum okkar eða verkefnum.

Við lýsum líka því að við þurfum að senda höfnina á hýsingarvél þróunaraðila okkar frá 3000 til 3000 gámahöfn. Þetta er gert sjálfkrafa með iptables og eigin vélbúnaði, sem er beint innbyggt í Docker.

Framkvæmdaraðilinn getur eins og áður fengið aðgang að hvaða IP tölu sem er tiltækt, til dæmis 127.0.0.1 staðbundið eða ytra IP tölu vélarinnar.

Síðasta línan segir að vefgámurinn sé háður db gámnum. Þegar við köllum á vefgáminn til að ræsa, mun docker-compose fyrst ræsa gagnagrunninn fyrir okkur. Þegar gagnagrunnurinn byrjar (reyndar eftir að gámurinn hefur verið ræstur! Þetta tryggir ekki viðbúnað gagnagrunnsins) mun hann ræsa forritið okkar, bakendann okkar.

Þetta gerir okkur kleift að forðast villur þegar gagnagrunnurinn er ekki uppi og gerir okkur kleift að spara tilföng þegar við stöðvum gagnagrunnsgáminn og losar þar með fjármagn fyrir önnur verkefni.

Hvað gefur okkur að nota gagnagrunnstengingu í verkefni? Við tökum upp MySQL útgáfuna fyrir alla forritara. Þetta gerir þér kleift að forðast nokkrar villur sem geta komið upp þegar útgáfur eru mismunandi, þegar setningafræði, stillingar og sjálfgefna stillingar breytast. Þetta gerir þér kleift að tilgreina sameiginlegt hýsingarheiti fyrir gagnagrunninn, innskráningu, lykilorð. Við erum að hverfa frá dýragarðinum af nöfnum og átökum í stillingarskrám sem voru til áður.

Við höfum tækifæri til að nota ákjósanlegri stillingu fyrir þróunarumhverfið, sem mun vera frábrugðið því sjálfgefna. MySQL er sjálfgefið stillt fyrir veikburða vélar og frammistaða þess utan kassans er mjög lág.

Docker gerir þér kleift að nota Python, Ruby, NodeJS, PHP túlk af viðkomandi útgáfu. Við losnum við þörfina á að nota einhvers konar útgáfustjóra. Áður var rpm pakki notaður fyrir Ruby, sem gerði þér kleift að breyta útgáfunni eftir verkefninu. Þökk sé Docker gámnum gerir þetta þér einnig kleift að flytja kóða og útgáfu hans ásamt ósjálfstæði. Við eigum ekki í neinum vandræðum með að skilja útgáfuna af bæði túlknum og kóðanum. Til að uppfæra útgáfuna þarftu að lækka gamla ílátið og hækka nýja ílátið. Ef eitthvað fer úrskeiðis getum við lækkað nýja gáminn, hækkað gamla gáminn.

Eftir að myndin hefur verið byggð verða gámarnir í bæði þróun og framleiðslu eins. Þetta á sérstaklega við um stórar innsetningar.

Á framenda notum við JavaScipt og NodeJS.

Núna höfum við síðasta verkefnið okkar á ReacJS. Framkvæmdaraðilinn setti allt í gáminn og þróaði með því að nota heita endurhleðslu.

Næst er verkefnið að setja saman JavaScipt sett af stað og kóðinn sem settur er saman er kyrrstæður sendur í gegnum nginx og sparar auðlindir.

Hér hef ég gefið skýringarmynd af nýjasta verkefninu okkar.

Hvaða vandamál leystir þú? Við þurftum að byggja upp kerfi sem farsímar hafa samskipti við. Þeir fá gögn. Einn af möguleikunum er að senda ýttu tilkynningar í þetta tæki.

Hvað höfum við gert fyrir þetta?

Við skiptum forritinu í eftirfarandi þætti: admin hluta í JS, bakenda sem vinnur í gegnum REST tengi undir Ruby on Rails. Bakendi hefur samskipti við gagnagrunninn. Niðurstaðan sem myndast er gefin til viðskiptavinarins. Stjórnborðið hefur samskipti við bakendann og gagnagrunninn í gegnum REST viðmót.

Við þurftum líka að senda Push tilkynningar. Fyrir þetta vorum við með verkefni þar sem kerfi var innleitt sem var ábyrgt fyrir því að senda tilkynningar á farsímakerfi.

Við höfum þróað eftirfarandi kerfi: stjórnandi frá vafranum hefur samskipti við stjórnborðið, stjórnborðið hefur samskipti við bakendann, verkefnið er að senda Push tilkynningar.

Push tilkynningar hafa samskipti við annan íhlut sem er útfærður í NodeJS.

Biðraðir eru byggðar og tilkynningar sendar samkvæmt eigin kerfi.

Hér eru teiknaðir tveir gagnagrunnar. Eins og er, með því að nota Docker, notum við 2 sjálfstæða gagnagrunna sem eru á engan hátt tengdir hver öðrum. Auk þess að þeir eru með sameiginlegt sýndarnet og líkamleg gögn eru geymd í mismunandi möppum á vél þróunaraðila.

Sama hluturinn en í tölum. Endurnotkun kóða er mikilvæg hér.

Ef við töluðum áður um að endurnýta kóða í formi bókasöfna, þá er þjónusta okkar, sem bregst við Push-tilkynningum, endurnotuð sem heill þjónn í þessu dæmi. Það veitir API. Og ný þróun okkar hefur samskipti við það.

Á þeim tíma vorum við að nota útgáfu 4 af NodeJS. Núna (árið 2017 - ritstjóra) í nýjustu þróun okkar notum við útgáfu 7 af NodeJS. Það er ekkert vandamál í nýjum hlutum að fela í sér nýjar útgáfur af bókasöfnum.

Ef nauðsyn krefur geturðu endurstillt og hækkað NodeJS útgáfuna af Push tilkynningaþjónustunni.

Og ef við getum viðhaldið API eindrægni, þá verður hægt að skipta því út fyrir önnur verkefni sem voru notuð áður.

Hvað þarftu til að bæta Docker við? Við bætum Dockerfile við geymsluna okkar, sem lýsir nauðsynlegum ósjálfstæðum. Í þessu dæmi er hlutunum skipt rökrétt. Þetta er lágmarksbúnaður fyrir bakenda þróunaraðila.

Þegar nýtt verkefni er búið til búum við til Dockerfile og lýsum viðkomandi vistkerfi (Python, Ruby, NodeJS). Í docker-compose lýsir það nauðsynlegri ósjálfstæði - gagnagrunninum. Við lýsum því að við þurfum gagnagrunn af slíkri og slíkri útgáfu, til að geyma gögn þar og þar.

Við notum sérstakan þriðja ílát með nginx til að þjóna kyrrstæðu efni. Það er hægt að setja inn myndir. Bakendinn setur þá í fyrirfram undirbúið bindi, sem einnig er komið fyrir í íláti með nginx, sem gefur kyrrstæð gögn.

Til að geyma nginx og mysql stillingarnar bættum við Docker möppu við þar sem við geymum nauðsynlegar stillingar. Þegar þróunaraðili gerir git klón af geymslu á vélinni sinni, er hann nú þegar með verkefni tilbúið fyrir staðbundna þróun. Það er engin spurning um hvaða höfn eða hvaða stillingar eigi að nota.

Næst höfum við nokkra íhluti: admin, info-API, ýta tilkynningar.

Til þess að ræsa allt þetta, bjuggum við til aðra geymslu sem kallast dockerized-app. Við notum eins og er margar geymslur fyrir hvern íhlut. Þeir eru einfaldlega rökfræðilega ólíkir - í GitLab lítur það út eins og mappa, en á vél þróunaraðila lítur það út eins og mappa fyrir tiltekið verkefni. Eitt stig fyrir neðan eru íhlutirnir sem verða sameinaðir.

Þetta er dæmi um innihald dockerized-apps. Við setjum einnig Docker möppu hér, þar sem við fyllum út þær stillingar sem krafist er fyrir samskipti allra íhluta. Það er README.md sem lýsir í stuttu máli hvernig á að hefja verkefnið.

Hér höfum við notað tvær docker-compose skrár. Þetta er gert til að hægt sé að hleypa af stokkunum í áföngum. Þegar verktaki vinnur með kjarnann þarf hann ekki Push tilkynningar, hann ræsir einfaldlega docker-compose skrána og í samræmi við það eru tilföng vistuð.

Ef þörf er á samþættingu við Push tilkynningar, þá eru docker-compose.yaml og docker-compose-push.yaml ræst.

Þar sem docker-compose.yaml og docker-compose-push.yaml eru í möppunni er eitt sýndarnet sjálfkrafa búið til.

Lýsing á íhlutum. Þetta er fullkomnari skrá sem ber ábyrgð á að safna íhlutum. Hvað er merkilegt hérna? Hér kynnum við jafnvægisþáttinn.

Þetta er tilbúin Docker mynd sem keyrir nginx og forrit sem hlustar á Docker falsið. Dynamic, þegar kveikt og slökkt er á gámum, er nginx stillingin endurgerð. Við dreifum meðhöndlun á íhlutum með því að nota þriðja stigs lén.

Fyrir þróunarumhverfið notum við .dev lénið - api.informer.dev. Forrit með .dev léni eru fáanleg á staðbundinni vél þróunaraðilans.

Síðan eru stillingarnar fluttar yfir á hvert verkefni og öll verkefni ræst saman á sama tíma.

Ef við sýnum það myndrænt kemur í ljós að viðskiptavinurinn er vafrinn okkar eða einhvers konar tól sem við gerum beiðnir með til jafnvægisaðilans.

Jafnvægismaðurinn ákvarðar hvaða ílát þarf að nálgast út frá léninu.

Þetta gæti verið nginx, sem veitir stjórnborðinu JS. Þetta er hægt að gera með nginx, sem veitir API, eða kyrrstæðum skrám, sem eru veittar af nginx í formi hleðslumynda.

Skýringarmyndin sýnir að gámarnir eru tengdir sýndarneti og falin á bak við proxy.

Á vél þróunaraðila geturðu fengið aðgang að gámnum með því að vita IP, en í grundvallaratriðum notum við þetta ekki. Það er nánast engin þörf á beinu sambandi.

Hvaða dæmi ætti ég að skoða til að gera umsóknina mína í skjóli? Að mínu mati er gott dæmi opinbera bryggjumyndin fyrir MySQL.

Það er frekar flókið. Það eru margar útgáfur. En virkni þess gerir þér kleift að mæta mörgum þörfum sem kunna að koma upp í frekari þróun. Ef þú tekur þér tíma og skilur hvernig þetta hefur allt samspil, þá held ég að þú eigir ekki í neinum vandræðum með að útfæra það sjálfur.

Hub.docker.com inniheldur venjulega tengla á github.com, þar sem hrá gögn eru veitt beint sem þú getur byggt mynd sjálfur úr.

Lengra í þessari geymslu er handrit docker-endpoint.sh, sem er ábyrgt fyrir upphaflegri frumstillingu og frekari úrvinnslu á ræsingu forrits.

Einnig í þessu dæmi er möguleiki á uppsetningu með því að nota umhverfisbreytur. Með því að skilgreina umhverfisbreytu þegar þú keyrir einn gám eða í gegnum docker-compose getum við sagt að við þurfum að setja tómt lykilorð fyrir docker fyrir root á MySQL eða hvað sem við viljum.

Það er möguleiki að búa til handahófskennt lykilorð. Við segjum að við þurfum notanda, við þurfum að setja lykilorð fyrir notandann og við þurfum að búa til gagnagrunn.

Í verkefnum okkar höfum við aðeins sameinað Dockerfile, sem ber ábyrgð á frumstillingu. Þar stilltum við það að þörfum okkar til að auka einfaldlega notendaréttindin sem forritið notar. Þetta gerði það mögulegt að búa einfaldlega til gagnagrunn úr forritatölvunni í framtíðinni. Ruby forrit hafa skipanir til að búa til, breyta og eyða gagnagrunnum.

Þetta er dæmi um hvernig ákveðin útgáfa af MySQL lítur út á github.com. Þú getur opnað Dockerfile og séð hvernig uppsetningin fer fram þar.

docker-endpoint.sh forskrift sem ber ábyrgð á inngangsstaðnum. Meðan á frumstillingu stendur eru nokkrar undirbúningsaðgerðir nauðsynlegar og allar þessar aðgerðir eru innifalin í frumstillingarforskriftinni.

Við skulum halda áfram að seinni hlutanum.

Við skiptum yfir í gitlab til að geyma frumkóða. Þetta er nokkuð öflugt kerfi sem hefur sjónrænt viðmót.

Einn af Gitlab íhlutunum er Gitlab CI. Það gerir þér kleift að lýsa röð skipana sem verða síðan notaðar til að skipuleggja kóðaafhendingarkerfi eða keyra sjálfvirkar prófanir.

Skýrsla um Gitlab CI 2 https://goo.gl/uohKjI — Skýrslan frá Ruby Russia klúbbnum er nokkuð ítarleg og gæti verið áhugaverð fyrir þig.

Nú munum við skoða hvað þarf til að virkja Gitlab CI. Til þess að ræsa Gitlab CI þurfum við bara að setja .gitlab-ci.yml skrána í rót verkefnisins.

Hér lýsum við því að við viljum framkvæma röð af ríkjum eins og prófun, dreifingu.

Við keyrum forskriftir sem kalla beint á docker-compose byggingu forritsins okkar. Þetta er dæmi um bara bakenda.

Næst segjum við að það sé nauðsynlegt að keyra flutninga til að breyta gagnagrunninum og keyra próf.

Ef forskriftirnar eru keyrðar á réttan hátt og skila ekki villukóða, þá heldur kerfið áfram á annað stig uppsetningar.

Dreifingarstigið er nú útfært fyrir sviðsetningu. Við skipulögðum ekki endurræsingu án niður í miðbæ.

Við slökkvum alla gáma með valdi og lyftum síðan öllum gámunum aftur, safnað á fyrsta stigi við prófun.

Við skulum keyra gagnagrunnsflutningana sem voru skrifaðir af þróunaraðilum fyrir núverandi breytuumhverfi.

Það er aths. að þetta ætti aðeins að gilda um meistaragreinina.

Virkar ekki þegar skipt er um aðrar greinar.

Hægt er að skipuleggja útfærslur meðfram útibúum.

Til að skipuleggja þetta frekar þurfum við að setja upp Gitlab Runner.

Þetta tól er skrifað í Golang. Það er ein skrá eins og algengt er í Golang heiminum, sem krefst enga ósjálfstæðis.

Við ræsingu skráum við Gitlab Runner.

Við fáum lykilinn í Gitlab vefviðmótið.

Síðan köllum við upphafsskipunina á skipanalínunni.

Stilla Gitlab Runner í valmynd (Shell, Docker, VirtualBox, SSH)

Kóðinn á Gitlab Runner mun keyra á hverri commit eftir .gitlab-ci.yml stillingunni.

Hvernig það lítur út sjónrænt í Gitlab í vefviðmótinu. Eftir að hafa tengt GItlab CI erum við með fána sem sýnir í hvaða ástandi byggingin er í augnablikinu.

Við sjáum að fyrir 4 mínútum síðan var gerð skuldbinding sem stóðst öll prófin og olli engum vandræðum.

Við getum skoðað byggingarnar nánar. Hér sjáum við að tvö ríki eru þegar liðin. Prófunarstaða og dreifingarstaða við sviðsetningu.

Ef við smellum á tiltekna byggingu, þá verður stjórnborðsúttak af skipunum sem voru ræstar í ferlinu samkvæmt .gitlab-ci.yml.

Svona lítur sagan af vörunni okkar út. Við sjáum að það hafa verið árangursríkar tilraunir. Þegar prófunum er skilað fara þau ekki í næsta skref og sviðsetningarkóði er ekki uppfærður.

Hvaða vandamál leystum við í sviðsetningu þegar við innleiddum docker? Kerfið okkar samanstendur af íhlutum og við þurftum að endurræsa aðeins hluta af þeim íhlutum sem voru uppfærðir í geymslunni, en ekki allt kerfið.

Til að gera þetta þurftum við að aðgreina allt í aðskildar möppur.

Eftir að við gerðum þetta áttum við í vandræðum með þá staðreynd að Docker-compose býr til sitt eigið netpláss fyrir hverja möppu og sér ekki íhluti nágrannans.

Til að komast um bjuggum við til netið handvirkt í Docker. Í Docker-compose var skrifað að þú ættir að nota slíkt net fyrir þetta verkefni.

Þannig sér hver hluti sem byrjar með þessu möskva íhluti í öðrum hlutum kerfisins.

Næsta vandamál er að skipta sviðsetningu á milli nokkurra verkefna.

Þar sem allt þetta lítur fallega út og sem næst framleiðslu er gott að nota port 80 eða 443 sem er notað alls staðar á VEFNUM.

Hvernig leystum við þetta? Við úthlutuðum einum Gitlab Runner í öll stór verkefni.

Gitlab gerir þér kleift að ræsa nokkra dreifða Gitlab Runners, sem munu einfaldlega taka öll verkefnin eitt af öðru í óskipulegri röð og keyra þau.

Til að forðast heimilisvandamál takmörkuðum við hóp verkefna okkar við einn Gitlab Runner, sem tekst á við magnið okkar án vandræða.

Við færðum nginx-proxy í sérstakt ræsiforrit og skrifuðum töflur allra verkefna í því.

Verkefnið okkar hefur eitt rist og jafnvægisbúnaðurinn hefur nokkrar töflur byggðar á verkefnaheitum. Það getur umboð frekar með lén.

Beiðnir okkar koma í gegnum lénið á höfn 80 og er leyst til hóps gáma sem þjónar þessu léni.

Hvaða önnur vandamál voru uppi? Þetta er það sem allir gámar keyra sem rót sjálfgefið. Þetta er ójafn rótarhýsill kerfisins.

Hins vegar, ef þú slærð inn ílátið verður það rót og skráin sem við búum til í þessum ílát fær rótarréttindi.

Ef þróunaraðili fór inn í gáminn og gerði nokkrar skipanir þar sem mynduðu skrár, fór síðan úr gámnum, þá er í vinnuskránni sinni skrá sem hann hefur ekki aðgang að.

Hvernig er hægt að leysa þetta? Þú getur bætt við notendum sem verða í gámnum.

Hvaða vandamál komu upp þegar við bættum notandanum við?

Þegar notandi er stofnaður passa hópauðkenni (UID) og notandakenni (GID) oft ekki saman.

Til að leysa þetta vandamál í gámnum notum við notendur með auðkenni 1000.

Í okkar tilviki féll þetta saman við þá staðreynd að næstum allir forritarar nota Ubuntu OS. Og í Ubuntu OS er fyrsti notandinn með ID 1000.

Höfum við áætlanir?

Lestu Docker skjölin aftur. Verkefnið er í virkri þróun, skjöl eru að breytast. Gögn sem fengust fyrir tveimur eða þremur mánuðum eru smám saman að verða úrelt.

Sum vandamálin sem við leystum gætu vel þegar verið leyst með hefðbundnum hætti.

Mig langar virkilega að halda áfram og fara beint í hljómsveitarstjórn.

Eitt dæmi er innbyggður vélbúnaður Docker sem heitir Docker Swarm, sem kemur upp úr kassanum. Mig langar að setja eitthvað af stað í framleiðslu byggt á Docker Swarm tækninni.

Hrygningarílát gera það að verkum að það er óþægilegt að vinna með stokka. Nú eru stokkarnir einangraðir. Þeir eru dreifðir í gámum. Eitt af verkefnunum er að hafa þægilegan aðgang að annálum í gegnum vefviðmót.

Heimild: www.habr.com