Ninapendekeza kusoma nakala ya ripoti ya Alexander Sigachev kutoka Inventos "Maendeleo na mchakato wa upimaji na Docker + Gitlab CI"
Wale ambao ndio wanaanza kutekeleza mchakato wa ukuzaji na upimaji kulingana na Docker + Gitlab CI mara nyingi huuliza maswali ya kimsingi. Wapi kuanza? Jinsi ya kupanga? Jinsi ya kupima?
Ripoti hii ni nzuri kwa sababu inazungumza kwa njia iliyopangwa kuhusu mchakato wa ukuzaji na majaribio kwa kutumia Docker na Gitlab CI. Ripoti yenyewe ni ya 2017. Nadhani kutoka kwa ripoti hii unaweza kujifunza misingi, mbinu, wazo, uzoefu wa matumizi.
Nani anajali, tafadhali chini ya paka.
Jina langu ni Alexander Sigachev. Ninafanya kazi Inventos. Nitakuambia kuhusu uzoefu wangu wa kutumia Docker na jinsi tunavyoitekeleza hatua kwa hatua kwenye miradi katika kampuni.
Mada ya uwasilishaji: Mchakato wa ukuzaji kwa kutumia Docker na Gitlab CI.
Hii ni mazungumzo yangu ya pili kuhusu Docker. Wakati wa ripoti ya kwanza, tulitumia Docker in Development kwenye mashine za wasanidi pekee. Idadi ya wafanyikazi waliotumia Docker ilikuwa takriban watu 2-3. Hatua kwa hatua, uzoefu ulipatikana na tukasonga mbele kidogo. Kiungo chetu .
Nini kitakuwa katika ripoti hii? Tutashiriki uzoefu wetu kuhusu kile tafuta tulichokusanya, matatizo gani tumetatua. Si kila mahali ilikuwa nzuri, lakini kuruhusiwa kuendelea.
Wito wetu ni: tia kila kitu tunaweza kupata mikono yetu.
Je, tunatatua matatizo gani?
Wakati kuna timu kadhaa katika kampuni, programu ni rasilimali iliyoshirikiwa. Kuna hatua wakati programu inatolewa kutoka kwa mradi mmoja na kutolewa kwa muda kwa mradi mwingine.
Ili programu kuelewa haraka, anahitaji kupakua msimbo wa chanzo wa mradi na kuzindua mazingira haraka iwezekanavyo, ambayo itamruhusu kusonga zaidi kutatua matatizo ya mradi huu.
Kawaida, ikiwa unaanza kutoka mwanzo, basi kuna nyaraka kidogo katika mradi huo. Taarifa kuhusu jinsi ya kusanidi inapatikana kwa watu wa zamani pekee. Wafanyikazi huweka mahali pao pa kazi peke yao kwa siku moja au mbili. Ili kuharakisha hii, tulitumia Docker.
Sababu inayofuata ni kusawazisha mipangilio katika Maendeleo. Katika uzoefu wangu, watengenezaji daima huchukua hatua. Katika kila kesi ya tano, kikoa cha desturi kinaingizwa, kwa mfano, vasya.dev. Ameketi karibu naye ni jirani yake Petya, ambaye kikoa chake ni petya.dev. Wanatengeneza tovuti au sehemu fulani ya mfumo kwa kutumia jina hili la kikoa.
Mfumo unapokua na majina haya ya vikoa kuanza kuingia katika usanidi, basi mzozo wa mazingira ya Uendelezaji hutokea na njia ya tovuti kuandikwa upya.
Vile vile hufanyika na mipangilio ya hifadhidata. Mtu hajisumbui na usalama na hufanya kazi na nenosiri tupu la mizizi. Katika hatua ya usakinishaji, MySQL ilimwomba mtu nenosiri na nenosiri likageuka kuwa 123. Mara nyingi hutokea kwamba usanidi wa hifadhidata unabadilika kila wakati kulingana na ahadi ya msanidi programu. Mtu alirekebisha, mtu hakurekebisha usanidi. Kulikuwa na hila tulipochukua aina fulani ya usanidi wa jaribio .gitignore na kila msanidi alilazimika kusanikisha hifadhidata. Hii ilifanya iwe vigumu kuanza. Ni muhimu, kati ya mambo mengine, kukumbuka kuhusu hifadhidata. Database lazima ianzishwe, nenosiri lazima liingizwe, mtumiaji lazima aandikishwe, meza inapaswa kuundwa, na kadhalika.
Tatizo jingine ni matoleo tofauti ya maktaba. Mara nyingi hutokea kwamba msanidi hufanya kazi na miradi tofauti. Kuna mradi wa Urithi ambao ulianza miaka mitano iliyopita (kutoka 2017 - ed. note). Wakati wa uzinduzi, tulianza na MySQL 5.5. Pia kuna miradi ya kisasa ambapo tunajaribu kutekeleza matoleo ya kisasa zaidi ya MySQL, kwa mfano, 5.7 au zaidi (mnamo 2017 - ed. note)
Mtu yeyote anayefanya kazi na MySQL anajua kuwa maktaba hizi huleta utegemezi nazo. Ni shida sana kuendesha besi 2 pamoja. Angalau, wateja wa zamani wana shida kuunganisha kwenye hifadhidata mpya. Hii, kwa upande wake, husababisha shida kadhaa.
Tatizo linalofuata ni wakati msanidi anafanya kazi kwenye mashine ya ndani, anatumia rasilimali za ndani, faili za mitaa, RAM ya ndani. Uingiliano wote wakati wa kuendeleza ufumbuzi wa matatizo unafanywa ndani ya mfumo wa ukweli kwamba inafanya kazi kwenye mashine moja. Mfano ni wakati tuna seva za nyuma katika Uzalishaji 3, na msanidi programu huhifadhi faili kwenye saraka ya mizizi na kutoka hapo nginx huchukua faili kujibu ombi. Wakati nambari kama hiyo inapoingia kwenye Uzalishaji, zinageuka kuwa faili iko kwenye moja ya seva 3.
Mwelekeo wa microservices unaendelea sasa. Tunapogawanya programu zetu kubwa katika vipengele vidogo vinavyoingiliana. Hii hukuruhusu kuchagua teknolojia kwa safu maalum ya kazi. Pia hukuruhusu kushiriki kazi na majukumu kati ya wasanidi programu.
Msanidi programu wa Frondend, anayeendelea kwenye JS, hana ushawishi wowote kwenye Backend. Msanidi wa backend, kwa upande wake, hukuza, kwa upande wetu, Ruby kwenye Reli na haiingilii na Frondend. Mwingiliano unafanywa kwa kutumia API.
Kama bonasi, kwa usaidizi wa Docker, tuliweza kuchakata rasilimali kwenye Staging. Kila mradi, kwa sababu ya maelezo yake maalum, ulihitaji mipangilio fulani. Kimwili, ilihitajika kutenga seva pepe na kuisanidi kando, au kushiriki aina fulani ya mazingira na miradi inaweza, kulingana na toleo la maktaba, kuathiri kila mmoja.
Zana. Je, tunatumia nini?
- Docker yenyewe. Dockerfile inaelezea utegemezi wa programu moja.
- Docker-compose ni kifurushi ambacho huleta pamoja programu chache zetu za Docker.
- Tunatumia GitLab kuhifadhi msimbo wa chanzo.
- Tunatumia GitLab-CI kwa ujumuishaji wa mfumo.
Ripoti hiyo ina sehemu mbili.
Sehemu ya kwanza itazungumza juu ya jinsi Docker ilivyoendeshwa kwenye mashine za watengenezaji.
Sehemu ya pili itazungumza juu ya jinsi ya kuingiliana na GitLab, jinsi tunavyoendesha majaribio na jinsi tunavyoeneza kwa Staging.
Docker ni teknolojia ambayo inaruhusu (kwa kutumia mbinu ya kutangaza) kuelezea vipengele muhimu. Huu ni mfano wa Dockerfile. Hapa tunatangaza kwamba tunarithi kutoka kwa picha rasmi ya Ruby:2.3.0 Docker. Ina toleo la Ruby 2.3 lililowekwa. Tunaweka maktaba za ujenzi zinazohitajika na NodeJS. Tunaelezea kwamba tunaunda saraka /app. Weka saraka ya programu kama saraka ya kufanya kazi. Katika saraka hii tunaweka Gemfile ndogo inayohitajika na Gemfile.lock. Kisha tunaunda miradi inayosakinisha picha hii ya utegemezi. Tunaonyesha kwamba kontena itakuwa tayari kusikilizwa kwenye bandari ya nje 3000. Amri ya mwisho ni amri ambayo huzindua programu yetu moja kwa moja. Ikiwa tutafanya amri ya kuanza kwa mradi, programu itajaribu kukimbia na kutekeleza amri maalum.
Huu ni mfano mdogo wa faili ya kutunga docker. Katika kesi hii, tunaonyesha kuwa kuna uhusiano kati ya vyombo viwili. Hii ni moja kwa moja kwenye huduma ya hifadhidata na huduma ya wavuti. Programu zetu za wavuti katika hali nyingi zinahitaji aina fulani ya hifadhidata kama msingi wa kuhifadhi data. Kwa kuwa tunatumia MySQL, mfano uko kwa MySQL - lakini hakuna kinachotuzuia kutumia hifadhidata nyingine (PostgreSQL, Redis).
Tunachukua kutoka kwa chanzo rasmi kutoka kwa kitovu cha Docker picha ya MySQL 5.7.14 bila mabadiliko. Tunakusanya picha ambayo inawajibika kwa programu yetu ya wavuti kutoka kwa saraka ya sasa. Inatukusanyia picha wakati wa uzinduzi wa kwanza. Kisha inaendesha amri ambayo tunatekeleza hapa. Ikiwa tunarudi nyuma, tutaona kwamba amri ya uzinduzi kupitia Puma imefafanuliwa. Puma ni huduma iliyoandikwa kwa Ruby. Katika kesi ya pili, tunapuuza. Amri hii inaweza kuwa ya kiholela kulingana na mahitaji au kazi zetu.
Pia tunaeleza kuwa tunahitaji kusambaza lango kwenye mashine yetu ya kupangisha msanidi kutoka 3000 hadi 3000 kwenye mlango wa kontena. Hii inafanywa kiotomatiki kwa kutumia iptables na utaratibu wake, ambao umewekwa moja kwa moja kwenye Docker.
Msanidi pia anaweza, kama hapo awali, kufikia anwani yoyote ya IP inayopatikana, kwa mfano, 127.0.0.1 ni anwani ya IP ya ndani au nje ya mashine.
Mstari wa mwisho unasema kwamba kontena ya wavuti inategemea chombo cha db. Tunapoita mwanzo wa kontena ya wavuti, docker-compose itaanza kwanza hifadhidata kwa ajili yetu. Tayari mwanzoni mwa hifadhidata (kwa kweli, baada ya uzinduzi wa chombo! Hii haina dhamana ya utayari wa hifadhidata) itazindua programu, backend yetu.
Hii huepuka hitilafu wakati hifadhidata haijaletwa na huhifadhi rasilimali tunaposimamisha kontena ya hifadhidata, hivyo basi kutoa rasilimali kwa miradi mingine.
Ni nini kinatupa matumizi ya uwekaji hifadhidata kwenye mradi huo. Tunarekebisha toleo la MySQL kwa watengenezaji wote. Hii huepuka baadhi ya makosa ambayo yanaweza kutokea matoleo yanapotofautiana, wakati sintaksia, usanidi, mipangilio chaguo-msingi inabadilika. Hii inakuwezesha kutaja jina la mwenyeji la kawaida kwa hifadhidata, kuingia, nenosiri. Tunaondoka kwenye mbuga ya wanyama ya majina na migogoro katika faili za usanidi ambazo tulikuwa nazo hapo awali.
Tunayo fursa ya kutumia usanidi bora zaidi kwa mazingira ya Maendeleo, ambayo yatatofautiana na chaguo-msingi. MySQL imesanidiwa kwa mashine dhaifu kwa chaguo-msingi na utendakazi wake nje ya boksi ni duni sana.
Docker hukuruhusu kutumia Python, Ruby, NodeJS, mkalimani wa PHP wa toleo unalotaka. Tunaondoa hitaji la kutumia aina fulani ya meneja wa toleo. Hapo awali, Ruby alitumia kifurushi cha rpm ambacho kilikuruhusu kubadilisha toleo kulingana na mradi. Pia inaruhusu, shukrani kwa chombo cha Docker, kuhamisha msimbo vizuri na kuibadilisha pamoja na vitegemezi. Hatuna shida kuelewa toleo la mkalimani na msimbo. Ili kusasisha toleo, punguza kontena la zamani na uinue kontena mpya. Ikiwa kitu kimeenda vibaya, tunaweza kupunguza chombo kipya, kuinua chombo cha zamani.
Baada ya kujenga picha, vyombo katika Maendeleo na Uzalishaji vitakuwa sawa. Hii ni kweli hasa kwa mitambo mikubwa.
Kwenye Frontend tunatumia JavaScipt na NodeJS.
Sasa tuna mradi wa mwisho kwenye ReacJS. Msanidi programu aliendesha kila kitu kwenye kontena na kuendeleza kwa kutumia upakiaji upya wa moto.
Ifuatayo, kazi ya kusanyiko la JavaScipt inazinduliwa na msimbo uliokusanywa katika statics hutolewa kupitia rasilimali za kuokoa nginx.
Hapa nimetoa mpango wa mradi wetu wa mwisho.
Ni kazi gani zilitatuliwa? Tulikuwa na hitaji la kuunda mfumo ambao vifaa vya rununu vinaingiliana. Wanapokea data. Uwezekano mmoja ni kutuma arifa kwa kifaa hiki.
Je, tumefanya nini kwa hili?
Tuligawanya katika programu vipengele kama vile: sehemu ya msimamizi kwenye JS, mazingira ya nyuma, ambayo hufanya kazi kupitia kiolesura cha REST chini ya Ruby on Rails. Mazingira ya nyuma yanaingiliana na hifadhidata. Matokeo ambayo hutolewa hutolewa kwa mteja. Jopo la msimamizi huingiliana na mazingira ya nyuma na hifadhidata kupitia kiolesura cha REST.
Pia tulikuwa na haja ya kutuma arifa zinazotumwa na programu hata wakati huitumii. Kabla ya hapo, tulikuwa na mradi ambao ulitekeleza utaratibu ambao una jukumu la kuwasilisha arifa kwenye mifumo ya simu.
Tumeanzisha mpango ufuatao: opereta kutoka kwa kivinjari huingiliana na jopo la msimamizi, jopo la msimamizi linaingiliana na backend, kazi ni kutuma arifa za Push.
Arifa za programu huingiliana na sehemu nyingine ambayo inatekelezwa katika NodeJS.
Foleni hujengwa na kisha arifa hutumwa kulingana na utaratibu wao.
Hifadhidata mbili zimechorwa hapa. Kwa sasa, kwa msaada wa Docker, tunatumia hifadhidata 2 za kujitegemea ambazo hazihusiani kwa njia yoyote. Kwa kuongeza, wana mtandao wa kawaida wa kawaida, na data ya kimwili huhifadhiwa katika saraka tofauti kwenye mashine ya msanidi.
Sawa lakini kwa idadi. Hapa ndipo utumiaji wa msimbo ni muhimu.
Ikiwa hapo awali tulizungumza juu ya kutumia tena nambari katika mfumo wa maktaba, basi katika mfano huu, huduma yetu inayojibu arifa za Push inatumiwa tena kama seva kamili. Inatoa API. Na maendeleo yetu mapya tayari yanaingiliana nayo.
Wakati huo, tulikuwa tukitumia toleo la 4 la NodeJS. Sasa (mnamo 2017 - ed. note) katika maendeleo ya hivi karibuni tunatumia toleo la 7 la NodeJS. Hakuna tatizo katika vipengele vipya kuhusisha matoleo mapya ya maktaba.
Ikihitajika, unaweza kurekebisha na kuinua toleo la NodeJS kutoka kwa huduma ya arifa ya Push.
Na ikiwa tunaweza kudumisha utangamano wa API, basi itawezekana kuibadilisha na miradi mingine ambayo ilitumiwa hapo awali.
Unahitaji nini kuongeza Docker? Tunaongeza Dockerfile kwenye hazina yetu, ambayo inaelezea utegemezi muhimu. Katika mfano huu, vipengele vinavunjwa kimantiki. Hii ni seti ya chini kabisa ya msanidi programu.
Wakati wa kuunda mradi mpya, tunaunda Dockerfile, tunaelezea mfumo wa ikolojia unaohitajika (Python, Ruby, NodeJS). Katika docker-compose, inaelezea utegemezi muhimu - hifadhidata. Tunaelezea kwamba tunahitaji hifadhidata ya toleo kama hilo na kama hilo, kuhifadhi data huko na huko.
Tunatumia chombo cha tatu tofauti na nginx kutumikia tuli. Inawezekana kupakia picha. Backend inawaweka kwa kiasi kilichotayarishwa awali, ambacho pia kimewekwa kwenye chombo kilicho na nginx, ambacho hutoa tuli.
Ili kuhifadhi usanidi wa nginx, mysql, tuliongeza folda ya Docker ambayo tunahifadhi usanidi muhimu. Wakati msanidi programu anafanya git clone ya hazina kwenye mashine yake, tayari ana mradi tayari kwa maendeleo ya ndani. Hakuna swali ni bandari gani au mipangilio gani ya kuomba.
Ifuatayo, tuna vipengele kadhaa: admin, taarifa-API, arifa za kushinikiza.
Ili kuanza haya yote, tuliunda hazina nyingine, ambayo tuliiita dockerized-app. Kwa sasa tunatumia hazina kadhaa kabla ya kila sehemu. Ni tofauti kimantiki - katika GitLab inaonekana kama folda, lakini kwenye mashine ya msanidi programu, folda ya mradi maalum. Ngazi moja chini ni vipengele ambavyo vitaunganishwa.
Huu ni mfano wa yaliyomo tu ya programu-jalizi. Pia tunaleta saraka ya Docker hapa, ambayo tunajaza usanidi unaohitajika kwa mwingiliano wa vipengele vyote. Kuna README.md ambayo inaeleza kwa ufupi jinsi ya kuendesha mradi.
Hapa tumetumia faili mbili za kutunga docker. Hii inafanywa ili kuweza kukimbia kwa hatua. Wakati msanidi anafanya kazi na msingi, haitaji arifa za kushinikiza, anazindua tu faili ya kutunga docker na, ipasavyo, rasilimali imehifadhiwa.
Iwapo kuna haja ya kuunganishwa na arifa za kushinikiza, basi docker-compose.yaml na docker-compose-push.yaml huzinduliwa.
Kwa kuwa docker-compose.yaml na docker-compose-push.yaml ziko kwenye folda, mtandao mmoja pepe huundwa kiotomatiki.
Maelezo ya vipengele. Hii ni faili ya juu zaidi ambayo inawajibika kwa mkusanyiko wa vipengele. Ni nini cha kushangaza hapa? Hapa tunatanguliza sehemu ya kusawazisha.
Hii ni picha ya Docker iliyotengenezwa tayari ambayo inaendesha nginx na programu inayosikiza kwenye tundu la Docker. Inayobadilika, kwani kontena huwashwa na kuzimwa, hutengeneza upya usanidi wa nginx. Tunasambaza ushughulikiaji wa vipengele kwa majina ya kikoa cha ngazi ya tatu.
Kwa mazingira ya Maendeleo, tunatumia kikoa cha .dev - api.informer.dev. Programu zilizo na kikoa cha .dev zinapatikana kwenye mashine ya ndani ya msanidi programu.
Zaidi ya hayo, usanidi huhamishiwa kwa kila mradi na miradi yote inazinduliwa pamoja kwa wakati mmoja.
Kwa mchoro, inageuka kuwa mteja ni kivinjari chetu au chombo fulani ambacho tunatuma maombi kwa mizani.
Kisawazisha cha jina la kikoa huamua ni chombo gani cha kuwasiliana.
Inaweza kuwa nginx, ambayo inampa admin JS. Hii inaweza kuwa nginx, ambayo inatoa API, au faili tuli, ambazo hupewa nginx kwa njia ya upakiaji wa picha.
Mchoro unaonyesha kuwa vyombo vimeunganishwa na mtandao pepe na kufichwa nyuma ya proksi.
Kwenye mashine ya msanidi programu, unaweza kufikia chombo kujua IP, lakini kwa kanuni hatutumii hii. Kwa kweli hakuna haja ya ufikiaji wa moja kwa moja.
Ni mfano gani wa kuangalia ili kusawazisha programu yako? Kwa maoni yangu, mfano mzuri ni picha rasmi ya kizimbani kwa MySQL.
Ni changamoto kabisa. Kuna matoleo mengi. Lakini utendaji wake unakuwezesha kufidia mahitaji mengi ambayo yanaweza kutokea katika mchakato wa maendeleo zaidi. Ikiwa unatumia muda na kujua jinsi yote yanavyoingiliana, basi nadhani hutakuwa na matatizo katika utekelezaji wa kibinafsi.
Hub.docker.com kawaida huwa na viungo vya github.com, ambayo ina data mbichi moja kwa moja ambayo unaweza kuunda picha mwenyewe.
Zaidi katika hazina hii kuna hati ya docker-endpoint.sh, ambayo inawajibika kwa uanzishaji wa awali na kwa usindikaji zaidi wa uzinduzi wa programu.
Pia katika mfano huu, kuna uwezo wa kusanidi kwa kutumia vigezo vya mazingira. Kwa kufafanua utofauti wa mazingira wakati wa kuendesha kontena moja au kupitia docker-compose, tunaweza kusema kwamba tunahitaji kuweka nenosiri tupu kwa docker ili mizizi kwenye MySQL au chochote tunachotaka.
Kuna chaguo la kuunda nenosiri la nasibu. Tunasema kwamba tunahitaji mtumiaji, tunahitaji kuweka nenosiri kwa mtumiaji, na tunahitaji kuunda database.
Katika miradi yetu, tuliunganisha kidogo Dockerfile, ambayo ina jukumu la kuanzishwa. Hapo tuliisahihisha kulingana na mahitaji yetu ili kuifanya iwe nyongeza tu ya haki za mtumiaji ambazo programu hutumia. Hii ilituruhusu kuunda hifadhidata kutoka kwa dashibodi ya programu baadaye. Programu za Ruby zina amri ya kuunda, kurekebisha, na kufuta hifadhidata.
Huu ni mfano wa jinsi toleo maalum la MySQL linaonekana kwenye github.com. Unaweza kufungua Dockerfile na kuona jinsi usakinishaji unaendelea hapo.
docker-endpoint.sh ndio hati inayohusika na mahali pa kuingilia. Wakati wa uanzishaji wa uanzishaji, hatua zingine za utayarishaji zinahitajika, na vitendo hivi vyote vinachukuliwa katika hati ya uanzishaji.
Wacha tuendelee kwenye sehemu ya pili.
Ili kuhifadhi misimbo ya chanzo, tulibadilisha hadi gitlab. Huu ni mfumo wenye nguvu sana ambao una kiolesura cha kuona.
Moja ya vipengele vya Gitlab ni Gitlab CI. Inakuruhusu kuelezea mlolongo wa amri ambazo baadaye zitatumika kupanga mfumo wa uwasilishaji wa msimbo au kufanya majaribio ya kiotomatiki.
Gitlab CI 2 majadiliano - ripoti kutoka kwa kilabu cha Ruby Russia - ya kina kabisa na labda itakuvutia.
Sasa tutaangalia kile kinachohitajika ili kuwezesha Gitlab CI. Ili kuanzisha Gitlab CI, tunahitaji tu kuweka faili ya .gitlab-ci.yml kwenye mzizi wa mradi.
Hapa tunaelezea kuwa tunataka kutekeleza mlolongo wa majimbo kama jaribio, peleka.
Tunatekeleza hati ambazo huita moja kwa moja docker-compose ili kuunda programu yetu. Huu ni mfano wa nyuma tu.
Ifuatayo, tunasema kwamba ni muhimu kuendesha uhamiaji ili kubadilisha hifadhidata na kufanya majaribio.
Ikiwa maandiko yanatekelezwa kwa usahihi na hairudi msimbo wa hitilafu, basi mfumo unaendelea hadi hatua ya pili ya kupelekwa.
Hatua ya upelekaji kwa sasa inatekelezwa kwa jukwaa. Hatukupanga kuwasha tena kwa muda usiopungua sifuri.
Tunazima vyombo vyote kwa nguvu, na kisha tunainua vyombo vyote tena, vilivyokusanywa katika hatua ya kwanza wakati wa kupima.
Tunaendesha mabadiliko ya mazingira ya sasa ya uhamishaji wa hifadhidata ambao uliandikwa na wasanidi.
Kuna kumbuka kwamba hii inatumika tu kwa tawi kuu.
Wakati wa kubadilisha matawi mengine si kunyongwa.
Inawezekana kupanga ugawaji na matawi.
Ili kupanga hili zaidi, tunahitaji kusakinisha Gitlab Runner.
Huduma hii imeandikwa kwa Golang. Ni faili moja, kama ilivyo kawaida katika ulimwengu wa Golang, ambayo haihitaji utegemezi wowote.
Tunapoanzisha, tunasajili Mkimbiaji wa Gitlab.
Tunapata ufunguo kwenye kiolesura cha wavuti cha Gitlab.
Kisha tunaita amri ya uanzishaji kwenye mstari wa amri.
Sanidi Gitlab Runner kwa maingiliano (Shell, Docker, VirtualBox, SSH)
Nambari ya kuthibitisha kwenye Gitlab Runner itatekeleza kwa kila ahadi, kulingana na mpangilio wa .gitlab-ci.yml.
Jinsi inaonekana kuibua katika Gitlab kwenye kiolesura cha wavuti. Baada ya kuunganisha GItlab CI, tunayo bendera inayoonyesha hali ya muundo kwa sasa.
Tunaona kwamba ahadi ilifanywa dakika 4 zilizopita, ambayo ilipitisha vipimo vyote na haikusababisha matatizo yoyote.
Tunaweza kuangalia kwa karibu miundo. Hapa tunaona kwamba majimbo mawili tayari yamepita. Hali ya majaribio na hali ya kupelekwa kwenye jukwaa.
Ikiwa tutabofya kwenye ujenzi maalum, basi kutakuwa na matokeo ya console ya amri ambazo ziliendeshwa katika mchakato kulingana na .gitlab-ci.yml.
Hivi ndivyo historia ya bidhaa zetu inavyoonekana. Tunaona kwamba kulikuwa na majaribio ya mafanikio. Majaribio yanapowasilishwa, hayaendelei kwa hatua inayofuata na msimbo wa hatua haujasasishwa.
Je, ni kazi gani tulizotatua kwenye jukwaa tulipotekeleza docker? Mfumo wetu una vijenzi na tulikuwa na haja ya kuanzisha upya, ni sehemu tu ya vipengele ambavyo vilisasishwa kwenye hazina, na si mfumo mzima.
Ili kufanya hivyo, tulilazimika kuvunja kila kitu kwenye folda tofauti.
Baada ya kufanya hivi, tulikuwa na shida na ukweli kwamba Docker-compose inaunda nafasi yake ya mtandao kwa kila baba na haoni vifaa vya jirani.
Ili kuzunguka, tuliunda mtandao kwenye Docker kwa mikono. Iliandikwa kwa Docker-compose kwamba unatumia mtandao kama huu kwa mradi huu.
Kwa hivyo, kila sehemu inayoanza na mesh hii huona vipengee katika sehemu zingine za mfumo.
Suala linalofuata ni kugawanya hatua katika miradi mingi.
Kwa kuwa ili yote haya yaonekane nzuri na karibu iwezekanavyo kwa uzalishaji, ni vizuri kutumia bandari 80 au 443, ambayo hutumiwa kila mahali kwenye WEB.
Je, tulitatuaje? Tumekabidhi Gitlab Runner moja kwa miradi yote mikuu.
Gitlab hukuruhusu kuendesha Gitlab Runners kadhaa zilizosambazwa, ambazo zitachukua tu kazi zote kwa zamu kwa njia ya fujo na kuziendesha.
Ili tusiwe na nyumba, tulipunguza kikundi cha miradi yetu kwa Gitlab Runner moja, ambayo inashughulikia bila shida na juzuu zetu.
Tulihamisha proksi ya nginx kwenye hati tofauti ya kuanza na kuongeza gridi za miradi yote ndani yake.
Mradi wetu una gridi moja, na usawazishaji una gridi kadhaa kwa majina ya mradi. Inaweza kuwa wakala zaidi kwa majina ya kikoa.
Maombi yetu huja kupitia kikoa kilicho kwenye port 80 na hutatuliwa kuwa kikundi cha kontena kinachohudumia kikoa hiki.
Kulikuwa na matatizo gani mengine? Hivi ndivyo vyombo vyote huendesha kama mzizi kwa chaguo-msingi. Hii ni mzizi usio sawa na mwenyeji wa mizizi ya mfumo.
Hata hivyo, ukiingiza chombo, kitakuwa mzizi na faili tunayounda kwenye chombo hiki hupata haki za mizizi.
Ikiwa msanidi programu aliingia kwenye chombo na akafanya amri fulani huko zinazozalisha faili, kisha akaacha chombo, basi ana faili katika saraka yake ya kazi ambayo hawana upatikanaji.
Inaweza kutatuliwaje? Unaweza kuongeza watumiaji ambao watakuwa kwenye kontena.
Ni matatizo gani yalitokea tulipoongeza mtumiaji?
Wakati wa kuunda mtumiaji, mara nyingi hatuna kitambulisho cha kikundi sawa (UID) na kitambulisho cha mtumiaji (GID).
Ili kutatua tatizo hili kwenye kontena, tunatumia watumiaji wenye ID 1000.
Kwa upande wetu, hii iliambatana na ukweli kwamba karibu watengenezaji wote hutumia Ubuntu OS. Na kwa Ubuntu, mtumiaji wa kwanza ana kitambulisho cha 1000.
Je, tuna mipango?
Soma hati za Docker. Mradi unaendelea kikamilifu, nyaraka zinabadilika. Data ambayo ilipokelewa miezi miwili au mitatu iliyopita tayari inapitwa na wakati.
Baadhi ya shida ambazo tulitatua inawezekana tayari zimetatuliwa kwa njia za kawaida.
Kwa hivyo nataka kwenda mbele zaidi tayari kwenda moja kwa moja kwenye okestra.
Mfano mmoja ni utaratibu wa ndani wa Docker unaoitwa Docker Swarm, ambao hutoka kwenye boksi. Ninataka kuendesha kitu katika uzalishaji kulingana na teknolojia ya Docker Swarm.
Vyombo vya kuzaa hufanya iwe vigumu kufanya kazi na magogo. Sasa magogo yametengwa. Wametawanyika kwenye vyombo. Moja ya kazi ni kufanya ufikiaji rahisi wa kumbukumbu kupitia kiolesura cha wavuti.
Chanzo: mapenzi.com