.NET Core на Linux, DevOps на кон

Разработихме DevOps възможно най-добре. Бяхме 8 души, а Вася беше най-готиният на Windows. Изведнъж Вася си тръгна и аз имах задачата да стартирам нов проект, който се доставя от разработката на Windows. Когато изсипах целия стек за разработка на Windows на масата, осъзнах, че ситуацията е мъка ...

Ето как започва историята Александра Синчинова на DevOpsConf. Когато водещият Windows специалист напусна компанията, Александър се чудеше какво да прави сега. Преминете към Linux, разбира се! Александър ще разкаже как успя да създаде прецедент и да прехвърли част от разработката на Windows към Linux, използвайки примера на реализиран проект за 100 000 крайни потребители.

Как лесно да доставяте проект на RPM с помощта на TFS, Puppet, Linux .NET ядро? Как да поддържам версията на базата данни на проекта, ако разработката чува думите Postgres и Flyway за първи път, а крайният срок е вдругиден? Как да се интегрирам с Docker? Как да мотивираме .NET разработчиците да се откажат от Windows и смутитата в полза на Puppet и Linux? Как да разрешим идеологически конфликти, ако няма сила, няма желание, няма ресурси за обслужване на Windows в производството? За това, както и за Web Deploy, тестване, CI, за практиките за използване на TFS в съществуващи проекти и, разбира се, за счупени патерици и работещи решения, в стенограмата на доклада на Александър.

И така, Вася си тръгна, задачата е върху мен, разработчиците чакат нетърпеливо с вили. Когато най-накрая разбрах, че Вася не може да бъде върнат, се заех с работата. Като начало прецених процента на Win VM в нашия флот. Резултатът не беше в полза на Windows.

Тъй като ние активно разработваме DevOps, разбрах, че нещо трябва да се промени в подхода за изваждане на ново приложение. Имаше само едно решение - ако е възможно, прехвърлете всичко на Linux. Google ми помогна - по това време .Net вече беше пренесен към Linux и разбрах, че това е решението!

Защо .NET core във връзка с Linux?

Имаше няколко причини за това. Между „плащане на пари“ и „неплащане“ мнозинството ще избере второто - като мен. Лицензът за MSDB струва около $1, а поддръжката на набор от виртуални машини с Windows струва стотици долари. За голяма компания това е голям разход. Ето защо спестявания - първа причина. Не най-важният, но един от най-значимите.

Виртуалните машини на Windows заемат повече ресурси от техните събратя на Linux - тежки са. Предвид размера на голяма компания, ние избрахме Linux.

Системата просто се интегрира в съществуващ CI. Смятаме се за прогресивен DevOps, използваме Bamboo, Jenkins и GitLab CI, така че повечето от нас са на Linux.

Последната причина е удобен съпровод. Трябваше да намалим прага за влизане на "maintainers" - момчета, които разбират техническата част, осигуряват приемственост и обслужват услуги от втора линия. Те вече бяха запознати със стека на Linux, така че за тях е много по-лесно да разберат новия продукт, да го поддържат и поддържат, вместо да харчат допълнителни ресурси, за да се справят с подобна функционалност на софтуера за платформата Windows.

Изисквания

Първо и най-важно - удобство на новото решение за разработчиците. Не всички от тях бяха готови за промяна, особено след изговорената дума Linux. Разработчиците искат любимото си Visual Studio, TFS с автоматични тестове за компилация и смутита. За тях не е важно как става доставката до производството. Затова решихме да не променяме обичайния процес и да оставим всичко непроменено за разработката на Windows.

Трябва нов проект вграждане в съществуващ CI. Релсите вече бяха там и цялата работа трябваше да се извърши, като се вземат предвид параметрите на системата за управление на конфигурацията, приетите стандарти за доставка и системите за наблюдение.

Лесна поддръжка и експлоатация, като условие за минимален входен праг за всички нови участници от различни отдели и отдела за поддръжка.

Краен срок - вчера.

