Kubernetes ni zana nzuri ya kuendesha vyombo vya Docker katika mazingira ya uzalishaji yaliyounganishwa. Hata hivyo, kuna matatizo ambayo Kubernetes hawezi kutatua. Kwa usambazaji wa mara kwa mara wa uzalishaji, tunahitaji utumaji otomatiki wa Bluu/Kijani ili kuepuka muda wa kupungua katika mchakato, ambao unahitaji pia kushughulikia maombi ya nje ya HTTP na kutekeleza upakuaji wa SSL. Hili linahitaji kuunganishwa na kikisawazisha mzigo kama vile ha-proksi. Changamoto nyingine ni kuongeza nusu kiotomatiki kwa nguzo ya Kubernetes yenyewe wakati wa kukimbia katika mazingira ya wingu, kwa mfano kupunguza sehemu ndogo wakati wa usiku.
Ingawa Kubernetes haina vipengele hivi nje ya boksi, inatoa API ambayo unaweza kutumia kutatua matatizo sawa. Zana za uwekaji otomatiki wa Bluu/Kijani na upanuzi wa nguzo ya Kubernetes ziliundwa kama sehemu ya mradi wa Cloud RTI, ambao uliundwa kwa msingi wa chanzo huria.
Nakala hii, nakala ya video, inakuonyesha jinsi ya kusanidi Kubernetes pamoja na vipengee vingine vya chanzo huria ili kuunda mazingira tayari ya uzalishaji ambayo yanakubali msimbo kutoka kwa ahadi ya git bila kupunguzwa kwa uzalishaji.
Kwa hivyo, ukishapata ufikiaji wa programu zako kutoka kwa ulimwengu wa nje, unaweza kuanza kusanidi otomatiki kikamilifu, ambayo ni, kuileta kwenye hatua ambayo unaweza kutekeleza ahadi ya git na uhakikishe kuwa ahadi hii ya git inaisha katika uzalishaji. Kwa kawaida, wakati wa kutekeleza hatua hizi, wakati wa kutekeleza kupelekwa, hatutaki kukutana na wakati wa kupungua. Kwa hivyo, otomatiki yoyote katika Kubernetes huanza na API.
Kubernetes si zana ambayo inaweza kutumika kwa tija nje ya boksi. Bila shaka, unaweza kufanya hivyo, kutumia kubectl na kadhalika, lakini bado API ndilo jambo la kuvutia na muhimu zaidi kuhusu jukwaa hili. Kwa kutumia API kama seti ya vitendakazi, unaweza kufikia karibu chochote unachotaka kufanya katika Kubernetes. kubectl yenyewe pia hutumia REST API.
Hii ni REST, kwa hivyo unaweza kutumia lugha au zana yoyote kufanya kazi na API hii, lakini maisha yako yatarahisishwa zaidi na maktaba maalum. Timu yangu iliandika maktaba 2 kama hizo: moja ya Java/OSGi na moja ya Go. Ya pili haitumiwi mara nyingi, lakini kwa hali yoyote unayo vitu hivi muhimu. Wao ni mradi wa chanzo huria ulioidhinishwa kwa kiasi. Kuna maktaba nyingi kama hizi za lugha tofauti, kwa hivyo unaweza kuchagua zile zinazokufaa zaidi.
Kwa hivyo, kabla ya kuanza kusambaza uwekaji wako kiotomatiki, unahitaji kuhakikisha kuwa mchakato hautakabiliwa na wakati wowote wa kupumzika. Kwa mfano, timu yetu hutuma usambazaji wa umma katikati ya siku wakati watu wanatumia programu kwa wingi wao, kwa hivyo ni muhimu kuepuka kucheleweshwa kwa mchakato huu. Ili kuzuia wakati wa kupungua, njia 2 hutumiwa: uwekaji wa bluu/kijani au sasisho la kukunja. Katika kesi ya mwisho, ikiwa una nakala 5 za programu inayoendesha, zinasasishwa mfululizo moja baada ya nyingine. Njia hii inafanya kazi vizuri, lakini haifai ikiwa una matoleo tofauti ya programu inayoendesha wakati huo huo wakati wa mchakato wa kupeleka. Katika kesi hii, unaweza kusasisha kiolesura cha mtumiaji wakati sehemu ya nyuma inaendesha toleo la zamani, na programu itaacha kufanya kazi. Kwa hivyo, kutoka kwa mtazamo wa programu, kufanya kazi katika hali kama hizi ni ngumu sana.
Hii ni mojawapo ya sababu kwa nini tunapendelea kutumia matumizi ya rangi ya samawati/kijani ili kuelekeza utumaji wa programu zetu kiotomatiki. Kwa njia hii, lazima uhakikishe kuwa toleo moja tu la programu linatumika kwa wakati mmoja.
Utaratibu wa kupeleka bluu/kijani unaonekana kama hii. Tunapokea trafiki ya maombi yetu kupitia ha-proksi, ambayo huisambaza kwa kutumia nakala za utumizi wa toleo sawa.
Wakati uwekaji mpya unafanywa, tunatumia Deployer, ambayo hupewa vipengele vipya na kusambaza toleo jipya. Kutuma toleo jipya la programu inamaanisha kuwa seti mpya ya nakala "imeinuliwa", baada ya hapo nakala hizi za toleo jipya zinazinduliwa kwa njia tofauti, mpya. Hata hivyo, ha-proksi hajui chochote kuwahusu na haielekezi mzigo wowote wa kazi kwao bado.
Kwa hivyo, kwanza kabisa, inahitajika kufanya ukaguzi wa utendaji wa matoleo mapya ya ukaguzi wa afya ili kuhakikisha kuwa nakala ziko tayari kuhudumia mzigo.
Vipengele vyote vya uwekaji lazima visaidie aina fulani ya ukaguzi wa afya. Hii inaweza kuwa ukaguzi rahisi sana wa simu wa HTTP, unapopokea nambari iliyo na hali ya 200, au ukaguzi wa kina zaidi, ambao unaangalia muunganisho wa nakala na hifadhidata na huduma zingine, uthabiti wa miunganisho ya mazingira yenye nguvu. , na ikiwa kila kitu kinaanza na kufanya kazi kwa usahihi. Utaratibu huu unaweza kuwa ngumu sana.
Baada ya mfumo kuthibitisha kuwa nakala zote zilizosasishwa zinafanya kazi, Deployer itasasisha usanidi na kupitisha confd sahihi, ambayo itaweka upya ha-proksi.
Tu baada ya hii trafiki itaelekezwa kwenye ganda na nakala za toleo jipya, na ganda la zamani litatoweka.
Utaratibu huu sio kipengele cha Kubernetes. Wazo la uwekaji wa Bluu/kijani limekuwepo kwa muda mrefu sana na daima limetumia kibawazishaji cha mizigo. Kwanza, unaelekeza trafiki yote kwa toleo la zamani la programu, na baada ya sasisho, unaihamisha kabisa kwa toleo jipya. Kanuni hii haitumiki tu katika Kubernetes.
Sasa nitakujulisha kwa sehemu mpya ya kupeleka - Deployer, ambayo hufanya ukaguzi wa afya, kurekebisha tena wawakilishi, na kadhalika. Hili ni wazo ambalo halitumiki kwa ulimwengu wa nje na lipo ndani ya Kubernetes. Nitakuonyesha jinsi unavyoweza kuunda dhana yako ya Kisambazaji kwa kutumia zana huria.
Kwa hivyo, jambo la kwanza Deployer hufanya ni kuunda kidhibiti cha urudufishaji cha RC kwa kutumia Kubernetes API. API hii huunda maganda na huduma kwa ajili ya kupelekwa zaidi, yaani, inaunda kundi jipya kabisa la programu zetu. Mara tu RC atakaposhawishika kuwa nakala zimeanza, itafanya ukaguzi wa Afya juu ya utendakazi wao. Ili kufanya hivyo, Deployer hutumia amri ya GET / afya. Huendesha vipengee vinavyofaa vya kuchanganua na hukagua vipengee vyote vinavyounga mkono utendakazi wa nguzo.
Baada ya ganda zote kuripoti afya zao, Deployer huunda kipengee kipya cha usanidi - nkd hifadhi iliyosambazwa, ambayo inatumiwa ndani na Kubernetes, ikiwa ni pamoja na kuhifadhi usanidi wa kusawazisha mzigo. Tunaandika data kwa etcd, na zana ndogo inayoitwa confd monitors etcd kwa data mpya.
Ikitambua mabadiliko yoyote kwenye usanidi wa awali, hutengeneza faili mpya ya mipangilio na kuihamisha kwa ha-proksi. Katika hali hii, ha-proxy huwasha upya bila kupoteza miunganisho yoyote na kushughulikia mzigo kwenye huduma mpya zinazowezesha toleo jipya la programu zetu kufanya kazi.
Kama unaweza kuona, licha ya wingi wa vipengele, hakuna chochote ngumu hapa. Unahitaji tu kulipa kipaumbele zaidi kwa API na etcd. Ninataka kukuambia kuhusu kisambaza programu-wazi ambacho sisi wenyewe tunatumia - Amdatu Kubernetes Deployer.
Ni zana ya kupanga upelekaji wa Kubernetes na ina sifa zifuatazo:
- Usambazaji wa Bluu / Kijani;
- kuanzisha usawa wa mzigo wa nje;
- usimamizi wa maelezo ya upelekaji;
- kusimamia upelekaji halisi;
- kuangalia utendaji wa ukaguzi wa Afya wakati wa kupeleka;
- utekelezaji wa vigezo vya mazingira katika maganda.
Kitumiaji hiki kimeundwa juu ya API ya Kubernetes na hutoa API ya REST ya kudhibiti vipini na uwekaji, pamoja na API ya Websocket ya kutiririsha kumbukumbu wakati wa mchakato wa kusambaza.
Huweka data ya usanidi wa kisawazisha cha mzigo kwenye etcd, kwa hivyo huhitaji kutumia ha-proksi yenye usaidizi wa nje ya kisanduku, lakini tumia kwa urahisi faili yako ya usanidi ya kikisawazisha mzigo. Amdatu Deployer imeandikwa katika Go, kama Kubernetes yenyewe, na imepewa leseni na Apache.
Kabla sijaanza kutumia toleo hili la kisambazaji, nilitumia maelezo yafuatayo ya upelekaji, ambayo yanabainisha vigezo ninavyohitaji.
Moja ya vigezo muhimu vya msimbo huu ni kuwezesha alama ya "useHealthCheck". Tunahitaji kubainisha kwamba ukaguzi wa usafi lazima ufanyike wakati wa mchakato wa kupeleka. Mpangilio huu unaweza kuzimwa wakati utumaji unatumia vyombo vya watu wengine ambavyo havihitaji kuthibitishwa. Kifafanuzi hiki pia kinaonyesha idadi ya nakala na URL ya mazingira ya mbele ambayo proksi ya ha inahitaji. Mwishoni kuna bendera ya maelezo ya ganda "podspec", ambayo huita Kubernetes kwa habari juu ya usanidi wa bandari, picha, nk. Hii ni maelezo rahisi ya JSON.
Chombo kingine ambacho ni sehemu ya mradi wa chanzo huria wa Amdatu ni Deploymentctl. Ina UI ya kusanidi uwekaji, historia ya utumiaji wa duka, na ina viboreshaji vya wavuti vya kupigiwa simu kutoka kwa watumiaji na wasanidi programu wengine. Huenda usitumie UI kwa kuwa Amdatu Deployer yenyewe ni REST API, lakini kiolesura hiki kinaweza kufanya utumaji kuwa rahisi kwako bila kuhusisha API yoyote. Deploymentctl imeandikwa katika OSGi/Vertx kwa kutumia Angular 2.
Sasa nitaonyesha yaliyo hapo juu kwenye skrini kwa kutumia rekodi iliyorekodiwa mapema ili usisubiri. Tutakuwa tukipeleka programu rahisi ya Go. Usijali ikiwa haujajaribu Nenda hapo awali, ni programu rahisi sana kwa hivyo unapaswa kuweza kuibaini.
Hapa tunaunda seva ya HTTP ambayo hujibu /afya pekee, kwa hivyo programu tumizi hii hujaribu tu ukaguzi wa afya na sio kitu kingine chochote. Ikiwa hundi itapita, muundo wa JSON ulioonyeshwa hapa chini hutumiwa. Ina toleo la programu ambalo litatumwa na kisambazaji, ujumbe unaouona juu ya faili, na aina ya data ya boolean - iwe programu yetu inafanya kazi au la.
Nilidanganya kidogo na mstari wa mwisho, kwa sababu niliweka thamani ya boolean iliyowekwa juu ya faili, ambayo katika siku zijazo itanisaidia kupeleka hata programu "isiyo ya afya". Tutashughulikia hili baadaye.
Basi hebu tuanze. Kwanza, tunaangalia uwepo wa maganda yoyote yanayoendeshwa kwa kutumia amri ~ kubectl pata maganda na, kulingana na kukosekana kwa jibu kutoka kwa URL ya sehemu ya mbele, tunahakikisha kuwa hakuna utumaji unaofanywa kwa sasa.
Inayofuata kwenye skrini unaona kiolesura cha Deploymentctl nilichotaja, ambamo vigezo vya upelekaji vimewekwa: nafasi ya jina, jina la programu, toleo la kupeleka, idadi ya nakala, URL ya mwisho wa mbele, jina la chombo, picha, mipaka ya rasilimali, nambari ya bandari kwa ukaguzi wa afya, nk. Mipaka ya rasilimali ni muhimu sana, kwani inakuwezesha kutumia kiwango cha juu cha vifaa vinavyowezekana. Hapa unaweza pia kutazama logi ya Usambazaji.
Ikiwa sasa unarudia amri ~ kubectl pata maganda, unaweza kuona kwamba mfumo "hugandisha" kwa sekunde 20, wakati ambapo ha-proksi inawekwa upya. Baada ya hayo, ganda huanza, na replica yetu inaweza kuonekana kwenye logi ya kupeleka.
Nilikata kusubiri kwa sekunde 20 kutoka kwa video, na sasa unaweza kuona kwenye skrini kwamba toleo la kwanza la programu limetumwa. Haya yote yalifanywa kwa kutumia UI pekee.
Sasa hebu tujaribu toleo la pili. Ili kufanya hivyo, ninabadilisha ujumbe wa programu kutoka "Hello, Kubernetes!" kwenye "Hello, Deployer!", Mfumo huunda picha hii na kuiweka kwenye Usajili wa Docker, baada ya hapo tunabofya kitufe cha "Weka" tena kwenye dirisha la Deploymentctl. Katika kesi hii, logi ya uwekaji inazinduliwa kiatomati kwa njia ile ile kama ilivyotokea wakati wa kusambaza toleo la kwanza la programu.
Amri ya ~ kubectl get pods inaonyesha kuwa kwa sasa kuna matoleo 2 ya programu yanayoendeshwa, lakini sehemu ya mbele inaonyesha kuwa bado tunaendesha toleo la 1.
Kisawazisha mzigo husubiri ukaguzi wa afya ukamilike kabla ya kuelekeza trafiki kwenye toleo jipya. Baada ya sekunde 20, tunabadilisha kwa curl na kuona kwamba sasa tuna toleo la 2 la programu iliyotumiwa, na ya kwanza imefutwa.
Hii ilikuwa ni kupelekwa kwa maombi ya "afya". Hebu tuone kitakachotokea ikiwa kwa toleo jipya la programu nitabadilisha kigezo cha Healthy kutoka kweli hadi uongo, yaani, nitajaribu kupeleka programu isiyofaa ambayo imeshindwa ukaguzi wa afya. Hili linaweza kutokea ikiwa baadhi ya hitilafu za usanidi zilifanywa katika programu katika hatua ya usanidi, na ikatumwa katika toleo la umma katika fomu hii.
Kama unavyoona, upelekaji hupitia hatua zote hapo juu na ~kubectl pata maganda inaonyesha kuwa maganda yote mawili yanafanya kazi. Lakini tofauti na uwekaji uliopita, logi inaonyesha hali ya kuisha. Hiyo ni, kutokana na ukweli kwamba hundi ya afya imeshindwa, toleo jipya la programu haiwezi kupelekwa. Kwa hivyo, unaona kwamba mfumo umerejea kwa kutumia toleo la zamani la programu, na toleo jipya limeondolewa tu.
Jambo zuri juu ya hili ni kwamba hata ikiwa una idadi kubwa ya maombi ya wakati mmoja inayokuja kwenye programu, hawatagundua hata wakati wa kutekeleza utaratibu wa kupeleka. Ukijaribu programu hii kwa kutumia mfumo wa Gatling, ambao hutuma maombi mengi iwezekanavyo, basi hakuna maombi haya yatakayotupwa. Hii inamaanisha kuwa watumiaji wetu hata hawataona masasisho ya toleo kwa wakati halisi. Ikishindikana, kazi itaendelea kwenye toleo la zamani; ikiwa itafaulu, watumiaji watabadilisha hadi toleo jipya.
Kuna jambo moja tu ambalo linaweza kushindwa - ikiwa hundi ya afya inafanikiwa, lakini maombi inashindwa mara tu mzigo wa kazi unatumiwa kwa hiyo, yaani, kuanguka kutatokea tu baada ya kukamilika kukamilika. Katika kesi hii, utalazimika kurudi kwa toleo la zamani. Kwa hivyo, tuliangalia jinsi ya kutumia Kubernetes na zana huria zilizoundwa kwa ajili yake. Mchakato wa kusambaza utakuwa rahisi zaidi ikiwa utaunda zana hizi kwenye mabomba yako ya Kujenga/Kusambaza. Wakati huo huo, ili kuanza kupeleka, unaweza kutumia kiolesura cha mtumiaji au kugeuza mchakato huu kikamilifu kwa kutumia, kwa mfano, kujitolea kwa bwana.
Seva yetu ya Muundo itaunda picha ya Docker, kuisukuma kwenye Docker Hub au usajili wowote utakaotumia. Docker Hub inasaidia webhook, ili tuweze kuanzisha utumiaji wa mbali kupitia Deployer kwa njia iliyoonyeshwa hapo juu. Kwa njia hii unaweza kuelekeza kikamilifu utumaji wa programu yako kwa uwezo wa uzalishaji.
Wacha tuendelee kwenye mada inayofuata - kuongeza nguzo ya Kubernetes. Kumbuka kuwa amri ya kubectl ni amri ya kuongeza kiwango. Kwa usaidizi zaidi, tunaweza kuongeza kwa urahisi idadi ya nakala katika nguzo yetu iliyopo. Walakini, katika mazoezi, kwa kawaida tunataka kuongeza idadi ya nodi badala ya maganda.
Wakati huo huo, wakati wa saa za kazi unaweza kuhitaji kuongezeka, na usiku, ili kupunguza gharama za huduma za Amazon, unaweza kuhitaji kupunguza idadi ya matukio ya maombi ya kukimbia. Hii haimaanishi kuwa kuongeza idadi tu ya maganda itatosha, kwa sababu hata ikiwa nodi moja haifanyi kazi, bado utalazimika kulipa Amazon kwa hiyo. Hiyo ni, pamoja na kuongeza maganda, utahitaji kuongeza idadi ya mashine zinazotumiwa.
Hii inaweza kuwa changamoto kwa sababu ikiwa tunatumia Amazon au huduma nyingine ya wingu, Kubernetes hajui chochote kuhusu idadi ya mashine zinazotumiwa. Haina chombo kinachokuwezesha kuongeza mfumo kwenye kiwango cha nodi.
Kwa hivyo tutalazimika kutunza nodi zote mbili na maganda. Tunaweza kuongeza kasi ya uzinduzi wa nodi mpya kwa urahisi kwa kutumia API ya AWS na mashine za kikundi cha Scaling ili kusanidi idadi ya nodi za wafanyikazi wa Kubernetes. Unaweza pia kutumia cloud-init au hati sawa kusajili nodi katika nguzo ya Kubernetes.
Mashine mpya huanza katika kikundi cha Kuongeza, hujianzisha yenyewe kama nodi, kujiandikisha kwenye usajili wa bwana na kuanza kufanya kazi. Baada ya hayo, unaweza kuongeza idadi ya nakala za matumizi kwenye nodi zinazosababisha. Kupunguza chini kunahitaji juhudi zaidi, kwani unahitaji kuhakikisha kuwa hatua kama hiyo haisababishi uharibifu wa programu zinazoendesha tayari baada ya kuzima mashine "zisizo za lazima". Ili kuzuia hali hiyo, unahitaji kuweka nodes kwa hali "isiyopangwa". Hii inamaanisha kuwa kipanga ratiba chaguo-msingi kitapuuza nodi hizi wakati wa kuratibu maganda ya DaemonSet. Kipanga ratiba hakitafuta chochote kutoka kwa seva hizi, lakini pia hakitazindua kontena mpya hapo. Hatua inayofuata ni kuondokana na node ya kukimbia, yaani, kuhamisha pods zinazoendesha kutoka kwa mashine nyingine, au nodes nyingine ambazo zina uwezo wa kutosha kwa hili. Ukishahakikisha kuwa hakuna tena kontena kwenye nodi hizi, unaweza kuziondoa kutoka Kubernetes. Baada ya hayo, watakoma tu kuwepo kwa Kubernetes. Ifuatayo, unahitaji kutumia API ya AWS kuzima nodi au mashine zisizo za lazima.
Unaweza kutumia Amdatu Scalard, zana nyingine ya kuongeza chanzo-wazi sawa na API ya AWS. Inatoa CLI kuongeza au kuondoa nodi kwenye nguzo. Kipengele chake cha kufurahisha ni uwezo wa kusanidi kipanga ratiba kwa kutumia faili ifuatayo ya json.
Msimbo ulioonyeshwa hupunguza uwezo wa nguzo kwa nusu wakati wa muda wa usiku. Inasanidi idadi ya nakala zinazopatikana na uwezo unaohitajika wa nguzo ya Amazon. Kutumia kiratibu hiki kutapunguza kiotomatiki idadi ya nodi wakati wa usiku na kuziongeza asubuhi, hivyo basi kuokoa gharama ya kutumia nodi kutoka kwa huduma ya wingu kama vile Amazon. Kipengele hiki hakijajengwa ndani ya Kubernetes, lakini kutumia Scalard kutakuruhusu kuongeza jukwaa hili jinsi unavyotaka.
Ningependa kusema kwamba watu wengi huniambia, "Hayo ni sawa na nzuri, lakini vipi kuhusu hifadhidata yangu, ambayo kwa kawaida ni tuli?" Unawezaje kuendesha kitu kama hiki katika mazingira yenye nguvu kama Kubernetes? Kwa maoni yangu, haupaswi kufanya hivi, haupaswi kujaribu kuendesha ghala la data huko Kubernetes. Hili linawezekana kitaalam, na kuna mafunzo kwenye Mtandao juu ya mada hii, lakini itachanganya sana maisha yako.
Ndiyo, kuna dhana ya maduka yanayoendelea huko Kubernetes, na unaweza kujaribu kuendesha maduka ya data kama Mongo au MySQL, lakini hii ni kazi kubwa sana. Hii ni kutokana na ukweli kwamba ghala za data haziunga mkono kikamilifu mwingiliano na mazingira yenye nguvu. Hifadhidata nyingi zinahitaji usanidi muhimu, pamoja na usanidi wa mwongozo wa nguzo, haipendi kuongeza otomatiki na vitu vingine sawa.
Kwa hivyo, hupaswi kuyatatiza maisha yako kwa kujaribu kuendesha ghala la data huko Kubernetes. Panga kazi zao kwa njia ya kitamaduni kwa kutumia huduma zinazofahamika na uwape Kubernetes uwezo wa kuzitumia.
Ili kuhitimisha mada, ningependa kukujulisha kwa jukwaa la Cloud RTI kulingana na Kubernetes, ambalo timu yangu inafanyia kazi. Inatoa ukataji miti wa kati, ufuatiliaji wa matumizi na nguzo, na vipengele vingine vingi muhimu ambavyo vitakuja kwa manufaa. Inatumia zana mbalimbali za chanzo huria kama vile Grafana ili kuonyesha ufuatiliaji.
Kulikuwa na swali kuhusu kwa nini utumie kisawazisha cha kupakia ha-proxy na Kubernetes. Swali zuri kwa sababu kwa sasa kuna viwango 2 vya kusawazisha mzigo. Huduma za Kubernetes bado ziko kwenye anwani pepe za IP. Huwezi kuzitumia kwa bandari kwenye mashine za mwenyeji wa nje kwa sababu Amazon ikipakia upangishaji wake wa wingu kupita kiasi, anwani itabadilika. Hii ndiyo sababu tunaweka ha-proksi mbele ya huduma - ili kuunda muundo tuli zaidi wa trafiki kuwasiliana bila mshono na Kubernetes.
Swali lingine nzuri ni jinsi gani unaweza kutunza mabadiliko ya schema ya hifadhidata wakati wa kupeleka bluu/kijani? Ukweli ni kwamba bila kujali matumizi ya Kubernetes, kubadilisha schema ya database ni kazi ngumu. Unahitaji kuhakikisha kuwa schema ya zamani na mpya inaendana, baada ya hapo unaweza kusasisha hifadhidata na kisha kusasisha programu zenyewe. Unaweza kubadilisha hifadhidata kwa moto na kisha kusasisha programu. Ninajua watu ambao wameanzisha nguzo mpya kabisa ya hifadhidata na schema mpya, hili ni chaguo ikiwa una hifadhidata isiyo na mpango kama Mongo, lakini sio kazi rahisi hata hivyo. Ikiwa huna maswali zaidi, asante kwa umakini wako!
Baadhi ya matangazo π
Asante kwa kukaa nasi. Je, unapenda makala zetu? Je, ungependa kuona maudhui ya kuvutia zaidi? Tuunge mkono kwa kuweka agizo au kupendekeza kwa marafiki, , analogi ya kipekee ya seva za kiwango cha kuingia, ambayo ilivumbuliwa na sisi kwa ajili yako: (inapatikana kwa RAID1 na RAID10, hadi cores 24 na hadi 40GB DDR4).
Dell R730xd 2x nafuu katika kituo cha data cha Equinix Tier IV huko Amsterdam? Hapa tu nchini Uholanzi! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - kutoka $99! Soma kuhusu
Chanzo: mapenzi.com