Me DevOps bi qasî ku ji destê me dihat pêşxist. Em 8 kes bûn, û Vasya di Windows-ê de herî xweş bû. Ji nişkê ve Vasya çû, û min peywira destpêkirina projeyek nû ya ku ji hêla pêşveçûna Windows-ê ve hatî peyda kirin hebû. Dema ku min tevahiya stûna pêşkeftina Windows-ê avêt ser maseyê, min fêm kir ku rewş êşek e…
Bi vî awayî çîrok dest pê dike Alexandra Sinchinova li ser . Dema ku pisporê sereke yê Windows-ê ji pargîdaniyê derket, Alexander meraq kir ku nuha çi bike. Biguherînin Linux, bê guman! Alexander dê ji we re vebêje ka wî çawa kariye ku pêşnumayek biafirîne û beşek ji pêşkeftina Windows-ê veguhezîne Linux-ê bi mînakek projeyek qedandî ya ji bo 100 bikarhênerên dawîn bikar tîne.
Meriv çawa bi karanîna TFS, Puppet, Linux .NET core projeyek bi hêsanî û bêhêz pêşkêşî RPM dike? Meriv çawa piştgirî dide guhertoya databasek projeyê heke tîmê pêşkeftinê yekem car peyvên Postgres û Flyway dibihîze, û muhleta piştî sibê ye? Meriv çawa bi Docker re yek dibe? Meriv çawa pêşdebirên .NET motîve dike ku dev ji Windows û smoothies berdin Puppet û Linux? Meriv çawa nakokiyên îdeolojîk çareser dike heke ne hêz, ne daxwaz û ne jî çavkaniyên ku Windows-ê di hilberînê de bidomîne hebe? Di derbarê vê de, û her weha di derbarê Web Deploy, ceribandin, CI de, di derbarê pratîkên karanîna TFS-ê de di projeyên heyî de, û, bê guman, di derbarê kelûpelên şikestî û çareseriyên xebatê de, di bernivîsa rapora Alexander de.
Ji ber vê yekê, Vasya çû, peywir li ser min e, pêşdebiran bi bêhnfirehiyê li bendê ne. Dema ku min di dawiyê de fêm kir ku Vasya nayê vegerandin, ez ketim kar. Ji bo destpêkê, min rêjeya Win VM-ên di fîloya me de nirxand. Encam ne di berjewendiya Windows-ê de bû.
Ji ber ku em bi aktîvî DevOps pêşve diçin, min fêm kir ku di nêzîkatiya radestkirina serîlêdanek nû de pêdivî ye ku tiştek were guheztin. Tenê çareseriyek hebû - heke gengaz be, her tiştî veguherînin Linux. Google alîkariya min kir - di wê demê de .Net jixwe ji Linux re hatibû veguhestin, û min fêm kir ku ev çareserî ye!
Çima .NET core bi Linux re?
Çend sedemên vê yekê hebûn. Di navbera "pere bidin" û "nedana" de, piranî dê ya duyemîn hilbijêrin - mîna min. Destûrnameyek ji bo MSDB bi qasî 1 dolar lêçûn; domandina fîloya makîneyên virtual yên Windows bi sedan dolar lê dike. Ji bo pargîdaniyek mezin ev lêçûnek mezin e. Li rê da xilaskirin - sedema yekem. Ne ya herî girîng, lê yek ji wan girîng e.
Makîneyên virtual yên Windows ji birayên xwe yên Linux bêtir çavkaniyan digirin - ew giran in. Ji ber pîvana pargîdaniya mezin, me Linux hilbijart.
Pergal bi tenê di nav CI-ya heyî de tête yek kirin. Em xwe DevOpsên pêşverû dihesibînin, em Bamboo, Jenkins û GitLab CI bikar tînin, ji ber vê yekê piraniya xebata me li Linux-ê dimeşîne.
Sedema dawî ye hevalbendiya hêsan. Me hewce bû ku astengiya têketina "eskort" kêm bikin - xortên ku beşa teknîkî fam dikin, karûbarê bênavber peyda dikin, û karûbarên ji rêza duyemîn biparêzin. Ew jixwe bi staka Linux-ê nas bûn, ji ber vê yekê ji wan re pir hêsantir e ku meriv hilberek nû fam bike, piştgirî û biparêze ji xerckirina çavkaniyên zêde ji bo fêmkirina heman fonksiyona nermalavê ya ji bo platforma Windows-ê.
daxwazên
Berî her tiştî - rehetiya çareseriya nû ji bo pêşdebiran. Ne hemî ji bo guhertinê amade bûn, nemaze piştî ku peyva Linux hate axaftin. Pêşdebiran Visual Studio-ya xweya bijare, TFS-ê bi ototestên ji bo meclîs û nerman dixwazin. Çawa gihandina hilberînê ji bo wan ne girîng e. Ji ber vê yekê, me biryar da ku em pêvajoya asayî neguherînin û ji bo pêşkeftina Windows-ê her tiştî neguherînin.
Projeyek nû hewce ye di CI-ya heyî de entegre bibin. Rêl jixwe li wir bûn û pêdivî bû ku hemî kar li gorî pîvanên pergala rêveberiya vesazkirinê, standardên radestkirinê yên pejirandî û pergalên çavdêriyê bêne kirin.
Hêsaniya piştgirî û operasyonê, wekî şertek ji bo hindiktirîn sînorê têketinê ji bo hemî beşdarên nû yên ji beşên cûda û beşa piştgiriyê.
Deadline - duh.
Koma Pêşkeftina Serkeftinê
Wê demê tîmê Windows bi çi re dixebitî?
Niha ez dikarim bi dilgermî bêjim IdentityServer4 alternatîfek belaş a xweş a ADFS-ê bi kapasîteyên wekhev e, an çi Entity Framework Core - bihuştek ji bo pêşdebirek, ku hûn ne hewce ne ku hûn bi nivîsandina nivîsarên SQL aciz bibin, lê pirsên di databasê de bi şertên OOP rave bikin. Lê dûv re, di dema nîqaşkirina plansaziya çalakiyê de, min li vê stikê nihêrî wekî ku ew tîpa sûmerî be, tenê PostgreSQL û Git nas kir.
Wê demê me bi awayekî aktîf bi kar anî Kejal wekî pergala rêveberiya vesazkirinê. Di piraniya projeyên xwe de me bikar anîn GitLab CI, elastic, karûbarên bilind-barkirina hevseng bikar tînin HAProxy çavdêriya her tiştî bi Zabbix, ligaments Grafana и Prometheus, Neçirvan, û ev hemû li ser perçeyên hesin dizivirîn HP c ESXi li ser VMware. Her kes wê dizane - klasîkek celebê.
Ka em lê binêrin û hewl bidin ku fêm bikin ka çi qewimî berî ku me dest bi van hemî destwerdanan bike.
Çi qewimî
TFS pergalek pir bi hêz e ku ne tenê kodê ji pêşdebiran digihîne makîneya hilberîna paşîn, lê di heman demê de komek ji bo entegrasyona pir maqûl bi karûbarên cihêreng re jî heye - da ku CI di astek cross-platform de peyda bike.
Berê, ev pencereyên hişk bûn. TFS gelek ajanên Build bikar anîn, ku ji bo berhevkirina gelek projeyan hatin bikar anîn. Her ajanek 3-4 karker hene ku peywiran paralel bikin û pêvajoyê xweşbîn bikin. Dûv re, li gorî plansaziyên berdanê, TFS Build-a nû-pijkirî radestî servera serîlêdana Windows-ê kir.
Me dixwest çi bi dest bixin?
Em TFS-ê ji bo radestkirin û pêşkeftinê bikar tînin, û serîlêdanê li ser serverek Serlêdana Linux-ê dimeşînin, û di navbera wan de celebek sêrbaz heye. Ev Magic Box û xwêya xebatê li pêş e. Berî ku ez ji hev veqetînim, ez ê gavekê bavêjim aliyekê û li ser serlêdanê çend peyvan bibêjim.
Projeyê
Serlêdan ji bo birêvebirina qertên pêşdibistanê fonksiyonê peyda dike.
Kirrîxwaz
Du cureyên bikarhêner hebûn. Yekemîn bi têketina bi karanîna sertîfîkayek SSL SHA-2 ve gihîştiye. U duyem gihîştina bi karanîna têketin û şîfreyek hebû.
HAProxy
Dûv re daxwaza xerîdar çû HAProxy, ku pirsgirêkên jêrîn çareser kir:
- destûra bingehîn;
- qedandina SSL;
- tuning daxwazên HTTP;
- daxwazên weşanê.
Sertîfîkaya xerîdar li ser zincîrê hate verast kirin. Em - erc û em dikarin vê yekê bidin, ji ber ku em bixwe sertîfîkayan ji xerîdarên karûbarê re derdixin.
Bala xwe bidin xala sêyem, em ê piçekî paşê vegerin ser wê.
Backend
Wan plan kir ku pişta li Linux-ê çêbikin. Piştgir bi databasê re têkilî dike, navnîşa pêwîst a îmtiyazan bar dike û dûv re, li gorî ka kîjan îmtiyazên bikarhênerê destûrdar heye, gihîştina îmzekirina belgeyên darayî û şandina wan ji bo darvekirinê peyda dike, an celebek raporê çêdike.
Savings bi HAProxy
Ji bilî du çarçoveyên ku her xerîdar rêve kir, çarçoveyek nasnameyê jî hebû. IdentityServer4 tenê dihêle hûn têkevinê, ev ji bo analogek belaş û hêzdar e ADFS - Xizmetên Federasyona Active Directory.
Daxwaza nasnameyê di çend gavan de hate kirin. Gava yekem - miştirî ket nav piştê, ku bi vê serverê re têkilî danî û hebûna nîşanek ji bo xerîdar kontrol kir. Ger nehatiba dîtin, daxwaz vedigerand ser çarçoweya ku jê hatî, lê bi beralîkirinek, û bi beralîkirinê re ew diçû nasnameyê.
Pêngava duyemîn - daxwaz hate wergirtin li ser rûpela destûrnameyê li IdentityServer, cihê ku xerîdar lê tomar kir, û ew tokena ku dirêj-hêvî bû di databasa IdentityServer de xuya bû.
Pêngava sêyemîn - muwekîlê paş ve hate veguhestin ji bo çarçoweya ku jê hatiye.
IdentityServer4 taybetmendiyek heye: ew bersiva daxwaza vegerê bi rêya HTTP vedigerîne. Her çend me di sazkirina serverê de têkoşîn kir, her çend me xwe bi belgeyê ronî kir jî, her carê me daxwaznameyek xerîdar a destpêkê bi URL-ya ku bi HTTPS-ê ve hatî werdigire, û IdentityServer heman çarçoveyê vedigere, lê bi HTTP. Em şok bûn! Û me ev hemî bi navgîniya nasnameya nasnameyê veguhezand HAProxy, û di serî de me neçar ma ku protokola HTTP-ê biguhezînin HTTPS.
Pêşveçûn çi ye û we li ku xilas kir?
Me bi karanîna çareseriyek belaş ji bo destûrdayîna komek bikarhêner, çavkaniyan, drav hilanî, ji ber ku me IdentityServer4 wekî girêkek veqetandî di perçeyek cihêreng de cîh negirt, lê ew bi paşîn re li ser heman serverê ku paşiya serîlêdanê lê dimeşîne bi kar anî. .
Divê çawa kar bike
Ji ber vê yekê, wekî ku min soz da - Magic Box. Em jixwe fam dikin ku em garantî dikin ku ber bi Linux ve biçin. Werin em karên taybetî yên ku çareseriyê hewce dikin formule bikin.
Puppet diyar dike. Ji bo radestkirin û birêvebirina karûbar û veavakirina serîlêdanê, pêdivî bû ku reçeteyên xweş werin nivîsandin. Rollek qelemê bi zelalî nîşan dide ku ew çiqas zû û bi bandor hate çêkirin.
Rêbaza radestkirinê. Standard RPM ye. Her kes fêm dike ku di Linux-ê de hûn nikarin bêyî wê bikin, lê proje bixwe, piştî kombûnê, komek pelên DLL-ê yên darvekirî bû. Nêzîkî 150 ji wan hebûn, proje pir dijwar bû. Çareseriya yekane aheng ev e ku meriv vê binaryê di RPM-ê de pak bike û sepanê jê re bicîh bike.
Versioning. Me neçar ma ku pir caran serbest berdin, û me biryar da ku em çawa navê pakêtê ava bikin. Ev pirsek asta yekbûna bi TFS re ye. Li ser Linux-ê saziyek me hebû. Gava ku TFS peywirek ji kargêrek - xebatkar - re dişîne ji ajansê Build, ew di heman demê de komek guherbarên ku digihîje hawîrdora pêvajoya hilkêşkerê jî derbas dike. Van guhêrbarên jîngehê navê Avakirinê, navê guhertoyê, û guhêrbarên din dihewîne. Li ser vê yekê di beşa "Avakirina pakêtek RPM" de bêtir bixwînin.
Sazkirina TFS hat ji bo sazkirina Pipeline. Berê, me hemî projeyên Windows-ê li ser ajanên Windows-ê berhev kir, lê naha nûnerek Linux-ê xuya dike - ajanek Build, ku pêdivî ye ku di koma çêkirinê de were nav kirin, bi hin huneran ve were dewlemend kirin, û jê re got ka dê çi celeb proje li ser vê ajansê Build were çêkirin. , û bi awayekî Pipeline biguherînin.
IdentityServer. ADFS ne riya me ye, em diçin Çavkaniya Vekirî.
Ka em ji pêkhateyan derbas bibin.
Magic Box
Ji çar beşan pêk tê.
Linux Build agent. Linux, ji ber ku em ji bo wê ava dikin - ew mentiqî ye. Ev beş di sê gavan de pêk hat.
- Karkeran mîheng bikin û ne bi tenê ye, ji ber ku li ser projeyê xebatek belavkirî dihat hêvîkirin.
- NET Core 1.x saz bike. Çima 1.x dema ku 2.0 jixwe di depoya standard de heye? Ji ber ku dema ku me dest bi pêşveçûnê kir, guhertoya stabîl 1.09 bû, û biryar hat dayîn ku proje li ser bingeha wê were çêkirin.
- Git 2.x.
RPM-depo. Pêdivî ye ku pakêtên RPM li cîhek werin hilanîn. Tê texmîn kirin ku em ê heman depoya RPM ya pargîdanî ya ku ji hemî mêvandarên Linux re heye bikar bînin. Tiştê ku kirin jî ev bû. Pêşkêşkara depoyê hatiye mîheng kirin web hook ku pakêta RPM ya pêwîst ji cîhê diyarkirî dakêşand. Guhertoya pakêtê ji hêla agent Build ve ji webhook re hate ragihandin.
GitLab. Baldarî! GitLab li vir ne ji hêla pêşdebiran ve, lê ji hêla beşa xebitandinê ve tê bikar anîn da ku guhertoyên serîlêdanê, guhertoyên pakêtê kontrol bike, rewşa hemî makîneyên Linux-ê bişopîne, û ew reçeteyê hilîne - hemî Puppet diyar dibe.
Kejal - hemî pirsgirêkên nakokî çareser dike û tam konfigurasyona ku em ji Gitlab dixwazin peyda dike.
Em dest bi davêjin. Radestkirina DLL ji RPM re çawa dixebite?
DDL radestkirina RPM
Em bêjin stêrkek rockê ya pêşkeftina .NET heye. Ew Visual Studio bikar tîne û şaxek berdanê diafirîne. Piştî wê, ew wê li Git bar dike, û Git li vir saziyek TFS ye, ango ew depoya serîlêdanê ye ku pêşdebir pê re dixebite.
Piştî vê yekê TFS dibîne ku komîteyek nû hatiye. Kîjan sepanê? Di mîhengên TFS de etîketek heye ku destnîşan dike ka kîjan çavkaniyan xwediyê saziyek taybetî ye. Di vê rewşê de, ew dibîne ku em projeyek .NET Core ava dikin û ajanek Linux Build ji hewzê hildibijêre.
Agent Build çavkaniyan distîne û ya pêwîst dadixe girêdayiyên ji depoya .NET, npm, hwd. û piştî avakirina serîlêdanê bixwe û pakkirina paşê, pakêtê RPM dişîne depoya RPM.
Ji aliyê din ve, jêrîn dibe. Endezyarê beşê operasyonê rasterast di navberkirina projeyê de têkildar e: ew guhertoyên pakêtan diguhezîne Hiera di depoya ku reçeteya serîlêdanê lê tê hilanîn, piştî ku Puppet dest pê dike Yum, pakêta nû ji depoyê distîne, û guhertoya nû ya serîlêdanê amade ye ku bikar bîne.
Her tişt di peyvan de hêsan e, lê di hundurê nûnerê Build bixwe de çi diqewime?
Packaging DLL RPM
Çavkaniyên projeyê wergirtin û ji TFS peywirê ava kirin. Build agent ji çavkaniyan dest bi avakirina projeyê dike. Projeya berhevkirî wekî set heye pelên DLL, ku di arşîvek zip de têne pak kirin da ku barkirina pergala pelan kêm bikin.
Arşîva ZIP tê avêtin ji pelrêça avakirina pakêta RPM re. Dûv re, skrîpta Bash guhêrbarên jîngehê dest pê dike, guhertoya Avakirinê, guhertoya projeyê, riya pelrêça çêkirinê dibîne, û RPM-avakirinê dimeşîne. Piştî ku avakirin qediya, pakêt ji bo weşandin depoya herêmî, ku li ser agent Build located.
Dûv re, ji nûnerê Avakirinê heya servera di depoya RPM de Daxwaza JSON tê şandin navê guherto û avahî nîşan dide. Webhook, ku min berê qala wê kir, vê pakêtê ji depoya herêmî ya li ser agentê Build-ê dadixe û civîna nû ji bo sazkirinê peyda dike.
Çima ev nexşeya radestkirina pakêtê ya taybetî ji depoya RPM re? Çima ez nikarim tavilê pakêta berhevkirî bişînim depoyê? Rastî ev e ku ev şertek ji bo ewlehiyê ye. Ev senaryo îhtîmala kesên bêdestûr barkirina pakêtên RPM-ê li serverek ku ji hemî makîneyên Linux-ê re tê gihîştinê bi sînor dike.
Guhertoya databasê
Di şêwirdariyê de bi tîmê pêşkeftinê re, derket holê ku xort nêzî MS SQL bûn, lê di pir projeyên ne-Windows de me berê bi hemî hêza xwe PostgreSQL bikar anî. Ji ber ku me berê biryar dabû ku em dev ji her tiştê hatî dayîn berdin, me dest bi karanîna PostgreSQL jî li vir kir.
Di vê beşê de ez dixwazim ji we re vebêjim ka me çawa databasê guherto kir û me çawa di navbera Flyway û Entity Framework Core de hilbijart. Ka em li başî û xerabiyên wan binêrin.
Минусы
Flyway tenê yek rê diçe, em em nikarin paşde bizivirin - ev dezavantajeke girîng e. Hûn dikarin wê bi Entity Framework Core re bi awayên din berhev bikin - di warê rehetiya pêşdebiran de. Tê bîra we ku me vê yekê li pêşiyê datîne, û pîvana sereke ew bû ku ji bo pêşkeftina Windows-ê tiştek neyê guheztin.
Ji bo Flyway me cûreyek pêçan hewce bûda ku xort nenivîsin Pirsên SQL. Ew di şertên OOP-ê de pir nêzîktir in. Me talîmatên ji bo xebata bi tiştên databasê re nivîsand, pirsek SQL çêkir û ew kir. Guhertoya nû ya databasê amade ye, ceribandin - her tişt baş e, her tişt dixebite.
Entity Framework Core kêmasiyek heye - di bin barên giran de ew pirsên SQL-ya nebaş ava dike, û kişandina databasê dikare girîng be. Lê ji ber ku em ne xwediyê karûbarek bargiran in, em barkirinê bi sedan RPS hesab nakin, me van xetereyan qebûl kir û pirsgirêk ji me re paşerojê re şand.
Плюсы
Entity Framework Core ji qutîkê dixebite û pêşvexistina hêsan e, û Flyway Bi hêsanî di CI-ya heyî de yek dibe. Lê em wê ji bo pêşdebiran rehet dikin :)
Pêvajoya dorpêçkirinê
Puppet dibîne ku guherînek di guhertoya pakêtê de tê, di nav de ya ku berpirsiyarê koçberiyê ye. Pêşîn, ew pakêtek saz dike ku skrîptên koçberiyê û fonksiyonên girêdayî databasê vedihewîne. Piştî vê yekê, serîlêdana ku bi databasê re dixebite ji nû ve tê destpêkirin. Piştre sazkirina pêkhateyên mayî tê. Rêza ku pakêt têne sazkirin û destpêkirina serlêdanan di manîfestoya Puppet de tê vegotin.
Serlêdan daneyên hesas bikar tînin, wek nîşanekan, şîfreyên databasê, ev hemî ji Puppet masterê di nav mîhengê de têne kişandin, li wir ew bi rengek şîfrekirî têne hilanîn.
Pirsgirêkên TFS
Piştî ku me biryar da û fêhm kir ku her tişt bi rastî ji me re dixebite, min biryar da ku binihêrim ka çi bi meclîsên di TFS-ê de bi tevahî ji bo beşa pêşkeftina Win li ser projeyên din diqewime - gelo em zû ava dikirin/berdidin an na, û pirsgirêkên girîng ên bi lezê kifş kirin.
Yek ji projeyên sereke 12-15 hûrdeman digire ku kom bibe - ew demek dirêj e, hûn nekarin wusa bijîn. Analîzek bilez di I/O de kêmbûnek tirsnak nîşan da, û ev li ser rêzan bû.
Piştî analîzkirina wê pêkhatî bi pêkhate, min sê foci nas kirin. Yekem - "Kaspersky antivirus", ku çavkaniyan li ser hemî nûnerên Windows Build dişoxilîne. Duyem - Windows Indexer. Ew neçalak bû, û her tişt di dema pêvajoyê de li ser ajanên Build-ê di dema rast de hate navnîş kirin.
Sêyem - Npm saz bikin. Derket holê ku di piraniya Pipelines de me ev senaryoya tam bikar anî. Çima ew xerab e? Pêvajoya sazkirinê ya Npm dema ku dara pêwendiyê tê çêkirin tê meşandin package-lock.json, ku versiyonên pakêtên ku dê ji bo avakirina projeyê werin bikar anîn têne tomar kirin. Nerazîbûn ev e ku sazkirina Npm her car guhertoyên herî paşîn ên pakêtan ji Înternetê derdixe, û ev di doza projeyek mezin de gelek wext digire.
Pêşdebir carinan li ser makîneyek herêmî diceribînin da ku biceribînin ka beşek taybetî an tevahî proje çawa dixebite. Carinan derdiket ku her tişt li herêmê sar bû, lê wan ew civandin, hildan, û tiştek nexebitî. Em dest pê dikin ku fêhm bikin ka pirsgirêk çi ye - erê, guhertoyên cihêreng ên pakêtên bi girêdayîbûnê.
biryar
- Çavkaniyên di îstîsnayên AV.
- Indekskirinê neçalak bike.
- Biçe npm ci.
Awantajên npm ci ew in ku em Em carek dara girêdayîbûnê berhev dikin, û em fersendê digirin ku pêşdebir peyda bikin lîsteya pakêtên niha, ya ku ew bi qasî ku jê hez dike dikare herêmî biceribîne. Ev dem xilas dike pêşdebirên ku kodê dinivîsin.
Guhertin
Naha hinekî li ser veavakirina depoyê. Di dîrokê de em bikar tînin Nexus ji bo birêvebirina depoyan, di nav de REPO Navxweyî. Ev depoya navxweyî hemî hêmanên ku em ji bo armancên hundurîn bikar tînin dihewîne, mînakî, çavdêriya xwe-nivîskî.
Em jî bikar tînin NuGet, ji ber ku ew li gorî rêveberên pakêtê yên din caching çêtir e.
Di encama
Piştî ku me Ajansên Avakirinê xweşbîn kir, dema çêkirinê ya navîn ji 12 hûrdem daket 7.
Ger em hemî makîneyên ku me dikaribû ji bo Windows-ê bi kar bianiya bihejmêrin, lê di vê projeyê de guheztin Linux-ê, me bi qasî 10 dolar teserûf kir.
Plans
Ji bo çaryeka pêşîn, me plan kir ku em li ser xweşbînkirina radestkirina kodê bixebitin.
Veguheztina wêneyek pêş-avakirina Docker. TFS bi gelek pêvekan re tiştek xweş e ku destûrê dide te ku hûn di Pipeline-ê de yek bibin, di nav de meclîsa-based a, bêje, wêneyek Docker. Em dixwazin vê teşebusê ji bo heman yekê çêbikin package-lock.json. Ger pêkhatina hêmanên ku ji bo avakirina projeyê têne bikar anîn bi rengek biguhezîne, em wêneyek nû ya Docker ava dikin. Dûv re ew tê bikar anîn da ku konteynerê bi serîlêdana berhevkirî re were bicîh kirin. Ev naha ne wusa ye, lê em plan dikin ku li Kubernetes, ku di pargîdaniya me de bi rengek çalak pêş dikeve û ji bo demek dirêj ve çareseriyên hilberînê re xizmetê dike, veguherînin mîmariya mîkro-xizmetê.
Nîqaş
Ez her kesî teşwîq dikim ku Windows-ê bavêjin, lê ew ne ji ber ku ez nizanim çawa çêdikim. Sedem ev e ku piraniya çareseriyên Opensource in Stack Linux. firroşgeha kelûpelên xwarinê li ser çavkaniyan xilas bike. Bi dîtina min, pêşeroj girêdayî çareseriyên Çavkaniya Vekirî ya li Linux-ê bi civakek hêzdar e.
Profîla axaftvan Alexander Sinchinov .
konferansek li ser yekbûna pêvajoyên pêşkeftin, ceribandin û xebitandinê ji bo pisporan ji hêla pisporan ve ye. Ji ber vê yekê projeya ku Îskender behs kir? pêk anîn û dixebitin, û di roja performansê de du serbestberdanên serkeftî hebûn. Li Di 27 û 28ê Gulanê de dê hîn zêdetir bûyerên bi vî rengî ji bijîjkan hebin. Hûn hê jî dikarin bikevin nav erebeya dawîn û an wextê xwe bigirin qert. Li Skolkovo bi me re hevdîtin bikin!
Source: www.habr.com