Спечелете група за развитие

Какво правеше тогава екипът на Windows?

Сега мога уверено да го кажа IdentityServer4 е страхотна безплатна алтернатива на ADFS с подобни функции или каквото и да е Ядро на Entity Framework - рай за програмист, където можете да не си правите труда да пишете SQL скриптове, но да описвате заявки в базата данни по отношение на OOP. Но тогава, когато обсъждах плана за действие, погледнах на този стек като на шумерски клинопис, разпознавайки само PostgreSQL и Git.

По това време използвахме активно Кукла на конци като система за управление на конфигурацията. В повечето от нашите проекти сме използвали GitLab CI, Еластичен, балансиране на високо натоварени услуги с помощта на HAProxy следеше всичко Zabbix, вързопи Графана и Прометей, Егерова тъкан, и всичко това се въртеше на парчета желязо HP c ESXi на VMware. Всеки знае - класика на жанра.

Нека да погледнем и да се опитаме да разберем какво се е случило, преди да започнем всички тези интервенции.

Какво стана

TFS е доста мощна система, която не само доставя код от разработчика до крайната производствена машина, но също така има набор за много гъвкава интеграция с различни услуги - за предоставяне на CI на кросплатформено ниво.

Преди това бяха твърди вентилационни отвори. TFS използва няколко агенти за изграждане, които изградиха много проекти. Всеки агент има 3-4 работници за паралелизиране на задачите и оптимизиране на процеса. Освен това, според плановете за издаване, TFS достави прясно изпечената компилация на сървъра за приложения на Windows.

Къде искахме да отидем

Използваме TFS за доставка и разработка и изпълняваме приложението на сървъра за приложения на Linux и между тях има някаква магия. Това Магическа кутия и там е солта на предстоящата работа. Преди да го разглобя, ще направя крачка встрани и ще кажа няколко думи за приложението.

Проект

Приложението предоставя функционалност за работа с предплатени карти.

Удовлетвореност

Имаше два типа потребители. Първи достъпен чрез влизане с SSL SHA-2 сертификат. При второто беше достъпно с потребителско име и парола.

HAProxy

След това клиентската заявка отиде до HAProxy, който реши следните задачи:

• първично разрешение;
• прекратяване на SSL;
• настройка на HTTP заявки;
• поискайте превод.

Проверката на клиентския сертификат вървеше по веригата. ние - власт и можем да си го позволим, тъй като сами издаваме сертификати на клиентите на услугата.

Обърнете внимание на третата точка, малко по-късно ще се върнем към нея.

бекенда

Бекендът беше планиран да бъде направен на Linux. Бекендът взаимодейства с базата данни, зарежда необходимия списък с привилегии и след това, в зависимост от това какви привилегии има оторизираният потребител, предоставя достъп за подписване на финансови документи и изпращането им за изпълнение или генериране на някакъв вид отчет.

Спестявания с HAProxy

В допълнение към двата контекста, в които всеки от клиентите вървеше, имаше и контекст на идентичност. IdentityServer4 просто ви позволява да влезете, това е безплатен и мощен аналог за ADFS - Услуги за федерация на Active Directory.

Заявката за самоличност беше обработена на няколко стъпки. Първа стъпка - клиент удари бекенда, който комуникира с този сървър и проверява за наличието на токен за клиента. Ако не го намери, заявката се връща обратно към контекста, от който идва, но с пренасочване, а с пренасочване отива към самоличност.

Втората стъпка - заявката е получена към страницата за оторизация в IdentityServer, където клиентът се регистрира и дългоочакваният токен се появи в базата данни на IdentityServer.

трета стъпка - клиентът е пренасочен обратно към контекста, от който идва.

IdentityServer4 има функция: той връща отговора на заявката за връщане чрез HTTP. Колкото и да се борехме с настройката на сървъра, колкото и просветена да беше документацията, всеки път, когато получавахме първоначалната клиентска заявка с URL адрес, идващ през HTTPS, и IdentityServer връщаше същия контекст, но с HTTP. Бяхме шокирани! И прехвърлихме всичко това през контекста на самоличността към HAProxy и в заглавките трябваше да променим HTTP протокола на HTTPS.

