Развивме DevOps најдобро што можевме. Бевме 8 луѓе, а Васија беше најкул во Windows. Одеднаш Васија замина, а јас имав задача да започнам нов проект што беше обезбеден од развојот на Windows. Кога го фрлив целиот куп за развој на Windows на маса, сфатив дека ситуацијата е болна...
Вака започнува приказната Александра Синчинова на . Кога водечкиот специјалист за Windows ја напушти компанијата, Александар се прашуваше што да прави сега. Префрлете се на Linux, се разбира! Александар ќе ви каже како успеал да создаде преседан и да пренесе дел од развојот на Windows на Linux користејќи го примерот на завршен проект за 100 крајни корисници.
Како лесно и без напор да испорачате проект до 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 јадрото во врска со Linux?
Имаше неколку причини за ова. Помеѓу „плати пари“ и „не плаќа“, мнозинството ќе го избере вториот - како мене. Лиценцата за MSDB чини околу 1 долари; одржувањето на флота од виртуелни машини Виндоус чини стотици долари. За голема компанија ова е голем трошок. Затоа заштеди - прва причина. Не најважниот, туку еден од позначајните.
Виртуелните машини на Windows заземаат повеќе ресурси од нивните браќа Линукс - тие се тешки. Со оглед на обемот на големата компанија, го избравме Linux.
Системот е едноставно интегриран во постоечкиот CI. Се сметаме за прогресивни DevOps, користиме Bamboo, Jenkins и GitLab CI, така што најголемиот дел од нашата работа работи на Linux.
Последната причина е удобен придружник. Требаше да ја намалиме бариерата за влез за „придружниците“ - момците кои го разбираат техничкиот дел, обезбедуваат непрекинато сервисирање и одржуваат услуги од втората линија. Тие веќе беа запознаени со стекот на Linux, па затоа им е многу полесно да разберат, поддржат и одржуваат нов производ отколку да трошат дополнителни ресурси за да ја разберат истата функционалност на софтверот за платформата Windows.
Барања
Прво и основно - практичноста на новото решение за програмерите. Не сите беа подготвени за промени, особено откако беше изговорен зборот Linux. Програмерите го сакаат своето омилено Visual Studio, TFS со автоматски тестови за склопови и смути. За нив не е важно како ќе дојде до испорака до производство. Затоа, решивме да не го менуваме вообичаениот процес и да оставиме сè непроменето за развој на Windows.
Потребен е нов проект се интегрираат во постојните CI. Шините веќе беа таму и целата работа требаше да се заврши земајќи ги предвид параметрите на системот за управување со конфигурацијата, прифатените стандарди за испорака и системите за следење.
Леснотија на поддршка и работа, како услов за минимален влезен праг за сите нови учесници од различни дивизии и одделот за поддршка.
Рок - вчера.
Win Development Group
Со што работеше тогаш тимот на Windows?
Сега можам со сигурност да го кажам тоа IdentityServer4 е одлична бесплатна алтернатива на ADFS со слични способности, или што Јадро на ентитетска рамка - рај за развивач, каде што не треба да се мачите да пишувате SQL скрипти, туку да ги опишувате прашањата во базата на податоци во термини OOP. Но, тогаш, за време на дискусијата за акциониот план, гледав на овој стек како да е сумерски клинесто писмо, препознавајќи ги само PostgreSQL и Git.
Во тоа време активно користевме куклен како систем за управување со конфигурации. Во повеќето наши проекти користевме GitLab CI, Виткаат, избалансирани услуги со големо оптоварување со користење HAПрокси следеше сè со Zabbix, лигаменти Графана и Прометеј, Џегер, и сето тоа се вртеше на парчиња железо HP c ESXi на VMware. Сите го знаат - класика на жанрот.
Ајде да погледнеме и да се обидеме да разбереме што се случило пред да ги започнеме сите овие интервенции.
Што се случи
TFS е прилично моќен систем кој не само што испорачува код од развивачот до финалната производна машина, туку има и сет за многу флексибилна интеграција со различни услуги - да обезбеди CI на ниво на меѓуплатформа.
Претходно, ова беа цврсти прозорци. TFS користеше неколку Build агенти, кои беа користени за склопување на многу проекти. Секој агент има 3-4 работници за паралелизирање на задачите и оптимизирање на процесот. Потоа, според плановите за издавање, TFS го испорача свежо печениот Build до серверот за апликации за Windows.
Што сакавме да постигнеме?
Ние користиме TFS за испорака и развој, и ја извршуваме апликацијата на Linux Application сервер и има некаква магија меѓу нив. Ова Магична кутија и таму е солта на работата напред. Пред да го расклопам, ќе се тргнам настрана и ќе кажам неколку зборови за апликацијата.
Проект
Апликацијата обезбедува функционалност за ракување со припејд картички.
клиентот
Имаше два типа на корисници. Прво доби пристап со најавување користејќи SSL SHA-2 сертификат. У втората имаше пристап со користење на најава и лозинка.
HAProxy
Потоа барањето на клиентот отиде до HAProxy, кое ги реши следните проблеми:
- примарно овластување;
- SSL завршување;
- подесување HTTP барања;
- барања за емитување.
Сертификатот на клиентот беше потврден долж ланецот. Ние - орган и можеме да си го дозволиме тоа, бидејќи ние самите издаваме сертификати на клиентите на услуги.
Обрнете внимание на третата точка, ќе се вратиме на неа малку подоцна.
Заднинската
Тие планираа да направат бекенд на Linux. Заднината е во интеракција со базата на податоци, ја вчитува потребната листа на привилегии и потоа, во зависност од тоа какви привилегии има овластениот корисник, обезбедува пристап до потпишување финансиски документи и нивно испраќање на извршување или генерирање на некој вид на извештај.
Заштеди со HAProxy
Покрај двата контекста по кои се движеше секој клиент, имаше и идентитетски контекст. IdentityServer4 само ви овозможува да се најавите, ова е бесплатен и моќен аналог за ADFS - Услуги на федерацијата на активниот директориум.
Барањето за идентитет беше обработено во неколку чекори. Првиот чекор - клиент влезе во задниот дел, кој комуницираше со овој сервер и го провери присуството на токен за клиентот. Доколку не се најде, барањето се враќаше назад во контекстот од кој дојде, но со пренасочување, а со пренасочувањето отиде во идентитет.
Втор чекор - барањето е примено на страницата за овластување во IdentityServer, каде што клиентот се регистрирал, а тој долгоочекуван токен се појавил во базата на податоци IdentityServer.
Трет чекор - клиентот беше пренасочен назад на контекстот од кој дојде.
IdentityServer4 има карактеристика: го враќа одговорот на барањето за враќање преку HTTP. Колку и да се мачевме со поставувањето на серверот, колку и да се просветливме со документацијата, секој пат добивавме почетно барање на клиентот со URL што доаѓаше преку HTTPS, а IdentityServer го враќаше истиот контекст, но со HTTP. Бевме шокирани! И сето ова го префрливме преку идентитетскиот контекст на HAProxy, а во заглавијата моравме да го измениме протоколот HTTP во HTTPS.
Кое е подобрувањето и каде заштедивте?
Заштедивме пари со користење на бесплатно решение за овластување група корисници, ресурси, бидејќи не го поставивме IdentityServer4 како посебен јазол во посебен сегмент, туку го користевме заедно со задниот дел на истиот сервер каде што работи заднината на апликацијата. .
Како треба да функционира
Така, како што ветив - Magic Box. Веќе разбираме дека ни е загарантирано да се движиме кон Linux. Ајде да формулираме конкретни задачи кои бараа решенија.
Кукла се манифестира. За да се испорача и да се управува со конфигурацијата на услугите и апликациите, требаше да се напишат одлични рецепти. Ролна молив елоквентно покажува колку брзо и ефикасно е направено.
Начин на достава. Стандардот е RPM. Секој разбира дека во Linux не можете без него, но самиот проект, по склопувањето, беше збир на извршни DLL-датотеки. Ги имаше околу 150, проектот беше доста тежок. Единственото хармонично решение е да го спакувате овој бинарен во RPM и да ја распоредите апликацијата од него.
Верзија. Моравме да пуштаме многу често, и моравме да одлучиме како да го формираме името на пакетот. Ова е прашање на нивото на интеграција со TFS. Имавме build-агент на Linux. Кога TFS испраќа задача до управувачот - работник - до агентот Build, тој исто така му пренесува еден куп променливи кои завршуваат во околината на процесот на управувачот. Овие променливи на околината го содржат името на градбата, името на верзијата и други променливи. Прочитајте повеќе за ова во делот „Градење пакет RPM“.
Поставување TFS се сведе на поставување на Pipeline. Претходно, ги собравме сите проекти на Windows на агенти на Windows, но сега се појавува агент на Linux - агент Build, кој треба да се вклучи во групата за изградба, да се збогати со некои артефакти и да се каже каков тип на проекти ќе бидат изградени на овој Build агент. , и некако модифицирајте го гасоводот.
IdentityServer. ADFS не е наш начин, ние одиме на отворен код.
Ајде да поминеме низ компонентите.
Магична кутија
Се состои од четири дела.
Агент за изградба на Linux. Линукс, затоа што градиме за него - логично е. Овој дел беше направен во три чекори.
- Конфигурирајте работници и не сам, бидејќи се очекуваше дистрибуирана работа на проектот.
- Инсталирајте .NET Core 1.x. Зошто 1.x кога 2.0 е веќе достапен во стандардното складиште? Бидејќи кога го започнавме развојот, стабилната верзија беше 1.09 и беше одлучено да се направи проектот врз основа на тоа.
- Git 2.x.
RPM-складиште. RPM пакетите требаше да се складираат некаде. Се претпоставуваше дека ќе го користиме истото корпоративно складиште за RPM што е достапно за сите хостови на Linux. Така направија. Серверот за складиште е конфигуриран мрежна кука кој го преземал потребниот RPM пакет од наведената локација. Верзијата на пакетот беше пријавена до webhook од страна на агентот Build.
ГитЛаб. Внимание! GitLab овде не се користи од програмери, туку од оперативниот оддел за контрола на верзии на апликации, верзии на пакети, следење на статусот на сите Linux машини и го складира рецептот - сите манифестации на Puppet.
куклен — ги решава сите контроверзни прашања и ја испорачува токму конфигурацијата што ја сакаме од Gitlab.
Почнуваме да нуркаме. Како функционира испораката на DLL до RPM?
Испорака DDL до RPM
Да речеме дека имаме рок-ѕвезда за развој на .NET. Користи Visual Studio и создава гранка за ослободување. После тоа, го прикачува на Git, а Git овде е TFS ентитет, односно тоа е складиштето на апликациите со кое работи развивачот.
После тоа, TFS гледа дека пристигнал нов commit. Која апликација? Во поставките за TFS има ознака што покажува кои ресурси има одреден Build агент. Во овој случај, тој гледа дека градиме проект .NET Core и избира агент за Linux Build од базенот.
Агентот Build ги прима изворите и ги презема потребните зависности од складиштето .NET, npm, итн. и по изградбата на самата апликација и последователно пакување, го испраќа RPM пакетот до складиштето RPM.
Од друга страна, се случува следново. Инженерот на оперативниот оддел е директно вклучен во реализацијата на проектот: тој ги менува верзиите на пакетите Хиера во складиштето каде што е зачуван рецептот за апликација, по што се активира Puppet Yum, го презема новиот пакет од складиштето и новата верзија на апликацијата е подготвена за употреба.
Сè е едноставно со зборови, но што се случува внатре во самиот Build агент?
Пакување DLL RPM
Добиени извори на проектот и изградба на задача од TFS. Изграден агент почнува да го гради самиот проект од извори. Склопениот проект е достапен како комплет DLL датотеки, кои се спакувани во zip архива за да се намали оптоварувањето на датотечниот систем.
Архивата ZIP е фрлена во директориумот за изградба на пакети RPM. Следно, скриптата Bash ги иницијализира променливите на околината, ја наоѓа верзијата Build, верзијата на проектот, патеката до директориумот за изградба и работи RPM-build. Откако ќе заврши изградбата, пакетот се објавува на локално складиште, кој се наоѓа на агентот Build.
Следно, од агентот Build до серверот во складиштето RPM Барањето JSON е испратено означувајќи го името на верзијата и изградбата. Webhook, за кој зборував претходно, го презема токму овој пакет од локалното складиште на агентот Build и го прави новото склопување достапно за инсталација.
Зошто оваа конкретна шема за испорака на пакети до складиштето RPM? Зошто не можам веднаш да го испратам собраниот пакет во складиштето? Факт е дека тоа е услов за обезбедување безбедност. Ова сценарио ја ограничува можноста неовластени луѓе да поставуваат RPM пакети на сервер што е достапен за сите Linux машини.
Верзија на бази на податоци
На консултација со тимот за развој, се покажа дека момците се поблиску до MS SQL, но во повеќето проекти што не се од Windows ние веќе го користевме PostgreSQL со сета нивна сила. Бидејќи веќе решивме да се откажеме од се што е платено, почнавме да користиме PostgreSQL и овде.
Во овој дел сакам да ви кажам како ја верзииравме базата на податоци и како избравме помеѓу Flyway и Entity Framework Core. Ајде да ги погледнеме нивните добрите и лошите страни.
Конс
Flyway оди само на еден начин, ние не можеме да се вратиме назад - ова е значителен недостаток. Можете да го споредите со Entity Framework Core на други начини - во однос на практичноста на програмерите. Се сеќавате дека го ставивме ова во прв план, а главниот критериум беше да не се менува ништо за развој на Windows.
За Flyway us беше потребна некаква обвивказа да не пишуваат момците SQL прашања. Тие се многу поблиску до работење во услови на ООП. Напишавме инструкции за работа со објекти на базата на податоци, генериравме SQL барање и го извршивме. Новата верзија на базата на податоци е подготвена, тестирана - сè е во ред, сè работи.
Entity Framework Core има минус - под тешки оптоварувања гради неоптимални SQL пребарувања, а повлекувањето во базата на податоци може да биде значајно. Но, бидејќи немаме услуга со големо оптоварување, не го пресметуваме оптоварувањето во стотици RPS, ги прифативме овие ризици и го делегиравме проблемот на идните нас.
Добрите
Јадро на ентитетска рамка работи надвор од кутијата и лесно се развива, и Flyway Лесно се интегрира во постојните CI. Но, ние го правиме погодно за програмерите :)
Постапка за собирање
Puppet гледа дека доаѓа промена во верзијата на пакетот, вклучувајќи ја и онаа што е одговорна за миграцијата. Прво, инсталира пакет кој содржи скрипти за миграција и функционалност поврзани со базата на податоци. По ова, апликацијата што работи со базата на податоци се рестартира. Следно доаѓа инсталацијата на останатите компоненти. Редоследот по кој се инсталираат пакетите и се стартуваат апликациите е опишан во Куклен манифест.
Апликациите користат чувствителни податоци, како што се токени, лозинки за бази на податоци, сето тоа е повлечено во конфигурацијата од Puppet master, каде што се складираат во шифрирана форма.
Проблеми со TFS
Откако решивме и сфативме дека сè навистина работи за нас, решив да погледнам што се случува со склоповите во TFS како целина за одделот за развој на Win за други проекти - дали брзо градевме/објавуваме или не, и откриле значителни проблеми со брзината .
Еден од главните проекти трае 12-15 минути за да се собере - тоа е долго време, не можете да живеете така. Брзата анализа покажа ужасно намалување на I/O, и тоа беше на низи.
Откако ја анализирав компонента по компонента, идентификував три фокуси. Прво - „Касперски антивирус“, кој ги скенира изворите на сите агенти за Windows Build. Второ - Windows Индексатор. Не беше оневозможен и сè беше индексирано во реално време на агентите на Build за време на процесот на распоредување.
Трето - Инсталирајте Npm. Се испостави дека во повеќето цевководи го користевме токму ова сценарио. Зошто е лош? Постапката за инсталирање Npm се извршува кога стеблото на зависност е формирано во пакет-брава.json, каде што се снимаат верзиите на пакети кои ќе се користат за изградба на проектот. Недостаток е тоа што инсталацијата Npm ги повлекува најновите верзии на пакети од Интернет секој пат, а тоа одзема многу време во случај на голем проект.
Програмерите понекогаш експериментираат на локална машина за да тестираат како функционира одреден дел или цел проект. Понекогаш се покажа дека сè е кул локално, но тие го склопуваа, го валаа и ништо не работеше. Почнуваме да откриваме што е проблемот - да, различни верзии на пакети со зависности.
Решение
- Извори во AV исклучоци.
- Оневозможи индексирање.
- Оди до npm ci.
Предностите на npm ci се тоа што ние Ние еднаш го собираме дрвото на зависност, и добиваме можност да му обезбедиме на развивачот тековната листа на пакети, со кои може да експериментира локално колку што сака. Ова заштедува време програмери кои пишуваат код.
Конфигурација
Сега малку за конфигурацијата на складиштето. Историски користиме Nexus за управување со складишта, вклучувајќи Внатрешен РЕПО. Ова внатрешно складиште ги содржи сите компоненти што ги користиме за внатрешни цели, на пример, самостојно напишано следење.
Ние исто така користиме NuGet, бидејќи има подобро кеширање во споредба со другите менаџери на пакети.
Резултира
Откако ги оптимизиравме Build Agents, просечното време на градење беше намалено од 12 минути на 7.
Ако ги броиме сите машини што можевме да ги користиме за Windows, но се префрливме на Linux во овој проект, заштедивме околу 10 долари. И тоа е само за лиценците, и повеќе ако ја земеме предвид содржината.
Планови
За следниот квартал планиравме да работиме на оптимизирање на испораката на кодови.
Префрлување на претходно изградена слика на Docker. TFS е одлична работа со многу приклучоци кои ви дозволуваат да се интегрирате во Pipeline, вклучително и склопување базирано на тригер на, да речеме, слика на Docker. Сакаме да го направиме овој активирач за истиот пакет-брава.json. Ако составот на компонентите што се користат за изградба на проектот некако се промени, градиме нова слика на Docker. Подоцна се користи за распоредување на контејнерот со склопената апликација. Сега не е така, но планираме да се префрлиме на микросервисна архитектура во Кубернетес, која активно се развива во нашата компанија и долго време опслужува производствени решенија.
Краток преглед
Ги охрабрувам сите да го фрлаат Windows, но тоа не е затоа што не знам како да го готвам. Причината е што повеќето решенија со отворен код се Линукс стек. Дали си добро заштедете на ресурси. Според мене, иднината им припаѓа на решенијата со отворен код на Linux со моќна заедница.
Профил на говорник на Александар Синчинов .
е конференција за интеграција на процесите на развој, тестирање и работа за професионалци од страна на професионалци. Затоа проектот за кој зборуваше Александар? имплементирана и работена, а на денот на изведбата имаше две успешни изданија. На На 27 и 28 мај ќе има уште повеќе слични случаи од практичарите. Сè уште можете да скокнете во последниот вагон и или одвојте време билет. Запознајте не во Сколково!
Извор: www.habr.com