Tulitengeneza DevOps kadri tulivyoweza. Kulikuwa na 8 kati yetu, na Vasya alikuwa baridi zaidi kwenye Windows. Ghafla, Vasya aliondoka, na nilikuwa na kazi ya kuzindua mradi mpya unaotolewa na maendeleo ya Windows. Nilipomimina safu nzima ya ukuzaji wa Windows kwenye meza, niligundua kuwa hali hiyo ni chungu ...
Hivi ndivyo hadithi inavyoanza Alexandra Sinchinova juu ya . Wakati mtaalamu mkuu wa Windows alipoondoka kwenye kampuni, Alexander alijiuliza nini cha kufanya sasa. Badili hadi Linux, bila shaka! Alexander atasema jinsi aliweza kuunda kielelezo na kuhamisha sehemu ya ukuzaji wa Windows kwa Linux kwa kutumia mfano wa mradi uliotekelezwa kwa watumiaji 100 wa mwisho.
Jinsi ya kutoa mradi kwa urahisi kwa RPM kwa kutumia msingi wa TFS, Puppet, Linux .NET? Jinsi ya kudumisha toleo la hifadhidata ya mradi ikiwa ukuzaji husikia maneno Postgres na Flyway kwa mara ya kwanza, na tarehe ya mwisho ni siku inayofuata kesho? Jinsi ya kuunganishwa na Docker? Jinsi ya kuwahamasisha watengenezaji wa NET kuondoka kutoka kwa Windows na laini ili kupendelea Puppet na Linux? Jinsi ya kutatua migogoro ya kiitikadi ikiwa hakuna nguvu, hakuna tamaa, hakuna rasilimali za kutumikia Windows katika uzalishaji? Kuhusu hili, na pia kuhusu Usambazaji wa Mtandao, upimaji, CI, kuhusu mazoea ya kutumia TFS katika miradi iliyopo, na, bila shaka, kuhusu magongo yaliyovunjika na ufumbuzi wa kazi, katika nakala ya ripoti ya Alexander.
Kwa hiyo, Vasya aliondoka, kazi ni juu yangu, watengenezaji wanasubiri kwa uvumilivu na pitchforks. Nilipogundua hatimaye kwamba Vasya hangeweza kurudishwa, nilianza biashara. Kuanza, nilikadiria asilimia ya Win VM kwenye meli yetu. Alama haikuwa ikipendelea Windows.
Kwa kuwa tunatengeneza DevOps kikamilifu, niligundua kuwa kuna kitu kinahitaji kubadilishwa katika mbinu ya kuchukua programu mpya. Kulikuwa na suluhisho moja tu - ikiwezekana, uhamishe kila kitu kwa Linux. Google ilinisaidia - wakati huo .Net ilikuwa tayari imetumwa kwa Linux, na nikagundua kuwa hili lilikuwa suluhisho!
Kwa nini .NET core kwa kushirikiana na Linux?
Kulikuwa na sababu kadhaa za hii. Kati ya "kulipa pesa" na "kutolipa", wengi watachagua mwisho - kama mimi. Leseni ya MSDB inagharimu takriban $1, na matengenezo ya kundi la mashine pepe za Windows hufikia mamia ya dola. Kwa kampuni kubwa, hii ni gharama kubwa. Ndiyo maana kuokoa - sababu ya kwanza. Sio muhimu zaidi, lakini moja ya muhimu zaidi.
Mashine halisi za Windows huchukua rasilimali zaidi kuliko ndugu zao wa Linux - ni wazito. Kwa kuzingatia ukubwa wa kampuni kubwa, tulichagua Linux.
Mfumo umeunganishwa kwa urahisi katika CI iliyopo. Tunajiona kuwa DevOps zinazoendelea, tunatumia Bamboo, Jenkins na GitLab CI, kwa hivyo wengi wetu tuko kwenye Linux.
Sababu ya mwisho ni kusindikiza kwa urahisi. Tulihitaji kupunguza kizingiti cha kuingia kwa "watunzaji" - watu wanaoelewa sehemu ya kiufundi, kuhakikisha mwendelezo na kutoa huduma kutoka kwa safu ya pili. Tayari walikuwa wanafahamu mrundikano wa Linux, kwa hiyo ni rahisi zaidi kwao kuelewa bidhaa mpya, kuunga mkono na kuidumisha, badala ya kutumia rasilimali za ziada ili kukabiliana na utendaji sawa wa programu kwa jukwaa la Windows.
Mahitaji
Kwanza kabisa - urahisi wa suluhisho mpya kwa watengenezaji. Sio wote walikuwa tayari kwa mabadiliko, haswa baada ya neno lililosemwa Linux. Watengenezaji wanataka Studio wanayoipenda ya Visual, TFS iliyo na majaribio ya kiotomatiki na laini. Jinsi utoaji kwa uzalishaji unafanyika sio muhimu kwao. Kwa hiyo, tuliamua kutobadilisha mchakato wa kawaida na kuacha kila kitu bila kubadilika kwa maendeleo ya Windows.
Unahitaji mradi mpya kupachika kwenye CI iliyopo. Reli zilikuwa tayari na kazi yote ilipaswa kufanywa kwa kuzingatia vigezo vya mfumo wa usimamizi wa usanidi, viwango vinavyokubalika vya utoaji na mifumo ya ufuatiliaji.
Urahisi wa matengenezo na uendeshaji, kama sharti la kiwango cha chini zaidi cha kuingia kwa washiriki wote wapya kutoka idara tofauti na idara ya usaidizi.
Tarehe ya mwisho - jana.
Kushinda timu ya maendeleo
Timu ya Windows ilikuwa ikifanya nini wakati huo?
Sasa naweza kusema hivyo kwa ujasiri IdentityServer4 ni mbadala nzuri ya bure kwa ADFS iliyo na huduma sawa, au chochote Msingi wa Mfumo wa Taasisi - paradiso kwa msanidi programu, ambapo huwezi kujisumbua kuandika maandishi ya SQL, lakini kuelezea maswali katika hifadhidata kwa suala la OOP. Lakini basi, wakati wa kujadili mpango wa utekelezaji, nilitazama safu hii kama kikabari cha Sumeri, nikitambua PostgreSQL na Git pekee.
Wakati huo, tulitumia kikamilifu Bomba kama mfumo wa usimamizi wa usanidi. Katika miradi yetu mingi tumetumia GitLab CI, Elastic, kusawazisha huduma zilizopakiwa sana kwa kutumia HAProksi, alifuatilia kila kitu Zabbix, vifurushi grafana ΠΈ Prometheus, Jaeger, na haya yote yalikuwa yanazunguka kwenye vipande vya chuma HP c ESXi juu ya VMware. Kila mtu anajua - classic ya Ghana.
Hebu tuangalie na tujaribu kuelewa ni nini kilifanyika kabla hatujaanza afua hizi zote.
Nini kimetokea
TFS ni mfumo wenye nguvu ambao sio tu hutoa msimbo kutoka kwa msanidi programu hadi kwa mashine ya mwisho ya uzalishaji, lakini pia ina seti ya ujumuishaji rahisi sana na huduma anuwai - kutoa CI katika kiwango cha jukwaa-msingi.
Hapo awali, haya yalikuwa matundu madhubuti. TFS ilitumia Wakala kadhaa wa Ujenzi waliojenga miradi mingi. Kila wakala ana wafanyikazi 3-4 ili kusawazisha kazi na kuboresha mchakato. Zaidi ya hayo, kulingana na mipango ya kutolewa, TFS iliwasilisha Muundo mpya uliooka kwenye seva ya programu ya Windows.
Tulitaka kwenda wapi
Tunatumia TFS kwa uwasilishaji na usanidi, na tunaendesha programu kwenye seva ya Maombi ya Linux, na kuna uchawi kati yao. Hii Magic Box na kuna chumvi ya kazi iliyo mbele. Kabla sijaitenganisha, nitachukua hatua kando na kusema maneno machache kuhusu programu.
Mradi
Programu hutoa utendaji wa kushughulikia kadi za kulipia kabla.
mteja
Kulikuwa na aina mbili za watumiaji. Kwanza kufikiwa kwa kuingia na cheti cha SSL SHA-2. Katika pili ilifikiwa na jina la mtumiaji na nenosiri.
HAProxy
Kisha ombi la mteja lilienda kwa HAProxy, ambayo ilitatua kazi zifuatazo:
- idhini ya msingi;
- kukomesha SSL;
- kurekebisha maombi ya HTTP;
- omba tafsiri.
Uthibitishaji wa cheti cha mteja ulikwenda pamoja na mlolongo. Sisi - mamlaka na tunaweza kumudu hili, kwani sisi wenyewe tunatoa vyeti kwa wateja wa huduma.
Zingatia hoja ya tatu, baadaye kidogo tutairudia.
Backend
Njia ya nyuma ilipangwa kufanywa kwenye Linux. Njia ya nyuma inaingiliana na hifadhidata, inapakia orodha inayohitajika ya marupurupu, na kisha, kulingana na marupurupu gani mtumiaji aliyeidhinishwa anayo, hutoa ufikiaji wa kusaini hati za kifedha na kuzituma kwa utekelezaji, au kutoa aina fulani ya ripoti.
Akiba na HAProxy
Mbali na miktadha miwili ambayo kila mteja alitembea, pia kulikuwa na muktadha wa utambulisho. IdentityServer4 hukuruhusu tu kuingia, hii ni analog ya bure na yenye nguvu ADFS - Huduma za Shirikisho la Saraka.
Ombi la utambulisho lilichakatwa kwa hatua kadhaa. Hatua ya kwanza - mteja piga sehemu ya nyuma, ambayo iliwasiliana na seva hii na kuangalia uwepo wa ishara kwa mteja. Ikiwa haikuipata, ombi lilirudi kwa muktadha lilikotoka, lakini kwa kuelekeza kwingine, na kwa kuelekeza upya lilienda kwa utambulisho.
Hatua ya pili - ombi lilipata kwa ukurasa wa idhini katika IdentityServer, ambapo mteja alijiandikisha, na tokeni iliyosubiriwa kwa muda mrefu ilionekana kwenye hifadhidata ya IdentityServer.
Hatua ya tatu - mteja ameelekezwa kwingine nyuma kwa mazingira ambayo ilitoka.
IdentityServer4 ina kipengele: inarudisha jibu kwa ombi la kurudi kupitia HTTP. Haijalishi jinsi tulivyotatizika kusanidi seva, haijalishi hati zilikuwa na mwanga kiasi gani, kila wakati tulipopokea ombi la awali la mteja na URL iliyokuja kupitia HTTPS, na IdentityServer ilirudisha muktadha uleule, lakini kwa kutumia HTTP. Tulishtuka! Na tulihamisha haya yote kupitia muktadha wa utambulisho hadi HAProxy, na katika vichwa tulilazimika kurekebisha itifaki ya HTTP kwa HTTPS.
Uboreshaji ni nini na umehifadhi wapi?
Tuliokoa pesa kwa kutumia suluhisho lisilolipishwa la kuidhinisha kikundi cha watumiaji, rasilimali, kwa sababu hatukuchukua IdentityServer4 kama nodi tofauti katika sehemu tofauti, lakini tuliitumia pamoja na sehemu ya nyuma kwenye seva hiyo hiyo ambapo urejeshaji wa programu unaendeshwa. .
Jinsi inapaswa kufanya kazi
Kwa hivyo, kama nilivyoahidi - Sanduku la Uchawi. Tayari tunaelewa kuwa tumehakikishiwa kuelekea Linux. Hebu tutengeneze kazi maalum ambazo zinahitajika kutatuliwa.
Puppet inajidhihirisha. Ili kutoa na kudhibiti usanidi wa huduma na matumizi, ilibidi uandike mapishi mazuri. Roli ya penseli inaonyesha kwa ufasaha jinsi ilifanyika haraka na kwa ufanisi.
Njia ya utoaji. Kiwango ni RPM. Kila mtu anaelewa kuwa katika Linux hakuna njia bila hiyo, lakini mradi yenyewe baada ya kusanyiko ulikuwa seti ya faili za DLL zinazoweza kutekelezwa. Kulikuwa na takriban 150 kati yao, mradi huo ni mzito sana. Suluhisho pekee la upatanifu ni kupakia jozi hii kwenye RPM na kupeleka programu kutoka kwayo.
Inatayarisha. Ilitubidi kuachilia mara nyingi sana, na tulilazimika kuamua jinsi ya kuunda jina la kifurushi. Ni swali la kiwango cha ujumuishaji na TFS. Tulikuwa na wakala wa ujenzi kwenye Linux. Wakati TFS inatuma kazi kwa mfanyakazi - mfanyakazi - kwenye wakala wa Kujenga, pia hupitisha rundo la vigezo kwake, ambavyo huanguka katika mazingira ya mchakato wa kushughulikia. Vigezo hivi vya mazingira hupitishwa jina la Kujenga, jina la toleo, na vigezo vingine. Soma zaidi kuhusu hili katika sehemu ya "kujenga kifurushi cha RPM".
Kuanzisha TFS ilikuja kuweka bomba. Hapo awali, tulikusanya miradi yote ya Windows kwenye mawakala wa Windows, na sasa wakala wa Linux anaonekana - wakala wa Kujenga ambaye anahitaji kujumuishwa katika kikundi cha kujenga, kilichoboreshwa na baadhi ya mabaki, kusema ni aina gani ya miradi itajengwa kwenye wakala huu wa Kujenga, na kwa namna fulani urekebishe Pipeline.
IdentityServer. ADFS sio njia yetu, tunazama kwa Open Source.
Hebu tuende kupitia vipengele.
Magic Box
Inajumuisha sehemu nne.
Wakala wa Kujenga Linux. Linux, kwa sababu tunaijenga - ni mantiki. Sehemu hii ilifanywa kwa hatua tatu.
- Weka wafanyikazi na sio moja, kwani kazi iliyosambazwa kwenye mradi ilichukuliwa.
- Sakinisha .NET Core 1.x. Kwa nini 1.x wakati 2.0 tayari inapatikana katika hazina ya kawaida? Kwa sababu tulipoanza maendeleo, toleo thabiti lilikuwa 1.09, na iliamuliwa kuifanya mradi huo.
- Git 2.x.
Hifadhi ya RPM. Vifurushi vya RPM vilihitajika kuhifadhiwa mahali fulani. Tulipaswa kutumia hazina ile ile ya shirika ya RPM ambayo inapatikana kwa wapangishi wote wa Linux. Na ndivyo walivyofanya. Seva ya hifadhi imesanidiwa mtandao ambayo ilipakua kifurushi cha RPM kinachohitajika kutoka eneo maalum. Toleo la kifurushi cha webhook liliripotiwa na wakala wa Muundo.
gitlab. Makini! GitLab haitumiwi hapa na watengenezaji, lakini na idara ya uendeshaji kudhibiti matoleo ya programu, matoleo ya vifurushi, kudhibiti hali ya mashine zote za Linux, na huhifadhi kichocheo - maonyesho yote ya Puppet.
Bomba - hutatua hoja zote zenye utata na kutoa usanidi hasa tunaotaka kutoka kwa Gitlab.
Tunaanza kupiga mbizi. Je, DLL inawasilishwaje kwa RPM?
Kutoa DDL kwa RPM
Hebu tuseme tunayo nyota ya maendeleo ya NET. Inatumia Visual Studio na huunda tawi la kutolewa. Baada ya hapo, inapakia kwa Git, na Git hapa ni chombo cha TFS, yaani, ni hazina ya programu ambayo msanidi hufanya kazi nayo.
Halafu TFS inaona ahadi mpya imefika. Programu gani? Katika mipangilio ya TFS kuna lebo iliyo na rasilimali gani hii au ile Wakala wa Kujenga anayo. Katika kesi hii, inaona kwamba tunaunda mradi wa NET Core na kuchagua wakala wa Linux Build kutoka kwa bwawa.
Wakala wa ujenzi hupokea vyanzo, kupakua muhimu utegemezi kutoka kwa hazina ya NET, npm, n.k. na baada ya kuunda programu yenyewe na ufungaji unaofuata, huwasilisha kifurushi cha RPM kwenye hazina ya RPM.
Kwa upande mwingine, zifuatazo hutokea. Mhandisi wa idara ya operesheni anahusika moja kwa moja katika uanzishaji wa mradi: anabadilisha matoleo ya vifurushi katika Hiera kwenye hifadhi ambapo kichocheo cha maombi kinahifadhiwa, baada ya hapo Puppet huchochea Yum, huchota kifurushi kipya kutoka kwa hazina, na toleo jipya la programu iko tayari kutumika.
Kwa maneno, kila kitu ni rahisi, lakini ni nini kinatokea ndani kwenye Wakala wa Kujenga yenyewe?
Ufungaji wa DLL RPM
Imepokea vyanzo vya mradi na kazi ya kujenga kutoka TFS. Wakala wa ujenzi huanza kujenga mradi wenyewe kutoka kwa vyanzo. Mradi uliokusanywa unapatikana kama seti dll faili, ambazo zimefungwa kwenye kumbukumbu ya zip ili kupunguza mzigo kwenye mfumo wa faili.
Kumbukumbu ya ZIP imetupwa nje kwa saraka ya ujenzi ya kifurushi cha RPM. Ifuatayo, hati ya Bash inaanzisha anuwai za mazingira, hupata toleo la Jenga, toleo la mradi, njia ya saraka ya ujenzi, na inaendesha RPM-build. Wakati ujenzi umekamilika, kifurushi kinachapishwa kwa hazina ya ndani, ambayo iko kwenye wakala wa Kujenga.
Zaidi ya hayo, kutoka kwa wakala wa Jenga hadi seva kwenye hazina ya RPM Ombi la JSON limetumwa kwa jina la toleo na kujenga. Webhook, ambayo nilitaja hapo awali, inapakua kifurushi hiki kutoka kwa hazina ya ndani kwenye Wakala wa Kujenga na kufanya jengo jipya lipatikane kwa usakinishaji.
Kwa nini mpango kama huu wa kupeana kifurushi kwenye hazina ya RPM? Kwa nini huwezi kusukuma kifurushi kilichojengwa mara moja kwenye hazina? Ukweli ni kwamba hili ni sharti la kuhakikisha usalama. Hali hii inapunguza uwezekano wa watu ambao hawajaidhinishwa kupakia vifurushi vya RPM kwenye seva ambayo inaweza kufikiwa na mashine zote za Linux.
Matoleo ya hifadhidata
Katika mashauriano ya maendeleo, iliibuka kuwa watu hao walikuwa karibu na MS SQL, lakini katika miradi mingi isiyo ya Windows tayari tulitumia PostgreSQL kwa nguvu na kuu. Kwa kuwa tayari tumeamua kuachana na kila kitu kilicholipwa, tulianza kutumia PostgreSQL hapa pia.
Katika sehemu hii, ninataka kukuambia jinsi tulivyotoa hifadhidata na jinsi tulivyochagua kati ya Flyway na Entity Framework Core. Fikiria faida na hasara zao.
Africa
Flyway huenda kwa njia moja tu, sisi hatuwezi kurudi nyuma ni hasara kubwa. Unaweza kulinganisha na Entity Framework Core kwa njia zingine - kulingana na urahisi wa msanidi. Unakumbuka kwamba tuliweka hili mbele, na kigezo kuu kilikuwa si kubadili chochote kwa maendeleo ya Windows.
Kwa njia ya ndege yetu aina fulani ya kanga inahitajikaili wavulana wasiandike Maswali ya SQL. Ziko karibu zaidi kufanya kazi kwa mujibu wa OOP. Tuliandika maagizo ya kufanya kazi na vitu vya hifadhidata, tukaunda swali la SQL na kutekeleza. Toleo jipya la hifadhidata iko tayari, limevingirwa - kila kitu ni sawa, kila kitu kinafanya kazi.
Msingi wa Mfumo wa Taasisi una minus - chini ya mizigo mizito, ni hujenga maswali yasiyo ya mojawapo ya SQL, na mchoro kwenye hifadhidata unaweza kuwa muhimu. Lakini kwa kuwa hatuna huduma iliyopakiwa sana, hatuhesabu mzigo katika mamia ya RPS, tulikubali hatari hizi na tukakabidhi tatizo kwa sisi siku zijazo.
Faida
Msingi wa Mfumo wa Taasisi inafanya kazi nje ya boksi na ni rahisi kukuza, na Flyway inaunganisha kwa urahisi katika CI iliyopo. Lakini tunaifanya kwa urahisi kwa watengenezaji :)
Utaratibu wa kusambaza
Puppet anaona kwamba mabadiliko katika toleo la vifurushi inakuja, kati ya ambayo, moja ambayo ni wajibu wa uhamiaji. Kwanza, husakinisha kifurushi ambacho kina hati za uhamiaji na utendaji unaohusiana na hifadhidata. Baada ya hayo, programu inayofanya kazi na hifadhidata inaanza tena. Ifuatayo inakuja ufungaji wa vipengele vilivyobaki. Mpangilio wa vifurushi husakinishwa na programu kuzinduliwa unafafanuliwa katika faili ya maelezo ya Puppet.
Programu hutumia data nyeti, kama vile ishara, manenosiri ya hifadhidata, yote haya yanavutwa hadi kwenye usanidi kutoka kwa bwana wa Puppet, ambapo huhifadhiwa kwa njia iliyosimbwa.
Masuala ya TFS
Baada ya kuamua na kugundua kuwa kila kitu kinatufanyia kazi kweli, niliamua kuona kinachoendelea na makusanyiko ya TFS kwa ujumla kwa idara ya maendeleo ya Win kwenye miradi mingine - ikiwa tunaenda / tunatoa haraka au la, na nikapata shida kubwa na kasi.
Moja ya miradi kuu ni kwenda kwa dakika 12-15 - ni muda mrefu, huwezi kuishi hivyo. Mchanganuo wa haraka ulionyesha mteremko mbaya katika I / O, na hii ni kwenye safu.
Baada ya kuchambua sehemu kwa sehemu, niligundua foci tatu. Kwanza - antivirus ya kaspersky, ambayo huchanganua vyanzo kwenye mawakala wote wa Windows Build. Pili - Windows indexer. Haikuzimwa, na kila kitu kiliwekwa kwenye faharasa kwenye mawakala wa Kujenga kwa wakati halisi wakati wa mchakato wa kupeleka.
Cha tatu - npm kufunga. Ilibadilika kuwa katika Pipelines nyingi tulitumia hali hii. Kwa nini yeye ni mbaya? Utaratibu wa usakinishaji wa Npm unaendeshwa wakati wa kujenga mti wa utegemezi ndani kifurushi-lock.json, ambapo matoleo ya vifurushi ambayo yatatumika kujenga mradi yanarekebishwa. Upande wa chini ni kwamba usakinishaji wa Npm huchota matoleo ya hivi karibuni ya vifurushi kutoka kwa Mtandao kila wakati, na hii ni wakati mwingi katika kesi ya mradi mkubwa.
Wasanidi programu wakati mwingine hufanya majaribio kwenye mashine ya ndani ili kujaribu utendakazi wa sehemu fulani au mradi mzima. Wakati mwingine ikawa kwamba kila kitu kilikuwa cha baridi ndani ya nchi, lakini walikusanya, wakavingirisha - hakuna kitu kilichofanya kazi. Tunaanza kuelewa shida ni nini - ndio, matoleo tofauti ya vifurushi na utegemezi.
uamuzi
- Vyanzo katika vighairi vya AV.
- Zima uwekaji faharasa.
- Mpito kwa npm ci.
Faida ya npm ci ni kwamba sisi kukusanya mti wa utegemezi mara moja, na tunapata fursa ya kumpa msanidi programu orodha ya vifurushi iliyosasishwa, ambayo anaweza kufanya majaribio ndani ya nchi kadri anavyotaka. Hii huokoa wakati watengenezaji wanaoandika msimbo.
Usanidi
Sasa kidogo juu ya usanidi wa hazina. Kihistoria tumetumia Ile dhana ya kusimamia hazina, ikiwa ni pamoja na REPO ya ndani. Hifadhi hii ya ndani inakuja na vipengele vyote tunavyotumia kwa madhumuni ya ndani, kwa mfano, ufuatiliaji wa kujiandikia.
Tunatumia pia NuGet, kwani inahifadhi bora kuliko wasimamizi wengine wa kifurushi.
Matokeo
Baada ya kuboresha mawakala wa ujenzi, muda wa wastani wa ujenzi ulipunguzwa kutoka dakika 12 hadi 7.
Ikiwa tutahesabu mashine zote ambazo tunaweza kutumia kwa Windows, lakini kubadili Linux katika mradi huu, tulihifadhi takriban $ 10. Na hii ni kwa leseni tu, na ikiwa unajumuisha maudhui, zaidi.
Mipango
Katika robo inayofuata, tulipanga kufanya kazi katika kuboresha utoaji wa nambari.
Inabadilisha hadi picha ya kuunda Docker. TFS ni jambo la kupendeza na programu-jalizi nyingi zinazokuwezesha kuunganishwa kwenye Bomba, ikiwa ni pamoja na kujenga kwenye kichochezi, kwa mfano, picha ya Docker. Tunataka kufanya kichochezi hiki sawa kifurushi-lock.json. Ikiwa muundo wa vipengele vinavyotumiwa kujenga mradi kwa namna fulani hubadilika, tunaunda picha mpya ya Docker. Baadaye hutumiwa kupeleka chombo na programu iliyojengwa. Sasa hii sivyo, lakini tunapanga kubadili usanifu wa huduma ndogo huko Kubernetes, ambayo inaendelea kikamilifu katika kampuni yetu na imekuwa ikitoa ufumbuzi wa uzalishaji kwa muda mrefu.
Muhtasari
Ninawasihi kila mtu kutupa Windows, lakini sio kwa sababu siwezi kupika. Sababu ni kwamba suluhisho nyingi za Opensource ni Rafu ya Linux. Je, wewe ni mzuri kuokoa kwenye rasilimali. Kwa maoni yangu, siku zijazo ni za suluhisho la Open Source kwenye Linux na jamii yenye nguvu.
Wasifu wa Spika Alexander Sinchinov .
ni mkutano wa ujumuishaji wa michakato ya maendeleo, upimaji na uendeshaji kwa wataalamu kutoka kwa wataalamu. Ndio maana mradi ambao Alexander alizungumza juu yake? kutekelezwa na kufanya kazi, na matoleo mawili yaliyofaulu yalifanywa siku ya utendaji. Washa Mnamo Mei 27 na 28 kutakuwa na kesi nyingi zaidi kutoka kwa watendaji. Bado unaweza kuruka kwenye gari la mwisho na au si kwa haraka tiketi. Tukutane huko Skolkovo!
Chanzo: mapenzi.com