Какво е подобрението и къде спестихте?

Спестихме пари, като използвахме безплатно решение за оторизиране на група потребители, ресурси, защото не извадихме IdentityServer4 като отделен възел в отделен сегмент, а го използвахме заедно с бекенда на същия сървър, където работи бекендът на приложението .

Как трябва да работи

И така, както обещах - Magic Box. Вече разбираме, че гарантирано ще преминем към Linux. Нека формулираме конкретните задачи, които трябваше да бъдат решени.

Куклени манифести. За да доставите и управлявате конфигурацията на услугата и приложението, трябваше да напишете страхотни рецепти. Ролката с молив красноречиво показва колко бързо и ефективно е направено.

Метод на доставка. Стандартът е RPM. Всеки разбира, че в Linux няма начин без него, но самият проект след сглобяването беше набор от изпълними DLL файлове. Бяха около 150, проектът е доста тежък. Единственото хармонично решение е да опаковате този двоичен файл в RPM и да разгърнете приложението от него.

Версиониране. Трябваше да пускаме много често и трябваше да решим как да формираме името на пакета. Това е въпрос на ниво на интеграция с TFS. Имахме агент за изграждане на Linux. Когато TFS изпрати задача на работник - worker - на Build агента, той също така му предава куп променливи, които попадат в средата на процеса на манипулатора. На тези променливи на средата се предават име на компилация, име на версия и други променливи. Прочетете повече за това в раздела "изграждане на RPM пакет".

Настройка на TFS се сведе до настройка на Pipeline. Преди това събирахме всички проекти на Windows на Windows агенти, а сега се появява Linux агент - Build агент, който трябва да бъде включен в групата за изграждане, обогатен с някои артефакти, за да каже какъв тип проекти ще бъдат изградени на този Build агент, и по някакъв начин да модифицирате Pipeline.

IdentityServer. ADFS не е нашият начин, ние се давим за Open Source.

Да преминем през компонентите.

Магическа кутия

Състои се от четири части.

Агент за изграждане на Linux. Linux, защото ние изграждаме за него - това е логично. Тази част беше направена в три стъпки.

• Настройте работници а не един, както се предполагаше разпределената работа по проекта.
• Инсталирайте .NET Core 1.x. Защо 1.x, когато 2.0 вече е наличен в стандартното хранилище? Защото, когато започнахме разработката, стабилната версия беше 1.09 и беше решено да направим проекта за нея.
• Git 2.x.

RPM хранилище. RPM пакетите трябваше да се съхраняват някъде. Трябваше да използваме същото корпоративно RPM хранилище, което е достъпно за всички Linux хостове. Така и направиха. Сървърът на хранилището е конфигуриран уеб кука който е изтеглил необходимия RPM пакет от посоченото място. Версията на пакета на webhook беше докладвана от агента за изграждане.

gitlab. внимание! GitLab се използва тук не от разработчици, а от оперативния отдел за контрол на версиите на приложенията, версиите на пакетите, контрол на състоянието на всички Linux машини и съхранява рецептата - всички манифести на Puppet.

Кукла на конци - решава всички спорни точки и доставя точно конфигурацията, която искаме от Gitlab.

Започваме да се гмуркаме. Как DLL се доставя на RPM?

Доставяне на DDL към RPM

Да кажем, че имаме рок звезда за разработка на .NET. Той използва Visual Studio и създава клон за освобождаване. След това го качва в Git, а Git тук е TFS обект, тоест това е хранилището на приложението, с което работи разработчикът.

Тогава TFS вижда, че е пристигнал нов ангажимент. Кое приложение? В настройките на TFS има етикет с това какви ресурси има този или онзи Build агент. В този случай той вижда, че изграждаме проект .NET Core и избира агент за изграждане на Linux от пула.

