Proses ddatblygu a phrofi gyda Docker a Gitlab CI

Cynigiaf ddarllen trawsgrifiad yr adroddiad gan Alexander Sigachev o Inventos "Proses datblygu a phrofi gyda Docker + Gitlab CI"

Mae'r rhai sydd newydd ddechrau gweithredu'r broses ddatblygu a phrofi yn seiliedig ar Docker + Gitlab CI yn aml yn gofyn cwestiynau sylfaenol. Ble i ddechrau? Sut i drefnu? Sut i brofi?

Mae'r adroddiad hwn yn dda oherwydd ei fod yn sôn mewn ffordd strwythuredig am y broses ddatblygu a phrofi gan ddefnyddio Docker a Gitlab CI. Mae’r adroddiad ei hun yn dyddio o 2017. Credaf o'r adroddiad hwn y gallwch ddysgu'r pethau sylfaenol, y fethodoleg, y syniad, a'r profiad o ddefnyddio.

Pwy sy'n gofalu, os gwelwch yn dda o dan y gath.

Fy enw i yw Alexander Sigachev. Rwy'n gweithio i Inventos. Dywedaf wrthych am fy mhrofiad o ddefnyddio Docker a sut yr ydym yn ei roi ar waith yn raddol ar brosiectau yn y cwmni.

Testun y cyflwyniad: Proses ddatblygu gan ddefnyddio Docker a Gitlab CI.

Proses ddatblygu a phrofi gyda Docker a Gitlab CI

Dyma fy ail sgwrs am Docker. Ar adeg yr adroddiad cyntaf, dim ond ar beiriannau datblygwyr y gwnaethom ddefnyddio Docker in Development. Roedd nifer y gweithwyr a ddefnyddiodd Docker tua 2-3 o bobl. Yn raddol, cafwyd profiad a symudom ychydig ymhellach. Dolen i'n adroddiad cyntaf.

Beth fydd yn yr adroddiad hwn? Byddwn yn rhannu ein profiad ynghylch pa gribin rydym wedi'i gasglu, pa broblemau rydym wedi'u datrys. Nid ym mhobman roedd yn brydferth, ond yn gadael i symud ymlaen.

Ein harwyddair yw: doc popeth y gallwn gael ein dwylo ar.

Proses ddatblygu a phrofi gyda Docker a Gitlab CI

Pa broblemau ydyn ni'n eu datrys?

Pan fo sawl tîm mewn cwmni, mae'r rhaglennydd yn adnodd a rennir. Mae yna gyfnodau pan fydd rhaglennydd yn cael ei dynnu allan o un prosiect a'i roi am beth amser i brosiect arall.

Er mwyn i'r rhaglennydd ddeall yn gyflym, mae angen iddo lawrlwytho cod ffynhonnell y prosiect a lansio'r amgylchedd cyn gynted â phosibl, a fydd yn caniatáu iddo symud ymhellach i ddatrys problemau'r prosiect hwn.

Fel arfer, os byddwch chi'n dechrau o'r dechrau, yna ychydig o ddogfennaeth sydd yn y prosiect. Mae gwybodaeth ar sut i sefydlu ar gael i bobl sy'n hen amser yn unig. Mae gweithwyr yn sefydlu eu gweithle ar eu pen eu hunain mewn diwrnod neu ddau. I gyflymu hyn, fe wnaethon ni ddefnyddio Docker.

Y rheswm nesaf yw safoni gosodiadau mewn Datblygiad. Yn fy mhrofiad i, mae datblygwyr bob amser yn cymryd yr awenau. Ym mhob pumed achos, cofnodir parth arfer, er enghraifft, vasya.dev. Yn eistedd wrth ei ymyl mae ei gymydog Petya, y mae ei barth yn petya.dev. Maent yn datblygu gwefan neu ryw elfen o'r system gan ddefnyddio'r enw parth hwn.

Pan fydd y system yn tyfu ac mae'r enwau parth hyn yn dechrau dod i mewn i ffurfweddiadau, mae gwrthdaro amgylchedd Datblygu yn codi ac mae llwybr y wefan yn cael ei ailysgrifennu.

Mae'r un peth yn digwydd gyda gosodiadau cronfa ddata. Nid yw rhywun yn trafferthu gyda diogelwch ac mae'n gweithio gyda chyfrinair gwraidd gwag. Ar y cam gosod, gofynnodd MySQL i rywun am gyfrinair a 123 oedd y cyfrinair. Yn aml mae'n digwydd bod ffurfwedd y gronfa ddata yn newid yn gyson yn dibynnu ar ymrwymiad y datblygwr. Cywirodd rhywun, ni chywirodd rhywun y ffurfwedd. Roedd triciau pan wnaethom gymryd rhyw fath o ffurfwedd prawf i mewn .gitignore ac roedd yn rhaid i bob datblygwr osod y gronfa ddata. Roedd hyn yn ei gwneud hi'n anodd cychwyn arni. Mae angen, ymhlith pethau eraill, i gofio am y gronfa ddata. Rhaid cychwyn y gronfa ddata, rhaid nodi cyfrinair, rhaid cofrestru defnyddiwr, creu tabl, ac ati.

