{"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\/et\/blog\/administrirovanie\/net-core-na-linux-devops-na-kone","title":{"rendered":".NET Core Linuxis, DevOps ratsutamisel","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Me arendame DevOps'i, kuidas oskame. Meid oli 8 inimest ja Vassia oli Windowsi alal parim. \u00dchel p\u00e4eval lahkus Vassia ja mul tekkis \u00fclesanne k\u00e4ivitada uus projekt, mis pakub Windows arendust. Kui ma lauas kokku kogusin kogu Windowsi arendustehnoloogia, siis sain aru, et olukord on valus...<\/p>\n

Nii algab lugu Aleksandr Sin\u010dinov<\/b> . Tundub, et DevOpsConf<\/a><\/noindex>. Kui ettev\u00f5ttest lahkus peamine Windowsi spetsialist, k\u00fcsis Aleksandr endalt, mida n\u00fc\u00fcd teha. Loomulikult liikuda Linuxile! Aleksandr r\u00e4\u00e4gib, kuidas tal \u00f5nnestus luua pretsedent ja viia osa Windowsi arendusest Linuxile, kasutades n\u00e4iteks projekti, millel on 100 000 l\u00f5ppkasutajat.<\/p>\n

\".NET
\n
\nKuidas tellida projekti RPM-i, kasutades TFS-i, Puppetit, Linux .NET core'i? Kuidas hallata projekti andmebaasi versioone, kui arendajad kuulevad Postgresi ja Flywayi nimed esmakordselt ja t\u00e4htaeg on \u00fclehomme? Kuidas integreerida Dockeriga? Kuidas motiveerida .NET arendajaid loobuma Windowsist ja smuutidest Puppet ja Linuxi kasuks? Kuidas lahendada ideoloogilisi konflikte, kui Windowsi tootmisressurss ei ole mitte ainult j\u00f5ud, vaid ka soov ja ressursid? Sellest, samuti Web Deployst, testimisest, CI-st, TFS-i kasutamise praktikast olemasolevates projektides, ja muidugi rikutud tugede ja t\u00f6\u00f6tavate lahenduste kohta, r\u00e4\u00e4gib Aleksandri esitluse \u00fclevaates.
\n<\/a><\/noindex>
\n

\r\n \"M\u00e4ngi\r\n
<\/div>\r\n <\/div><\/center>
\nNii, Vassia lahkus, \u00fclesanne on n\u00fc\u00fcd minu \u00f5lul, arendajad ootavad p\u00f5nevusega. Kui ma l\u00f5puks m\u00f5istsin, et Vassiat ei saa tagasi tuua\u2014alustasin t\u00f6\u00f6d. Esiteks hindasin meie Windowsi virtuaalmasinate protsenti. Numbrid ei olnud Windowsi kasuks.<\/p>\n

\".NET
\n
\nKuna me aktiivselt arendame DevOps'i, m\u00f5istsin, et uus rakenduse v\u00e4ljaandmine peab muutuma. Lahendus oli \u00fcheselt selge\u2014k\u00f5ik tuleb v\u00f5imaluse korral viia Linuxile. Google aitas mind\u2014tol hetkel oli .Net juba Linuxile portitud ja ma sain aru, et see on lahendus!<\/p>\n

Miks .NET core koos Linuxiga?<\/h2>\n

\nSellel oli mitu p\u00f5hjust. Enamiku jaoks, kes peavad valima 'maksta raha' ja 'mitte maksta', valib enamik teise\u2014nagu mina. MSDB litsents maksab umbes 1 000 dollarit, Windowsi virtuaalmasinate hooldus maksab sadu dollareid. Suurettev\u00f5tte jaoks on need suuremad kulud. Seega s\u00e4\u00e4st\u00a0<\/b>\u2014 on esimene p\u00f5hjus<\/b>. Mitte k\u00f5ige olulisem, aga \u00fcks t\u00e4htsamaid.<\/p>\n

Windowsi virtuaalmasinad v\u00f5tavad rohkem ressursse kui nende Linuxi vennad\u2014 nad on rasked<\/b>. Arvestades suure ettev\u00f5tte m\u00f5\u00f5tmeid, valisime Linuxi.<\/p>\n

S\u00fcsteem integreerub lihtsalt olemasolevasse CI-sse<\/b>. Peame end progressiivseteks DevOps-ideks, kasutame Bamboo, Jenkinsit ja GitLab CI-d, seet\u00f5ttu p\u00f5hineb meil enamik Linuxil.<\/p>\n

Viimane p\u00f5hjus on mugav teenindamine. <\/b>Oli vajalik v\u00e4hendada sisenemise l\u00e4ve \u201eteenindajatele\u201c - neile, kes m\u00f5istavad tehnilist poolt, tagavad teenuste t\u00f5rgeteta toimimise ja hooldavad teenuseid teise taseme abil. Nad olid juba tuttavad Linuxi tehnoloogiaga, seega on neil uus toode, selle toetamine ja hooldamine tunduvalt lihtsam, kui kulutada lisaj\u00f5ude Windowsi platvormide sarnaste funktsioonide m\u00f5istmiseks.<\/p>\n

N\u00f5uded<\/h2>\n

\nEsiteks ja k\u00f5ige olulisem on uue lahenduse mugavus arendajatele<\/b>. Mitte k\u00f5ik neist ei olnud muudatusteks valmis, eriti p\u00e4rast s\u00f5na Linuxi mainimist. Arendajad soovivad armastatud Visual Studio't, TFS-i koos automaatsete testidega build'ide jaoks ja smuutisid. Kuidas toimub kohaletoimetamine tootmisse - need ei hooli. Seet\u00f5ttu otsustasime mitte muuta harjumusp\u00e4rast protsessi ja j\u00e4tta Windowsi arendamiseks k\u00f5ik muutumatuks. <\/p>\n

Uus projekt tuleb integreerida olemasolevasse CI-sse<\/b>. R\u00f6\u00f6pad olid juba paigas ning kogu t\u00f6\u00f6 tuli teostada arvestades konfiguratsiooni haldamise s\u00fcsteemi parameetreid, standardse kohaletoimetamise protseduuri ja j\u00e4lgimiss\u00fcsteemide n\u00f5udeid.<\/p>\n

Toetamise ja kasutamise lihtsus<\/b>, nagu tingimus, et k\u00f5ik uued osalejad erinevatest osakondadest ja teenindusosakonnast saaksid madala sisenemise l\u00e4ve.<\/p>\n

T\u00e4htp\u00e4ev oli eile<\/b>.<\/p>\n

Windowsi arendamise grupp<\/h2>\n

\nMillega t\u00f6\u00f6tas Windowsi meeskond?<\/p>\n

\".NET
\n
\nPraegu v\u00f5in kindlalt \u00f6elda, et IdentityServer4<\/b>\u00a0on suurep\u00e4rane tasuta alternatiiv ADFS-ile sarnaste v\u00f5imalustega, v\u00f5i et Entity Framework Core<\/b>\u00a0on arendajate paradiis, kus ei pea muretsema SQL skriptide kirjutamise p\u00e4rast, vaid saab kirjeldada andmebaasi p\u00e4ringuid OOP terminoloogiaga. Kuid siis, k\u00e4imasoleval tegevuskava arutelul, vaatasin sellele tehnoloogiale nagu sumero-keelele, tunnen ainult PostgreSQL-i ja Gitit.<\/p>\n

Sel ajal kasutasime aktiivselt Puppet<\/b> konfiguratsiooni haldamiseks. Enamikus meie projektides kasutasime GitLab CI-d<\/b>, Elastic<\/b>, balanseerisime k\u00f5rge koormusega teenuseid HAProxy-ga,<\/b> k\u00f5ike j\u00e4lgisime Zabbix<\/b>, komplekti Grafana<\/b> ja\u00a0Prometheus<\/b>, Jaeger<\/b>, ja see k\u00f5ik t\u00f6\u00f6tas riistvaral\u00a0HP<\/b> c\u00a0ESXi<\/b> . Tundub, et\u00a0VMware<\/b>. K\u00f5igile tuttav - \u017eanri klassika.<\/p>\n

\".NET
\n
\nVaatame ja proovime m\u00f5ista, mis juhtus enne, kui me k\u00f5ik need sekkumised ette v\u00f5tsime.<\/p>\n

Mis toimus<\/h2>\n

\nTFS on \u00fcsna v\u00f5imas s\u00fcsteem, mis mitte ainult ei toeta koodi edastamist arendajalt l\u00f5pplikku tootmismasinasse, vaid omab ka tugevat t\u00f6\u00f6riistakomplekti, et toetada v\u00e4ga paindlikku integreerimist erinevate teenustega \u2013 CI tagamiseks \u00fclepakkumise tasemel.<\/p>\n

\".NET
\nVarem olid need t\u00e4iesti aknad. TFS kasutas mitmeid Build-agenete, millel koguti kokku palju projekte. Igas agendis oli 3-4 t\u00f6\u00f6tlijat, et t\u00f6id paralleelselt jagada ja protsessi optimeerida. Edasi, vastavalt v\u00e4ljaande plaanidele, edastas TFS v\u00e4rskelt valmistatud Buildi Windowsi rakenduste serverisse.<\/p>\n

Mille poole me tahtsime j\u00f5uda<\/h2>\n

\nKasutame TFS-i edastamiseks ja arendamiseks, aga k\u00e4ivitame rakenduse Linuxi rakenduste serveris, ja nende vahele j\u00e4\u00e4b mingi maagia. See Magic Box<\/b> ongi eelseisva t\u00f6\u00f6 sool. Enne kui hakkame seda t\u00fckeldama, teen sammu k\u00f5rvale ja \u00fctlen paar s\u00f5na rakendusest.<\/p>\n

Projekt<\/h2>\n

\nRakendus pakub funktsionaalsust ette makstud kaartide haldamiseks. <\/p>\n

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

Klient<\/h3>\n

\nOli olemas kaks t\u00fc\u00fcpi kasutajaid. Esimene<\/b> saime ligip\u00e4\u00e4su, autentides SSL SHA-2 sertifikaadi kaudu. Teisel\u00a0oli ligip\u00e4\u00e4s sisselogimise ja parooli kaudu.<\/b> HAProxy<\/p>\n

Edasi l\u00e4ks kliendi p\u00e4ring HAProxy-sse, mis lahendas j\u00e4rgmised \u00fclesanded:<\/h3>\n

\nesmane autentimine;<\/p>\n