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

Vi udviklede DevOps s\u00e5 godt, vi kunne. Vi var 8 personer, og Vasha var den bedste til Windows. Pludselig forlod Vasha, og jeg fik ansvaret for at f\u00f8re et nyt projekt, der skulle levere Windows-udvikling. Da jeg spredte hele stakken af Windows-udvikling ud p\u00e5 bordet, inds\u00e5 jeg, at situationen var problematisk\u2026<\/p>\n

S\u00e5dan begynder historien Alexander Sinchivnov<\/b> og f\u00e5 en fungerende kommando. DevOpsConf<\/a><\/noindex>. Da virksomhedens f\u00f8rende specialist i Windows forlod, stillede Alexander sig selv sp\u00f8rgsm\u00e5let, hvad han nu skulle g\u00f8re. Selvf\u00f8lgelig skulle han overg\u00e5 til Linux! Alexander vil fort\u00e6lle, hvordan han lykkedes med at skabe et pr\u00e6cedens og overf\u00f8re en del af Windows-udviklingen til Linux ved hj\u00e6lp af et projekt med 100.000 slutbrugere.<\/p>\n

\".NET
\n
\nHvordan kan man nemt og ubesv\u00e6ret levere et projekt i RPM ved brug af TFS, Puppet, Linux .NET core? Hvordan kan man opretholde versionering af projektets database, hvis udviklingen aldrig har h\u00f8rt om Postgres og Flyway, og deadline er i overmorgen? Hvordan integreres man med Docker? Hvordan motiverer man .NET-udviklere til at give afkald p\u00e5 Windows og smoothies til fordel for Puppet og Linux? Hvordan l\u00f8ser man ideologiske konflikter, hvis man ikke har hverken kr\u00e6fter, vilje eller ressourcer til at vedligeholde Windows i produktionen? Om dette, samt Web Deploy, test, CI, brugen af TFS i eksisterende projekter, og selvf\u00f8lgelig om de \u00f8delagte st\u00f8ttepiller og fungerende l\u00f8sninger, tales der i transkriptionen af Alexanders pr\u00e6sentation.
\n<\/a><\/noindex>
\n

\r\n \"Afspil\r\n
<\/div>\r\n <\/div><\/center>
\nS\u00e5 Vasha forlod, opgaven l\u00e5 p\u00e5 mig, udviklerne ventede ut\u00e5lmodigt. Da jeg endelig inds\u00e5, at jeg ikke kunne f\u00e5 Vasha tilbage, gik jeg i gang. F\u00f8rst vurderede jeg procentdelen af Windows VM i vores park. Resultatet var ikke til fordel for Windows.<\/p>\n

\".NET
\n
\nDa vi aktivt udvikler DevOps, inds\u00e5 jeg, at jeg m\u00e5tte \u00e6ndre tilgangen til udskiftningen af den nye applikation. Der var kun \u00e9n l\u00f8sning - at overf\u00f8re alt muligt til Linux. Google hjalp mig - p\u00e5 det tidspunkt var .Net allerede blevet porteret til Linux, og jeg inds\u00e5, at det var l\u00f8sningen!<\/p>\n

Hvorfor .NET core i forbindelse med Linux?<\/h2>\n

\nDer var flere grunde til det. Mellem at \u00abbetale penge\u00bb og \u00abikke betale\u00bb vil de fleste v\u00e6lge det andet - ligesom jeg. Licensen til MSDB koster omkring 1.000 $, og vedligeholdelse af parken af Windows virtuelle maskiner koster hundredvis af dollars. For en stor virksomhed er det store omkostninger. Derfor besparelser\u00a0<\/b>\u2014 er den f\u00f8rste grund<\/b>. Ikke den vigtigste, men en af de v\u00e6sentlige.<\/p>\n

Windows virtuelle maskiner kr\u00e6ver flere ressourcer end deres Linux-br\u00f8dre - de er tunge<\/b>. I betragtning af skalaen af en stor virksomhed valgte vi Linux.<\/p>\n

Systemet integreres nemt i den eksisterende CI<\/b>. Vi betragter os som progressive DevOps'ere, bruger Bamboo, Jenkins og GitLab CI, s\u00e5 st\u00f8rstedelen af vores arbejde k\u00f8rer p\u00e5 Linux.<\/p>\n

Den sidste \u00e5rsag er bekvem vedligeholdelse. <\/b>Vi havde brug for at s\u00e6nke indgangsbarriererne for \"vedligeholdere\" - folk, der forst\u00e5r den tekniske del, sikrer driften og vedligeholder tjenesterne fra anden linje. De var allerede bekendte med Linux-stakken, s\u00e5 det var meget nemmere for dem at forst\u00e5 det nye produkt, vedligeholde og supportere det, end at bruge ekstra ressourcer p\u00e5 at s\u00e6tte sig ind i tilsvarende funktionalitet for Windows-platforme.<\/p>\n