Problem arall yw fersiynau gwahanol o lyfrgelloedd. Yn aml mae'n digwydd bod datblygwr yn gweithio gyda gwahanol brosiectau. Mae yna brosiect Etifeddiaeth a ddechreuodd bum mlynedd yn ôl (o 2017 - nodyn gol). Ar adeg ei lansio, dechreuon ni gyda MySQL 5.5. Mae yna hefyd brosiectau modern lle rydyn ni'n ceisio gweithredu fersiynau mwy modern o MySQL, er enghraifft, 5.7 neu hŷn (yn 2017 - nodyn gol)

Mae unrhyw un sy'n gweithio gyda MySQL yn gwybod bod y llyfrgelloedd hyn yn dod â dibyniaethau gyda nhw. Mae rhedeg 2 sylfaen gyda'i gilydd braidd yn broblemus. O leiaf, mae hen gleientiaid yn broblemus i gysylltu â'r gronfa ddata newydd. Mae hyn yn ei dro yn creu nifer o broblemau.

Y broblem nesaf yw pan fydd datblygwr yn gweithio ar beiriant lleol, mae'n defnyddio adnoddau lleol, ffeiliau lleol, RAM lleol. Mae'r holl ryngweithio ar adeg datblygu datrysiad i broblemau yn cael ei wneud o fewn fframwaith y ffaith ei fod yn gweithio ar un peiriant. Enghraifft yw pan fydd gennym weinyddion backend yn Cynhyrchiad 3, ac mae'r datblygwr yn arbed ffeiliau i'r cyfeiriadur gwraidd ac oddi yno mae nginx yn cymryd ffeiliau i ymateb i'r cais. Pan fydd cod o'r fath yn cyrraedd Cynhyrchu, mae'n ymddangos bod y ffeil yn bresennol ar un o'r 3 gweinydd.

Mae cyfeiriad microwasanaethau yn datblygu nawr. Pan fyddwn yn rhannu ein cymwysiadau mawr yn rhai cydrannau bach sy'n rhyngweithio â'i gilydd. Mae hyn yn caniatáu ichi ddewis technolegau ar gyfer pentwr penodol o dasgau. Mae hefyd yn caniatáu ichi rannu gwaith a chyfrifoldebau rhwng datblygwyr.

Nid oes gan Frondend-datblygwr, sy'n datblygu ar JS, bron unrhyw ddylanwad ar Backend. Mae'r datblygwr backend, yn ei dro, yn datblygu, yn ein hachos ni, Ruby on Rails ac nid yw'n ymyrryd â Frondend. Perfformir y rhyngweithio gan ddefnyddio'r API.

Fel bonws, gyda chymorth Docker, roeddem yn gallu ailgylchu adnoddau ar Lwyfanu. Roedd angen gosodiadau penodol ar bob prosiect, oherwydd ei fanylion penodol. Yn gorfforol, roedd angen dyrannu naill ai gweinydd rhithwir a'u ffurfweddu ar wahân, neu rannu rhyw fath o amgylchedd amrywiol a gallai prosiectau, yn dibynnu ar fersiwn y llyfrgelloedd, ddylanwadu ar ei gilydd.

Proses ddatblygu a phrofi gyda Docker a Gitlab CI

Offer. Beth ydyn ni'n ei ddefnyddio?

  • Dociwr ei hun. Mae'r Dockerfile yn disgrifio dibyniaethau un cymhwysiad.
  • Mae Docker-compose yn fwndel sy'n dod â rhai o'n cymwysiadau Docker ynghyd.
  • Rydym yn defnyddio GitLab i storio'r cod ffynhonnell.
  • Rydym yn defnyddio GitLab-CI ar gyfer integreiddio system.

Proses ddatblygu a phrofi gyda Docker a Gitlab CI

Mae’r adroddiad yn cynnwys dwy ran.

Bydd y rhan gyntaf yn sôn am sut y cafodd Docker ei redeg ar beiriannau datblygwyr.

Bydd yr ail ran yn sôn am sut i ryngweithio â GitLab, sut rydym yn cynnal profion a sut rydym yn cyflwyno i Lwyfanu.

Proses ddatblygu a phrofi gyda Docker a Gitlab CI

