{"id":32217,"date":"2019-10-31T21:45:43","date_gmt":"2019-10-31T18:45:43","guid":{"rendered":"https:\/\/prohoster.info\/blog\/net-core-na-linux-devops-na-kone\/"},"modified":"2019-10-31T21:45:43","modified_gmt":"2019-10-31T18:45:43","slug":"net-core-na-linux-devops-na-kone","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/net-core-na-linux-devops-na-kone","title":{"rendered":".NET Core na Linuxu, DevOps na konju","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Dejavno smo razvijali DevOps, kot smo mogli. Bilo nas je 8 in Vasja je bil najbolj\u0161i specialist za Windows. Nenadoma je Vasja od\u0161el in pred mano se je pojavila naloga, da uvedem nov projekt, ki vklju\u010duje Windows razvoj. Ko sem postavil na mizo celoten Windows razvojni sklad, sem razumel, da je situacija zelo slaba...<\/p>\n

Tako se za\u010dne zgodba Aleksander Sin\u010dinov<\/b> na DevOpsConf<\/a><\/noindex>. Ko je iz podjetja od\u0161el vodilni strokovnjak za Windows, se je Aleksander vpra\u0161al, kaj storiti zdaj. Preiti na Linux, seveda! Aleksander bo govoril o tem, kako mu je uspelo ustvariti precedens in prenesti del Windows razvoja na Linux na primeru izvedenega projekta za 100.000 kon\u010dnih uporabnikov.<\/p>\n

\".NET
\n
\nKako enostavno in brez te\u017eav dostaviti projekt v RPM, ob uporabi TFS, Puppet, Linux .NET core? Kako vzdr\u017eevati verzioniranje baze podatkov projekta, \u010de razvojna ekipa prvi\u010d sli\u0161i besede Postgres in Flyway, rok za dokon\u010danje pa je jutri? Kako integrirati z Dockerjem? Kako motivirati .NET razvijalce, da se odre\u010dejo Windows in smoothiejem v prid Puppet in Linuxu? Kako re\u0161iti ideolo\u0161ke konflikte, ko za vzdr\u017eevanje Windows v produkciji ni ve\u010d mo\u010di, volje ali sredstev? O tem, pa tudi o Web Deploy, testiranju, CI, praksah uporabe TFS v obstoje\u010dih projektih in seveda o pokvarjenih nastavitvah in delujo\u010dih re\u0161itvah bo govoril Aleksander.
\n<\/a><\/noindex>
\n

\r\n \"Predvajaj\r\n
<\/div>\r\n <\/div><\/center>
\nTorej, Vasja je od\u0161el, naloga pa je z menoj, razvijalci \u010dakajo z vilami. Ko sem dokon\u010dno spoznal, da Vasje ne morem vrniti, sem se lotil dela. Najprej sem ocenil odstotek Windows VM v na\u0161em parku. \u0160tevilke niso bile v prid Windows.<\/p>\n

\".NET
\n
\nKer aktivno razvijamo DevOps, sem spoznal, da je treba spremeniti pristop k uvedbi nove aplikacije. Edina re\u0161itev je bila, da vse mo\u017eno prenesemo na Linux. Google mi je pomagal - v tistem trenutku je bil .Net \u017ee portiran na Linux in razumel sem, da je to re\u0161itev!<\/p>\n

Zakaj .NET core v povezavi z Linuxom?<\/h2>\n

\nZanj je bilo ve\u010d razlogov. Med \u201epla\u010dati denar\u201c in \u201ene pla\u010dati\u201c ve\u010dina izbira drugo \u2014 tako kot jaz. Licenca za MSDB stane okoli 1.000 $, vzdr\u017eevanje parka Windows virtualnih strojev pa je merjeno v stotinah dolarjev. Za veliko podjetje so to veliki stro\u0161ki. Zato prihranek\u00a0<\/b>\u2014 je prvi razlog<\/b>. Ni najpomembnej\u0161i, je pa eden izmed tehtnih.<\/p>\n

Windows virtualni stroji zavzamejo ve\u010d virov kot njihovi Linux bratje \u2014 so te\u017eki<\/b>. Glede na obseg velikega podjetja smo izbrali Linux.<\/p>\n

Sistema se preprosto vklju\u010di v obstoje\u010di CI<\/b>. \u0160e vedno se \u0161tejemo za napredne DevOps-e, uporabljamo Bamboo, Jenkins in GitLab CI, zato ve\u010dina deluje na Linuxu.<\/p>\n

Zadnji razlog je udobno vzdr\u017eevanje. <\/b>Morali smo zni\u017eati prag vstopa za 'vzdr\u017eevalce' \u2013 fante, ki razumejo tehni\u010dne zadeve, zagotavljajo nemoteno delovanje in vzdr\u017eujejo storitve druge ravni. Ti so se \u017ee seznanili s tehnologijo Linux, zato jim je veliko la\u017eje razumeti nov izdelek, ga podpirati in vzdr\u017eevati, kot pa tro\u0161iti dodatne vire za razumevanje primerljive funkcionalnosti programske opreme za Windows platformo.<\/p>\n

Zahteve<\/h2>\n

\nPrvo in najpomembnej\u0161e je udobje nove re\u0161itve za razvijalce<\/b>. Ne v\u0161ecim vsem je bilo lahko sprejeti spremembe, \u0161e posebej po izgovorjeni besedi Linux. Razvijalci \u017eelijo svojo priljubljeno Visual Studio, TFS z avtomatskimi testi po zgradbah in smoothie. Kako se izvaja dostava v produkcijo \u2013 zanje ni pomembno. Zato smo se odlo\u010dili, da ne bomo spreminjali obi\u010dajnega postopka in bomo pustili za Windows razvijalce vse nespremenjeno. <\/p>\n

Nov projekt je treba vklju\u010diti v obstoje\u010di CI<\/b>. Tirnice so \u017ee obstajale in vso delo je bilo treba opraviti ob upo\u0161tevanju parametrov sistema upravljanja konfiguracij, sprejetih standardov dostave in sistemov monitoringa.<\/p>\n

Enostavnost vzdr\u017eevanja in delovanja<\/b>, kot pogoj za minimalni vhodni prag za vse nove udele\u017eence iz razli\u010dnih oddelkov in vzdr\u017eevalnega oddelka.<\/p>\n

Rok je bil v\u010deraj<\/b>.<\/p>\n

Skupina Win razvoja<\/h2>\n

\nS \u010dim je torej delala ekipa Windows?<\/p>\n

\".NET
\n
\nZdaj lahko samozavestno povem, da IdentityServer4<\/b>\u00a0\u2014 to je odli\u010dna brezpla\u010dna alternativa ADFS z enakimi mo\u017enostmi, ali pa Entity Framework Core<\/b>\u00a0\u2014 raj za razvijalca, kjer ni treba skrbeti za pisanje SQL skript, ampak opisovati poizvedbe v BDP v razumljivih OOP izrazih. Ampak takrat, na razpravi o akcijskem na\u010drtu, sem na to tehnologijo gledal kot na \u0161umerko klinopis in poznal le PostgreSQL in Git.<\/p>\n

V tistem \u010dasu smo aktivno uporabljali Puppet<\/b> kot sistem upravljanja konfiguracije. V ve\u010dini na\u0161ih projektov smo uporabljali GitLab CI<\/b>, Elastic<\/b>, uravnote\u017eili visoko obremenjene storitve s pomo\u010djo HAProxy,<\/b> vse spremljali s pomo\u010djo Zabbix<\/b>, povezave Grafana<\/b> in\u00a0Prometheus<\/b>, Jaeger<\/b>, in vse to se je vrtelo na strojni opremi\u00a0HP<\/b> c\u00a0ESXi<\/b> na\u00a0VMware<\/b>. Vsem je znano \u2013 klasika \u017eanra.<\/p>\n

\".NET
\n
\nPoglejmo in posku\u0161ajmo razumeti, kaj se je dogajalo, preden smo za\u010deli vse te posege.<\/p>\n

Kaj je bilo<\/h2>\n

\nTFS je precej zmogljiv sistem, ki ne le prena\u0161a kodo od razvijalca do kon\u010dne produkcijske naprave, ampak tudi ponuja niz mo\u017enosti za zelo fleksibilno integracijo z razli\u010dnimi storitvami \u2013 za zagotavljanje CI na\u8de8\u5e73\u53f0 raven.<\/p>\n

\".NET
\nPrej so bile to same odprtine. TFS je uporabljal ve\u010d Build-agentov, na katerih je bilo zbranih ve\u010d projektov. V vsakem agentu po 3-4 delavce, da so razdelili naloge in optimizirali proces. Nato je TFS, v skladu z na\u010drti izdaje, dostavil sve\u017ee zgrajen Build na Windows stre\u017enik aplikacij.<\/p>\n

Kam smo \u017eeleli priti<\/h2>\n

\nZa dostavo in razvoj uporabljamo TFS, aplikacijo pa zagnamo na Linux stre\u017eniku aplikacij, med njima pa se odvija neka magija. Ta Magic Box<\/b> je tista klju\u010dna komponenta prihodnjega dela. Preden ga razstavim na dele, bom naredil korak nazaj in povedal dve besedi o aplikaciji.<\/p>\n

Projekt<\/h2>\n

\nAplikacija ponuja funkcionalnost za upravljanje s predpla\u010dni\u0161kimi karticami. <\/p>\n

\".NET
\n<\/p>\n

Client<\/h3>\n

\nObstajala sta dva tipa uporabnikov. Prvi<\/b> je imel dostop, avtentificiral se je s certifikatom SSL SHA-2. Drugi\u00a0je imel dostop s prijavno in geslom.<\/b> Nato se je uporabni\u0161ka zahteva poslala v HAProxy, ki je re\u0161eval naslednje naloge:<\/p>\n

HAProxy<\/h3>\n

\nprvotna avtentifikacija;<\/p>\n