Build-agent получава източниците, изтегля необходимото зависимости от хранилището на .NET, npm и т.н. и след изграждане на самото приложение и последващо опаковане, предава RPM пакета в RPM хранилището.

От друга страна се получава следното. Инженерът от оперативния отдел участва пряко в разгръщането на проекта: той променя версиите на пакетите в Хиера в хранилището, където се съхранява рецептата за приложение, след което се задейства Puppet Yum, изтегля нов пакет от хранилището и новата версия на приложението е готова за използване.

На думи всичко е просто, но какво се случва вътре в самия Build агент?

Пакетиране на DLL RPM

Получени източници на проект и задача за изграждане от TFS. Агент за изграждане започва да изгражда самия проект от източници. Сглобеният проект се предлага в комплект dll файлове, които са опаковани в zip архив, за да се намали натоварването на файловата система.

ZIP архивът е изхвърлен към директорията за компилация на RPM пакета. След това скриптът Bash инициализира променливите на средата, намира версията на компилацията, версията на проекта, пътя до директорията за компилация и изпълнява RPM-build. Когато изграждането приключи, пакетът се публикува в локално хранилище, който се намира на Build agent.

Освен това от Build агента към сървъра в RPM хранилището JSON заявката е изпратена с името на версията и компилацията. Webhook, който споменах по-рано, изтегля същия този пакет от локалното хранилище на Build агента и прави новата компилация достъпна за инсталиране.

Защо такава схема за доставка на пакет до RPM хранилището? Защо не можете незабавно да изпратите изградения пакет в хранилището? Факт е, че това е условие за гарантиране на сигурността. Този сценарий ограничава възможността неупълномощени хора да качват RPM пакети на сървър, който е достъпен за всички Linux машини.

Версиониране на бази данни

На консултацията за разработка се оказа, че момчетата са по-близо до MS SQL, но в повечето проекти, които не са Windows, ние вече използвахме PostgreSQL с пълна сила. Тъй като вече решихме да изоставим всичко платено, започнахме да използваме PostgreSQL и тук.

В тази част искам да ви разкажа как направихме версии на базата данни и как избрахме между Flyway и Entity Framework Core. Помислете за техните плюсове и минуси.

Против

Flyway върви само в една посока, ние не можем да се върнем назад е съществен недостатък. Можете да сравните с Entity Framework Core по други начини - по отношение на удобството за разработчици. Спомняте си, че поставихме това на преден план и основният критерий беше да не променяме нищо за разработката на Windows.

За нас необходима е някаква обвивкатака че момчетата да не пишат SQL заявки. Те са много по-близки до работа по отношение на OOP. Написахме инструкции за работа с обекти на база данни, формирахме SQL заявка и я изпълнихме. Новата версия на базата данни е готова, навита - всичко е наред, всичко работи.

Entity Framework Core има минус - при големи натоварвания, то изгражда неоптимални SQL заявкии намаляването на базата данни може да бъде значително. Но тъй като нямаме високо натоварена услуга, не изчисляваме натоварването в стотици RPS, ние приехме тези рискове и делегирахме проблема на бъдещето.

Професионалисти

Ядро на Entity Framework работи извън кутията и е лесен за разработванеи Flyway лесно се интегрира в съществуващ CI. Но ние го правим удобно за разработчиците :)

Рол-он процедура

Puppet вижда, че предстои промяна във версията на пакетите, сред които този, който отговаря за миграцията. Първо, той инсталира пакет, който съдържа миграционни скриптове и функционалност, свързана с базата данни. След това приложението, което работи с базата данни, се рестартира. Следва инсталирането на останалите компоненти. Редът, в който се инсталират пакети и стартират приложения, е описан в манифеста на Puppet.

Приложенията използват чувствителни данни, като токени, пароли за бази данни, всичко това се изтегля в конфигурацията от Puppet master, където се съхраняват в криптирана форма.

Проблеми с TFS