Krav<\/h2>\n

\nF\u00f8rst og fremmest er bekvemmeligheden ved den nye l\u00f8sning for udviklerne<\/b>. Ikke alle af dem var klar til \u00e6ndringer, is\u00e6r efter at have h\u00f8rt ordet Linux. Udviklerne \u00f8nsker deres elskede Visual Studio, TFS med automatiserede tests til builds og smoothies. Hvordan leveringen til produktionen sker, er ikke vigtigt for dem. Derfor besluttede vi at bevare den velkendte proces og lade Windows-udviklingen forblive u\u00e6ndret. <\/p>\n

Det nye projekt skal integreres i den eksisterende CI<\/b>. Railsene var allerede p\u00e5 plads, og alt arbejde skulle udf\u00f8res med hensyntagen til konfigurationsstyringssystemets parametre, de vedtagne leveringsstandarder og overv\u00e5gningssystemerne.<\/p>\n

Simplicitet i vedligeholdelse og drift<\/b>, som en betingelse for den minimale indgangsbarriere for alle nye deltagere fra forskellige afdelinger og supportafdelingen.<\/p>\n

Deadline - i g\u00e5r<\/b>.<\/p>\n

Windows-udviklingsgruppen<\/h2>\n

\nHvad arbejdede Windows-teamet s\u00e5 med?<\/p>\n

\".NET
\n
\nNu kan jeg med sikkerhed sige, at IdentityServer4<\/b>\u00a0\u2014 det er et fantastisk gratis alternativ til ADFS med lignende funktionalitet, eller at Entity Framework Core<\/b>\u00a0\u2014 er et paradis for udvikleren, hvor du ikke beh\u00f8ver at bekymre dig om at skrive SQL-scripts, men i stedet kan beskrive databaseforesp\u00f8rgsler i OOP-termer. Men dengang, under diskussionen af handlingsplanen, s\u00e5 jeg p\u00e5 dette stak som p\u00e5 sumerisk kileskrift og genkendte kun PostgreSQL og Git.<\/p>\n

P\u00e5 det tidspunkt brugte vi aktivt Puppet<\/b> som konfigurationsstyringssystem. I de fleste af vores projekter anvendte vi GitLab CI<\/b>, Elastic<\/b>, balancerede h\u00f8jbelastede tjenester ved hj\u00e6lp af HAProxy,<\/b> holdt \u00f8je med alt ved hj\u00e6lp af Zabbix<\/b>, s\u00e6ttet Grafana<\/b> og\u00a0Prometheus<\/b>, Jaeger<\/b>, og alt dette k\u00f8rte p\u00e5 hardware\u00a0HP<\/b> c\u00a0ESXi<\/b> og f\u00e5 en fungerende kommando.\u00a0VMware<\/b>. Alle kender det - klassikeren i genren.<\/p>\n

\".NET
\n
\nLad os se og fors\u00f8ge at forst\u00e5, hvad der skete, f\u00f8r vi begyndte med alle disse indgreb.<\/p>\n

Hvad der skete<\/h2>\n

\nTFS er et ret kraftfuldt system, der ikke kun leverer kode fra udvikleren til den endelige produktionsmaskine, men ogs\u00e5 har et s\u00e6t til meget fleksibel integration med forskellige tjenester - for at sikre CI p\u00e5 tv\u00e6rplatformsniveau.<\/p>\n

\".NET
\nTidligere var det blot et hav af vinduer. TFS brugte flere build-agenter, hvor mange projekter blev samlet. I hver agent var der 3-4 workere for at parallellisere opgaverne og optimere processen. Derefter, i henhold til udgivelsesplanerne, leverede TFS den friskbagte build til Windows-applikationsserveren.<\/p>\n

Hvor vi \u00f8nskede at komme hen<\/h2>\n

\nTil levering og udvikling bruger vi TFS, og vi k\u00f8rer applikationen p\u00e5 Linux-applikationsserveren, og mellem dem er der en slags magi. Denne Magic Box<\/b> er essensen af det kommende arbejde. F\u00f8r jeg g\u00e5r videre med at dele det op, vil jeg tage et skridt til siden og sige et par ord om applikationen.<\/p>\n

Projekt<\/h2>\n

\nApplikationen giver funktionalitet til at h\u00e5ndtere forudbetalte kort. <\/p>\n

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

Client<\/h3>\n

\nDer var to typer brugere. F\u00f8rste<\/b> fik adgang ved at autentificere sig med et SSL SHA-2 certifikat. Den\u00a0den anden<\/b> hadde adgang via login og adgangskode.<\/p>\n

HAProxy<\/h3>\n

\nDerefter blev klientens anmodning sendt til HAProxy, som havde f\u00f8lgende opgaver:<\/p>\n