Mae Docker yn dechnoleg sy'n caniatáu (gan ddefnyddio dull datganiadol) i ddisgrifio'r cydrannau angenrheidiol. Dyma enghraifft Dockerfile. Yma rydym yn datgan ein bod yn etifeddu o ddelwedd swyddogol Ruby:2.3.0 Docker. Mae'n cynnwys fersiwn Ruby 2.3 wedi'i osod. Rydym yn gosod y llyfrgelloedd adeiladu gofynnol a NodeJS. Rydym yn disgrifio ein bod yn creu cyfeiriadur /app. Gosodwch y cyfeiriadur app fel y cyfeiriadur gweithio. Yn y cyfeiriadur hwn rydym yn gosod y Gemfile lleiaf gofynnol a Gemfile.lock. Yna byddwn yn adeiladu'r prosiectau sy'n gosod y ddelwedd dibyniaeth hon. Rydyn ni'n nodi y bydd y cynhwysydd yn barod i wrando ar borthladd allanol 3000. Y gorchymyn olaf yw'r gorchymyn sy'n lansio ein cais yn uniongyrchol. Os byddwn yn gweithredu'r gorchymyn cychwyn prosiect, bydd y cais yn ceisio rhedeg a rhedeg y gorchymyn penodedig.

Proses ddatblygu a phrofi gyda Docker a Gitlab CI

Dyma enghraifft fach iawn o ffeil cyfansoddi docwr. Yn yr achos hwn, rydym yn dangos bod cysylltiad rhwng dau gynhwysydd. Mae hyn yn uniongyrchol i'r gwasanaeth cronfa ddata a'r gwasanaeth gwe. Mae ein cymwysiadau gwe yn y rhan fwyaf o achosion yn gofyn am ryw fath o gronfa ddata fel ôl-wyneb ar gyfer storio data. Gan ein bod yn defnyddio MySQL, mae'r enghraifft gyda MySQL - ond nid oes dim yn ein hatal rhag defnyddio cronfa ddata arall (PostgreSQL, Redis).

Rydyn ni'n cymryd delwedd MySQL 5.7.14 o'r ffynhonnell swyddogol o ganolbwynt y Docker heb newidiadau. Rydym yn casglu'r ddelwedd sy'n gyfrifol am ein cymhwysiad gwe o'r cyfeiriadur cyfredol. Mae'n casglu delwedd i ni yn ystod y lansiad cyntaf. Yna mae'n rhedeg y gorchymyn yr ydym yn ei weithredu yma. Os awn yn ôl, fe welwn fod y gorchymyn lansio trwy Puma wedi'i ddiffinio. Mae Puma yn wasanaeth a ysgrifennwyd yn Ruby. Yn yr ail achos, rydym yn diystyru. Gall y gorchymyn hwn fod yn fympwyol yn dibynnu ar ein hanghenion neu ein tasgau.

Rydym hefyd yn disgrifio bod angen inni anfon porthladd ymlaen ar ein peiriant gwesteiwr datblygwr o 3000 i 3000 ar y porthladd cynhwysydd. Gwneir hyn yn awtomatig gan ddefnyddio iptables a'i fecanwaith, sydd wedi'i ymgorffori'n uniongyrchol yn Docker.

Gall y datblygwr hefyd, fel o'r blaen, gael mynediad i unrhyw gyfeiriad IP sydd ar gael, er enghraifft, 127.0.0.1 yw cyfeiriad IP lleol neu allanol y peiriant.