След като решихме и разбрахме, че всичко наистина работи за нас, реших да видя какво се случва със сглобките в TFS като цяло за отдела за разработка на Win по други проекти - независимо дали ще / пускаме бързо или не, и открих значителни проблеми с скорост .

Един от основните проекти върви към 12-15 минути - това е много време, не може да се живее така. Бърз анализ показа ужасно намаляване на I / O и това е на масиви.

След като анализирах компонент по компонент, идентифицирах три огнища. първо - антивирус на касперски, който сканира източниците на всички агенти на Windows Build. второ - Windows индексатор. Не беше деактивиран и всичко беше индексирано в агентите за изграждане в реално време по време на процеса на внедряване.

трето - npm инсталирайте. Оказа се, че в повечето Pipeline използваме този сценарий. Защо е лош? Процедурата за инсталиране на Npm се изпълнява при изграждане на дървото на зависимостите package-lock.json, където са фиксирани версиите на пакетите, които ще се използват за изграждане на проекта. Недостатъкът е, че инсталацията на Npm изтегля най-новите версии на пакети от интернет всеки път, а това е много време в случай на голям проект.

Разработчиците понякога експериментират на локална машина, за да тестват производителността на определена част или цял проект. Понякога се оказа, че всичко е готино на местно ниво, но те го събраха, пуснаха го - нищо не работи. Започваме да разбираме какъв е проблемът - да, различни версии на пакети със зависимости.

Решение

• Източници в AV изключения.
• Деактивиране на индексирането.
• Отидете на npm ci.

Предимството на npm ci е, че ние съберете дървото на зависимостите веднъж, и получаваме възможността да предоставим разработчика актуален списък с пакети, с които той може да експериментира на местно ниво, колкото си иска. Това спестява време разработчици, които пишат кода.

Конфигурация

Сега малко за конфигурацията на хранилището. Исторически сме използвали SSI Nexus за управление на хранилища, включително Вътрешно РЕПО. Това вътрешно хранилище идва с всички компоненти, които използваме за вътрешни цели, например самонаписано наблюдение.

Ние също използваме NuGet, тъй като кешира по-добре от другите мениджъри на пакети.

Резултат

След като оптимизирахме агентите за изграждане, средното време за изграждане беше намалено от 12 минути на 7.

Ако преброим всички машини, които можехме да използваме за Windows, но преминахме към Linux в този проект, спестихме около $ 10 000. И това е само от лицензи, а ако включите съдържание, повече.

Планове

За следващото тримесечие планирахме да работим върху оптимизирането на доставката на код.

Превключване към предварително компилирано изображение на Docker. TFS е страхотно нещо с много плъгини, които ви позволяват да се интегрирате в Pipeline, включително изграждане на тригер, например изображение на Docker. Искаме да направим този тригер на същото package-lock.json. Ако съставът на компонентите, които се използват за изграждане на проекта, се промени по някакъв начин, ние изграждаме ново изображение на Docker. По-късно се използва за разгръщане на контейнера с изграденото приложение. Сега това не е така, но планираме да преминем към микросервизна архитектура в Kubernetes, която се развива активно в нашата компания и обслужва производствени решения от дълго време.

Обобщение

Призовавам всички да изхвърлят Windows, но не е защото не мога да го готвя. Причината е, че повечето решения с отворен код са такива Linux стек. Добър ли си спестете ресурси. Според мен бъдещето принадлежи на решенията с отворен код за Linux с мощна общност.

Профил на лектора Александър Синчинов на GitHub.

DevOps Conf е конференция за интегриране на процеси за разработка, тестване и работа за професионалисти от професионалисти. Ето защо проектът, за който говори Александър? внедрена и работеща, а в деня на представянето бяха направени две успешни версии. На DevOps Conf в RIT++ На 27 и 28 май ще има още повече такива случаи от практикуващи лекари. Все още можете да скочите в последния вагон и подадете доклад или не бърза резервирам билет. Ще се видим в Сколково!

Източник: www.habr.com