Mae'r llinell olaf yn dweud bod y cynhwysydd gwe yn dibynnu ar y cynhwysydd db. Pan fyddwn yn galw cychwyn y cynhwysydd gwe, bydd docker-compose yn cychwyn y gronfa ddata i ni yn gyntaf. Eisoes ar ddechrau'r gronfa ddata (yn wir, ar ôl lansio'r cynhwysydd! Nid yw hyn yn gwarantu parodrwydd y gronfa ddata) yn lansio'r cais, ein backend.

Mae hyn yn osgoi gwallau pan nad yw'r gronfa ddata i fyny ac yn arbed adnoddau pan fyddwn yn atal y cynhwysydd cronfa ddata, gan ryddhau adnoddau ar gyfer prosiectau eraill.

Proses ddatblygu a phrofi gyda Docker a Gitlab CI

Beth sy'n rhoi i ni ddefnyddio dockerization cronfa ddata ar y prosiect. Rydym yn trwsio'r fersiwn o MySQL ar gyfer pob datblygwr. Mae hyn yn osgoi rhai gwallau a all ddigwydd pan fydd fersiynau'n ymwahanu, pan fydd y gystrawen, y ffurfweddiad, y gosodiadau diofyn yn newid. Mae hyn yn caniatáu ichi nodi enw gwesteiwr cyffredin ar gyfer y gronfa ddata, mewngofnodi, cyfrinair. Rydym yn symud i ffwrdd o'r sw o enwau a gwrthdaro yn y ffeiliau ffurfweddu a oedd gennym yn gynharach.

Mae gennym gyfle i ddefnyddio cyfluniad mwy optimaidd ar gyfer yr amgylchedd Datblygu, a fydd yn wahanol i'r rhagosodiad. Mae MySQL wedi'i ffurfweddu ar gyfer peiriannau gwan yn ddiofyn ac mae ei berfformiad allan o'r bocs yn wael iawn.

Proses ddatblygu a phrofi gyda Docker a Gitlab CI

Mae Docker yn caniatáu ichi ddefnyddio dehonglydd Python, Ruby, NodeJS, PHP o'r fersiwn a ddymunir. Rydym yn cael gwared ar yr angen i ddefnyddio rhyw fath o reolwr fersiwn. Yn flaenorol, defnyddiodd Ruby becyn rpm a oedd yn caniatáu ichi newid y fersiwn yn dibynnu ar y prosiect. Mae hefyd yn caniatáu, diolch i'r cynhwysydd Docker, i fudo'r cod yn llyfn a'i fersiwn ynghyd â dibyniaethau. Nid oes gennym unrhyw broblem yn deall fersiwn y cyfieithydd a'r cod. I ddiweddaru'r fersiwn, gostyngwch yr hen gynhwysydd a chodwch y cynhwysydd newydd. Os aeth rhywbeth o'i le, gallwn ostwng y cynhwysydd newydd, codi'r hen gynhwysydd.

Ar ôl adeiladu'r ddelwedd, bydd y cynwysyddion yn y ddau Ddatblygu a Chynhyrchu yr un peth. Mae hyn yn arbennig o wir ar gyfer gosodiadau mawr.

Proses ddatblygu a phrofi gyda Docker a Gitlab CI Ar Frontend rydym yn defnyddio JavaScipt a NodeJS.

Nawr mae gennym y prosiect olaf ar ReacJS. Rhedodd y datblygwr bopeth yn y cynhwysydd a datblygu gan ddefnyddio ail-lwytho poeth.

Nesaf, mae tasg cydosod JavaScipt yn cael ei lansio a rhoddir y cod a luniwyd yn statig trwy adnoddau arbed nginx.

Proses ddatblygu a phrofi gyda Docker a Gitlab CI

Yma rwyf wedi rhoi cynllun ein prosiect diwethaf.

Pa dasgau gafodd eu datrys? Roedd angen i ni adeiladu system y mae dyfeisiau symudol yn rhyngweithio â hi. Maent yn derbyn data. Un posibilrwydd yw anfon hysbysiadau gwthio i'r ddyfais hon.

Beth ydym ni wedi'i wneud ar gyfer hyn?

Fe wnaethon ni rannu cydrannau fel: y rhan weinyddol ar JS, y backend, sy'n gweithio trwy'r rhyngwyneb REST o dan Ruby on Rails i'r cymhwysiad. Mae'r backend yn rhyngweithio â'r gronfa ddata. Rhoddir y canlyniad a gynhyrchir i'r cleient. Mae'r panel gweinyddol yn rhyngweithio â'r backend a'r gronfa ddata trwy'r rhyngwyneb REST.

Roedd angen i ni anfon hysbysiadau gwthio hefyd. Cyn hynny, roedd gennym brosiect a roddodd fecanwaith ar waith sy'n gyfrifol am gyflwyno hysbysiadau i lwyfannau symudol.

Rydym wedi datblygu'r cynllun canlynol: mae gweithredwr o'r porwr yn rhyngweithio â'r panel gweinyddol, mae'r panel gweinyddol yn rhyngweithio â'r backend, y dasg yw anfon hysbysiadau Push.

Mae hysbysiadau gwthio yn rhyngweithio ag elfen arall sy'n cael ei gweithredu yn NodeJS.

Mae ciwiau'n cael eu hadeiladu ac yna anfonir hysbysiadau yn unol â'u mecanwaith.

Tynnir dwy gronfa ddata yma. Ar hyn o bryd, gyda chymorth Docker, rydym yn defnyddio 2 gronfa ddata annibynnol nad ydynt yn gysylltiedig â'i gilydd mewn unrhyw ffordd. Yn ogystal, mae ganddynt rwydwaith rhithwir cyffredin, ac mae data corfforol yn cael ei storio mewn gwahanol gyfeiriaduron ar beiriant y datblygwr.

Proses ddatblygu a phrofi gyda Docker a Gitlab CI

Yr un peth ond mewn niferoedd. Dyma lle mae ailddefnyddio cod yn bwysig.

Os buom yn siarad yn gynharach am ailddefnyddio cod ar ffurf llyfrgelloedd, yna yn yr enghraifft hon, mae ein gwasanaeth sy'n ymateb i hysbysiadau Push yn cael ei ailddefnyddio fel gweinydd cyflawn. Mae'n darparu API. Ac mae ein datblygiad newydd eisoes yn rhyngweithio ag ef.

Bryd hynny, roeddem yn defnyddio fersiwn 4 o NodeJS. Nawr (yn 2017 - nodyn gol) mewn datblygiadau diweddar rydym yn defnyddio fersiwn 7 o NodeJS. Nid oes problem mewn cydrannau newydd i gynnwys fersiynau newydd o lyfrgelloedd.

Os oes angen, gallwch ailffactorio a chodi'r fersiwn NodeJS o'r gwasanaeth hysbysu Push.

Ac os gallwn gynnal cydnawsedd API, yna bydd yn bosibl ei ddisodli â phrosiectau eraill a ddefnyddiwyd yn flaenorol.

Proses ddatblygu a phrofi gyda Docker a Gitlab CI

Beth sydd angen i chi ei ychwanegu Docker? Rydym yn ychwanegu Dockerfile at ein cadwrfa, sy'n disgrifio'r dibyniaethau angenrheidiol. Yn yr enghraifft hon, mae'r cydrannau'n cael eu torri i lawr yn rhesymegol. Dyma set leiaf datblygwr backend.

Wrth greu prosiect newydd, rydym yn creu Dockerfile, yn disgrifio'r ecosystem a ddymunir (Python, Ruby, NodeJS). Yn docker-compose, mae'n disgrifio'r ddibyniaeth angenrheidiol - y gronfa ddata. Rydym yn disgrifio bod angen cronfa ddata o'r fath a fersiwn o'r fath, storio data yn y fan a'r lle.

Rydym yn defnyddio trydydd cynhwysydd ar wahân gyda nginx i wasanaethu'n sefydlog. Mae'n bosibl uwchlwytho lluniau. Mae backend yn eu rhoi mewn cyfrol a baratowyd ymlaen llaw, sydd hefyd wedi'i osod mewn cynhwysydd â nginx, sy'n rhoi'r statig.

I storio'r cyfluniad nginx, mysql, fe wnaethom ychwanegu ffolder Docker lle rydym yn storio'r cyfluniadau angenrheidiol. Pan fydd datblygwr yn gwneud clôn git o ystorfa ar ei beiriant, mae ganddo brosiect yn barod ar gyfer datblygiad lleol. Nid oes unrhyw gwestiwn pa borthladd na pha osodiadau i'w cymhwyso.

Proses ddatblygu a phrofi gyda Docker a Gitlab CI

Nesaf, mae gennym sawl cydran: gweinyddol, hysbys-API, hysbysiadau gwthio.

Er mwyn cychwyn hyn i gyd, fe wnaethon ni greu ystorfa arall, y gwnaethom ei galw'n dockerized-app. Ar hyn o bryd rydym yn defnyddio sawl ystorfa cyn pob cydran. Maent yn wahanol yn rhesymegol - yn GitLab mae'n edrych fel ffolder, ond ar beiriant y datblygwr, ffolder ar gyfer prosiect penodol. Un lefel i lawr yw'r cydrannau a fydd yn cael eu cyfuno.

Proses ddatblygu a phrofi gyda Docker a Gitlab CI

Dyma enghraifft o gynnwys dockerized-app yn unig. Rydyn ni hefyd yn dod â chyfeiriadur Docker yma, lle rydyn ni'n llenwi'r ffurfweddiadau sy'n ofynnol ar gyfer rhyngweithiadau'r holl gydrannau. Mae yna README.md sy'n disgrifio'n gryno sut i redeg y prosiect.

Yma rydym wedi cymhwyso dwy ffeil cyfansoddi docwr. Gwneir hyn er mwyn gallu rhedeg mewn camau. Pan fydd datblygwr yn gweithio gyda'r craidd, nid oes angen hysbysiadau gwthio arno, yn syml mae'n lansio ffeil cyfansoddi docwr ac, yn unol â hynny, mae'r adnodd yn cael ei arbed.

Os oes angen integreiddio â hysbysiadau gwthio, yna mae docker-compose.yaml a docker-compose-push.yaml yn cael eu lansio.

Gan fod docker-compose.yaml a docker-compose-push.yaml mewn ffolder, mae un rhwydwaith rhithwir yn cael ei greu yn awtomatig.

Proses ddatblygu a phrofi gyda Docker a Gitlab CI

Disgrifiad o'r cydrannau. Mae hon yn ffeil fwy datblygedig sy'n gyfrifol am gasglu cydrannau. Beth sy'n hynod yma? Yma rydym yn cyflwyno'r gydran balancer.

Mae hon yn ddelwedd Docker parod sy'n rhedeg nginx a chymhwysiad sy'n gwrando ar soced y Docker. Yn ddeinamig, wrth i gynwysyddion gael eu troi ymlaen ac i ffwrdd, mae'n adfywio'r ffurfwedd nginx. Rydym yn dosbarthu trin cydrannau yn ôl enwau parth trydydd lefel.

Ar gyfer yr amgylchedd Datblygu, rydym yn defnyddio'r parth .dev - api.informer.dev. Mae cymwysiadau gyda pharth .dev ar gael ar beiriant lleol y datblygwr.

Ymhellach, trosglwyddir cyfluniadau i bob prosiect a chaiff pob prosiect ei lansio gyda'i gilydd ar yr un pryd.

Proses ddatblygu a phrofi gyda Docker a Gitlab CI

Yn graffigol, mae'n ymddangos mai'r cleient yw ein porwr neu ryw offeryn yr ydym yn gwneud ceisiadau i'r balancer ag ef.

Mae'r cydbwysedd enw parth yn pennu pa gynhwysydd i gysylltu ag ef.

Gall fod yn nginx, sy'n rhoi'r JS gweinyddol. Gall hyn fod yn nginx, sy'n rhoi'r API, neu ffeiliau statig, a roddir i nginx ar ffurf uwchlwythiadau delwedd.

Mae'r diagram yn dangos bod y cynwysyddion wedi'u cysylltu gan rwydwaith rhithwir ac wedi'u cuddio y tu ôl i ddirprwy.

Ar beiriant y datblygwr, gallwch gael mynediad i'r cynhwysydd gan wybod yr IP, ond mewn egwyddor nid ydym yn defnyddio hyn. Nid oes angen mynediad uniongyrchol bron.

Proses ddatblygu a phrofi gyda Docker a Gitlab CI

Pa enghraifft i edrych arni i docio'ch cais? Yn fy marn i, enghraifft dda yw delwedd swyddogol y docwr ar gyfer MySQL.

Mae'n eithaf heriol. Mae yna lawer o fersiynau. Ond mae ei ymarferoldeb yn caniatáu ichi gwmpasu llawer o anghenion a all godi yn y broses o ddatblygu ymhellach. Os ydych chi'n treulio amser ac yn darganfod sut mae'r cyfan yn rhyngweithio, yna rwy'n credu na fyddwch chi'n cael unrhyw broblemau o ran hunan-weithredu.

Mae Hub.docker.com fel arfer yn cynnwys dolenni i github.com, sy'n cynnwys data crai yn uniongyrchol y gallwch chi adeiladu'r ddelwedd eich hun ohono.

Ymhellach yn yr ystorfa hon mae sgript docker-endpoint.sh, sy'n gyfrifol am y cychwyniad cychwynnol ac am brosesu lansiad y cais ymhellach.

Hefyd yn yr enghraifft hon, mae'r gallu i ffurfweddu gan ddefnyddio newidynnau amgylchedd. Trwy ddiffinio newidyn amgylchedd wrth redeg cynhwysydd sengl neu drwy docker-compose, gallwn ddweud bod angen i ni osod cyfrinair gwag i docwr wreiddio ar MySQL neu beth bynnag yr ydym ei eisiau.

Mae opsiwn i greu cyfrinair ar hap. Rydyn ni'n dweud bod angen defnyddiwr arnom ni, mae angen i ni osod cyfrinair ar gyfer y defnyddiwr, ac mae angen i ni greu cronfa ddata.

Yn ein prosiectau, fe wnaethom uno'r Dockerfile ychydig, sy'n gyfrifol am gychwyn. Yno fe wnaethom ei gywiro i'n hanghenion i'w wneud yn estyniad yn unig o'r hawliau defnyddiwr y mae'r rhaglen yn eu defnyddio. Roedd hyn yn caniatáu i ni greu cronfa ddata o'r consol cymwysiadau yn nes ymlaen. Mae gan geisiadau Ruby orchymyn ar gyfer creu, addasu a dileu cronfeydd data.

Proses ddatblygu a phrofi gyda Docker a Gitlab CI

Dyma enghraifft o sut olwg sydd ar fersiwn benodol o MySQL ar github.com. Gallwch agor y Dockerfile a gweld sut mae'r gosodiad yn mynd ymlaen yno.

docker-endpoint.sh yw'r sgript sy'n gyfrifol am y pwynt mynediad. Yn ystod y cychwyniad cychwynnol, mae angen rhai camau paratoi, a chymerir yr holl gamau hyn yn y sgript ymgychwyn yn unig.

Proses ddatblygu a phrofi gyda Docker a Gitlab CI

Gadewch i ni symud ymlaen i'r ail ran.

I storio'r codau ffynhonnell, fe wnaethom newid i gitlab. Mae hon yn system eithaf pwerus sydd â rhyngwyneb gweledol.

Un o gydrannau Gitlab yw Gitlab CI. Mae'n caniatáu ichi ddisgrifio dilyniant o orchmynion a fydd yn cael eu defnyddio'n ddiweddarach i drefnu system cyflwyno cod neu redeg profion awtomatig.

Sgwrs Gitlab CI 2 https://goo.gl/uohKjI - adroddiad gan glwb Ruby Russia - eithaf manwl ac efallai y bydd o ddiddordeb i chi.

Proses ddatblygu a phrofi gyda Docker a Gitlab CI

Nawr byddwn yn edrych ar yr hyn sydd ei angen er mwyn actifadu Gitlab CI. Er mwyn cychwyn Gitlab CI, does ond angen i ni roi'r ffeil .gitlab-ci.yml yng ngwraidd y prosiect.

Yma rydym yn disgrifio ein bod am weithredu dilyniant o gyflyrau fel prawf, defnyddio.

Rydym yn gweithredu sgriptiau sy'n galw docker-compose yn uniongyrchol i adeiladu ein cymhwysiad. Dim ond enghraifft gefn yw hon.

Nesaf, dywedwn fod angen rhedeg mudo i newid y gronfa ddata a chynnal profion.

Os caiff y sgriptiau eu gweithredu'n gywir ac nad yw'n dychwelyd cod gwall, yna mae'r system yn mynd ymlaen i ail gam y gosodiad.

Mae'r cam lleoli yn cael ei weithredu ar hyn o bryd ar gyfer llwyfannu. Ni wnaethom drefnu ailgychwyn amser segur.

Rydyn ni'n diffodd yr holl gynwysyddion yn rymus, ac yna rydyn ni'n codi'r holl gynwysyddion eto, a gasglwyd yn y cam cyntaf yn ystod y profion.

Rydym yn rhedeg ar gyfer y newidyn amgylchedd presennol y mudo cronfa ddata a ysgrifennwyd gan y datblygwyr.

Mae nodyn bod hyn yn berthnasol i'r brif gangen yn unig.

Pan na fydd newid canghennau eraill yn cael ei weithredu.

Mae'n bosibl trefnu cyflwyno fesul cangen.

Proses ddatblygu a phrofi gyda Docker a Gitlab CI

I drefnu hyn ymhellach, mae angen i ni osod Gitlab Runner.

Mae'r defnyddioldeb hwn wedi'i ysgrifennu yn Golang. Mae'n ffeil sengl, fel sy'n gyffredin yn y byd Golang, nad oes angen unrhyw ddibyniaethau arni.

Wrth gychwyn, rydym yn cofrestru'r Rhedwr Gitlab.

Rydyn ni'n cael yr allwedd yn rhyngwyneb gwe Gitlab.

Yna rydym yn galw'r gorchymyn cychwyn ar y llinell orchymyn.

Sefydlu Gitlab Runner yn rhyngweithiol (Shell, Docker, VirtualBox, SSH)

Bydd y cod ar Gitlab Runner yn gweithredu ar bob ymrwymiad, yn dibynnu ar y gosodiad .gitlab-ci.yml.

Proses ddatblygu a phrofi gyda Docker a Gitlab CI

Sut mae'n edrych yn weledol yn Gitlab yn y rhyngwyneb gwe. Ar ôl i ni gysylltu GItlab CI, mae gennym faner sy'n dangos cyflwr yr adeiladwaith ar hyn o bryd.

Gwelwn fod ymrwymiad wedi'i wneud 4 munud yn ôl, a basiodd yr holl brofion ac nad oedd yn achosi unrhyw broblemau.

Proses ddatblygu a phrofi gyda Docker a Gitlab CI

Gallwn edrych yn agosach ar yr adeiladau. Yma gwelwn fod dwy dalaith eisoes wedi mynd heibio. Profi statws a statws lleoli ar lwyfannu.

Os byddwn yn clicio ar adeiladwaith penodol, yna bydd allbwn consol o'r gorchmynion a gafodd eu rhedeg yn y broses yn ôl .gitlab-ci.yml.

Proses ddatblygu a phrofi gyda Docker a Gitlab CI

Dyma sut olwg sydd ar hanes ein cynnyrch. Gwelwn fod ymdrechion llwyddiannus. Pan gyflwynir profion, nid yw'n symud ymlaen i'r cam nesaf ac nid yw'r cod llwyfannu yn cael ei ddiweddaru.

Proses ddatblygu a phrofi gyda Docker a Gitlab CI

Pa dasgau wnaethon ni eu datrys ar lwyfannu pan wnaethom weithredu docker? Mae ein system yn cynnwys cydrannau ac roedd angen i ni ailgychwyn, dim ond rhan o'r cydrannau a ddiweddarwyd yn y storfa, ac nid y system gyfan.

I wneud hyn, roedd yn rhaid i ni dorri popeth i ffolderi ar wahân.

Ar ôl i ni wneud hyn, cawsom broblem gyda'r ffaith bod Docker-compose yn creu ei ofod rhwydwaith ei hun ar gyfer pob tad ac nid yw'n gweld cydrannau'r cymydog.

Er mwyn symud o gwmpas, fe wnaethon ni greu'r rhwydwaith yn Docker â llaw. Fe'i hysgrifennwyd yn Docker-compose eich bod yn defnyddio rhwydwaith o'r fath ar gyfer y prosiect hwn.

Felly, mae pob cydran sy'n dechrau gyda'r rhwyll hon yn gweld cydrannau mewn rhannau eraill o'r system.

Y rhifyn nesaf yw rhannu llwyfannu ar draws prosiectau lluosog.

Ers er mwyn i hyn i gyd edrych yn hardd ac mor agos â phosibl at gynhyrchu, mae'n dda defnyddio porthladd 80 neu 443, a ddefnyddir ym mhobman yn y WEB.

Proses ddatblygu a phrofi gyda Docker a Gitlab CI

Sut wnaethon ni ei ddatrys? Rydym wedi neilltuo un Rhedwr Gitlab i bob prosiect mawr.

Mae Gitlab yn caniatáu ichi redeg sawl rhedwr Gitlab dosbarthedig, a fydd yn syml yn cymryd yr holl dasgau yn eu tro mewn modd anhrefnus a'u rhedeg.

Fel nad oes gennym ni dŷ, fe wnaethom gyfyngu’r grŵp o’n prosiectau i un Gitlab Runner, sy’n ymdopi heb broblemau gyda’n cyfeintiau.

Fe wnaethom symud nginx-proxy i sgript cychwyn ar wahân ac ychwanegu gridiau ar gyfer pob prosiect ynddo.

Mae gan ein prosiect un grid, ac mae gan y balancer sawl grid yn ôl enwau prosiectau. Gall ddirprwy ymhellach yn ôl enwau parth.

Daw ein ceisiadau trwy'r parth ar borthladd 80 ac fe'u datrysir yn grŵp cynwysyddion sy'n gwasanaethu'r parth hwn.

Proses ddatblygu a phrofi gyda Docker a Gitlab CI

Pa broblemau eraill oedd yna? Dyma beth mae pob cynhwysydd yn rhedeg fel gwraidd yn ddiofyn. Mae hwn yn gwraidd yn anghyfartal â gwraidd gwesteiwr y system.

Fodd bynnag, os byddwch chi'n mynd i mewn i'r cynhwysydd, bydd yn gwraidd ac mae'r ffeil rydyn ni'n ei chreu yn y cynhwysydd hwn yn cael hawliau gwraidd.

Pe bai'r datblygwr yn mynd i mewn i'r cynhwysydd ac wedi gwneud rhai gorchmynion yno sy'n cynhyrchu ffeiliau, yna gadael y cynhwysydd, yna mae ganddo ffeil yn ei gyfeiriadur gwaith nad oes ganddo fynediad iddi.

Sut y gellir ei datrys? Gallwch ychwanegu defnyddwyr a fydd yn y cynhwysydd.

Pa broblemau a gododd pan wnaethom ychwanegu'r defnyddiwr?

Wrth greu defnyddiwr, yn aml nid oes gennym yr un ID grŵp (UID) a ID defnyddiwr (GID).

I ddatrys y broblem hon yn y cynhwysydd, rydym yn defnyddio defnyddwyr ag ID 1000.

Yn ein hachos ni, roedd hyn yn cyd-daro â'r ffaith bod bron pob datblygwr yn defnyddio'r Ubuntu OS. Ac ar Ubuntu, mae gan y defnyddiwr cyntaf ID o 1000.

Proses ddatblygu a phrofi gyda Docker a Gitlab CI

A oes gennym ni gynlluniau?

Darllenwch ddogfennaeth y Docker. Mae'r prosiect wrthi'n datblygu, mae'r ddogfennaeth yn newid. Mae'r data a dderbyniwyd ddau neu dri mis yn ôl eisoes yn mynd yn hen ffasiwn yn raddol.

Mae'n ddigon posibl bod rhai o'r problemau y gwnaethom eu datrys eisoes wedi'u datrys drwy ddulliau safonol.

Felly rwyf am fynd ymhellach yn barod i fynd yn uniongyrchol at yr offeryniaeth.

Un enghraifft yw mecanwaith adeiledig Docker o'r enw Docker Swarm, sy'n dod allan o'r bocs. Rwyf am redeg rhywbeth ym maes cynhyrchu yn seiliedig ar dechnoleg Docker Swarm.

Mae cynwysyddion silio yn ei gwneud hi'n anghyfleus i weithio gyda boncyffion. Nawr mae'r logiau wedi'u hynysu. Maent wedi'u gwasgaru ar draws cynwysyddion. Un o'r tasgau yw gwneud mynediad cyfleus i'r logiau trwy'r rhyngwyneb gwe.

Proses ddatblygu a phrofi gyda Docker a Gitlab CI

Ffynhonnell: hab.com

Ychwanegu sylw