A DevOps-t a lehető legjobban fejlesztettük. 8-an voltunk, és Vasya volt a legmenőbb a Windowsban. Vasya hirtelen távozott, és az volt a feladatom, hogy elindítsak egy új projektet, amelyet a Windows fejlesztés biztosított. Amikor az egész Windows fejlesztési csomagot az asztalra tettem, rájöttem, hogy a helyzet fájdalmas...
Így kezdődik a történet Alexandra Sinchinova on . Amikor a vezető Windows-specialista elhagyta a céget, Alexander azon töprengett, mit tegyen most. Természetesen váltson Linuxra! Alexander elmeséli, hogyan sikerült precedenst teremtenie és a Windows-fejlesztés egy részét Linuxra vinni egy 100 000 végfelhasználó számára befejezett projekt példáján.
Hogyan lehet egyszerűen és könnyedén eljuttatni egy projektet az RPM-hez TFS, Puppet, Linux .NET mag használatával? Hogyan lehet támogatni egy projekt adatbázis verziószámát, ha a fejlesztőcsapat először hallja a Postgres és a Flyway szavakat, és a határidő holnapután? Hogyan lehet integrálni a Dockerrel? Hogyan lehet motiválni a .NET fejlesztőket, hogy hagyják el a Windows-t és a turmixokat a Puppet és a Linux javára? Hogyan lehet feloldani az ideológiai konfliktusokat, ha nincs se erő, se kedv, se erőforrás a Windows termelésben való karbantartásához? Erről, valamint a Web Deploy-ról, a tesztelésről, a CI-ről, a TFS használatának gyakorlatáról a meglévő projektekben, és természetesen a törött mankókról és a működő megoldásokról Alexander jelentésének átiratában.
Szóval, Vasya elment, a feladat rajtam van, a fejlesztők türelmetlenül várnak vasvillával. Amikor végre rájöttem, hogy Vasyát nem lehet visszaküldeni, hozzáfogtam az üzlethez. Először is felmértem a Win virtuális gépek százalékos arányát a flottánkban. Az eredmény nem a Windows javára szólt.
Mivel aktívan fejlesztjük a DevOps-t, rájöttem, hogy valamit változtatni kell egy új alkalmazás szállításának megközelítésén. Csak egy megoldás volt – ha lehetséges, vigyen át mindent Linuxra. A Google segített – akkoriban a .Net már át volt portolva Linuxra, és rájöttem, hogy ez a megoldás!
Miért érdemes a .NET magot a Linuxszal együtt használni?
Ennek több oka is volt. A „fizess pénzt” és a „nem fizess” között a többség a másodikat választja – mint én. Az MSDB licence körülbelül 1 dollárba kerül; a Windows virtuális gépek flottájának fenntartása több száz dollárba kerül. Egy nagy cég számára ez nagy kiadás. Ezért megtakarítás - első ok. Nem a legfontosabb, de az egyik legjelentősebb.
A Windows virtuális gépek több erőforrást igényelnek, mint linuxos testvéreik - nehezek. A nagy cég méreteire való tekintettel a Linuxot választottuk.
A rendszer egyszerűen integrálható a meglévő CI-be. Progresszív DevOps-nak tartjuk magunkat, Bamboo-t, Jenkinst és GitLab CI-t használunk, így munkánk nagy része Linuxon fut.
Az utolsó ok az kényelmes kíséret. Le kellett csökkentenünk a belépési korlátot a „kísérők” számára – olyan srácok számára, akik értik a technikai részt, biztosítják a zavartalan szolgáltatást, és a második vonalból tartják fenn a szolgáltatásokat. Már ismerték a Linux-vermet, így sokkal könnyebb számukra egy új termék megértése, támogatása és karbantartása, mint további erőforrások kiadása a Windows platformra szánt szoftverek ugyanazon funkcióinak megértésére.
Követelmények
Elsősorban - az új megoldás kényelme a fejlesztők számára. Nem mindegyik volt kész a változásra, különösen a Linux szó elhangzása után. A fejlesztők kedvenc Visual Studio-jukat, a TFS-t akarják automatikus tesztekkel az összeállításokhoz és a turmixokhoz. Számukra nem fontos, hogy a gyártásba való szállítás hogyan történik. Ezért úgy döntöttünk, hogy nem változtatjuk meg a szokásos folyamatot, és mindent változatlanul hagyunk a Windows fejlesztése során.
Új projekt szükséges integrálni a meglévő CI-be. A sínek már megvoltak, és minden munkát a konfigurációkezelő rendszer, az elfogadott szállítási szabványok és a felügyeleti rendszerek paramétereinek figyelembevételével kellett elvégezni.
Könnyű támogatás és kezelés, a minimális belépési küszöb feltételeként a különböző részlegekből és a támogatási osztályból származó összes új résztvevő esetében.
Határidő - tegnap.
Win Development Group
Mivel dolgozott akkor a Windows csapata?
Most már bátran kijelenthetem IdentityServer4 egy klassz ingyenes alternatíva az ADFS-hez hasonló képességekkel, vagy mi Entitás-keretrendszer mag - fejlesztők paradicsoma, ahol nem kell SQL szkriptek írásával vesződni, hanem az adatbázisban lévő lekérdezéseket OOP kifejezésekkel leírni. De aztán az akcióterv megvitatása közben úgy néztem erre a veremre, mintha sumér ékírás lenne, és csak a PostgreSQL-t és a Git-et ismertem fel.
Akkoriban aktívan használtuk Báb konfigurációkezelő rendszerként. A legtöbb projektünkben használtuk GitLab CI, Rugalmas, kiegyensúlyozott nagy terhelésű szolgáltatások segítségével HAProxy mindent figyelemmel kísért Zabbix, szalagok grafana и Prométheusz, Vadász, és mindez vasdarabokon forgott HP c ESXi on VMware. Mindenki ismeri – a műfaj klasszikusa.
Nézzük meg és próbáljuk megérteni, mi történt, mielőtt elkezdtük ezeket a beavatkozásokat.
Mi történt
A TFS egy meglehetősen nagy teljesítményű rendszer, amely nem csak a kódot szállítja a fejlesztőtől a végső gyártási gépig, hanem rendelkezik egy készlettel is a különféle szolgáltatásokkal való nagyon rugalmas integrációhoz - a CI biztosításához platformok közötti szinten.
Korábban ezek tömör ablakok voltak. A TFS több Build ügynököt használt, amelyeket sok projekt összeállítására használtak. Minden ügynöknek 3-4 dolgozója van a feladatok párhuzamosításához és a folyamat optimalizálásához. Aztán a kiadási tervek szerint a TFS a frissen sült Build-et szállította a Windows alkalmazásszerverére.
Mit akartunk elérni?
TFS-t használunk szállításra és fejlesztésre, az alkalmazást Linux Application szerveren futtatjuk, és van köztük valami varázslat. Ez Magic Box és ott van a munka sója. Mielőtt szétszedem, félrelépek, és néhány szót ejtek az alkalmazásról.
Terv
Az alkalmazás az előre fizetett kártyák kezeléséhez nyújt funkcionalitást.
Vásárló
Kétféle felhasználó volt. Első SSL SHA-2 tanúsítvánnyal való bejelentkezéssel jutott hozzá. U a második bejelentkezéssel és jelszóval lehetett hozzáférni.
HAProxy
Ezután az ügyfél kérése a HAProxyhoz ment, amely a következő problémákat oldotta meg:
- elsődleges engedély;
- SSL megszüntetése;
- HTTP kérések hangolása;
- közvetítési kérések.
Az ügyféltanúsítványt a lánc mentén ellenőrizték. Mi - hatóság és ezt meg is engedhetjük magunknak, hiszen mi magunk adunk ki tanúsítványokat a szolgáltató ügyfeleknek.
Figyeljünk a harmadik pontra, erre kicsit később visszatérünk.
háttér
Azt tervezték, hogy a háttérrendszert Linuxra készítik. A háttérrendszer interakcióba lép az adatbázissal, betölti a szükséges jogosultságok listáját, majd attól függően, hogy a jogosult felhasználó milyen jogosultságokkal rendelkezik, hozzáférést biztosít a pénzügyi dokumentumok aláírásához és végrehajtásra küldéséhez, vagy valamilyen jelentés elkészítéséhez.
Megtakarítás a HAProxyval
Azon a két kontextuson kívül, amelyben minden ügyfél navigált, létezett egy identitáskontextus is. IdentityServer4 csak bejelentkezést tesz lehetővé, ez egy ingyenes és hatékony analóg a számára ADFS - Active Directory összevonási szolgáltatások.
Az identitásigénylés feldolgozása több lépésben történt. Első lépés - ügyfél bekerült a háttérbe, amely kommunikált ezzel a szerverrel, és ellenőrizte a kliens tokenjének jelenlétét. Ha nem található, a kérés visszakerült abba a kontextusba, ahonnan érkezett, de átirányítással, és az átirányítással az identitáshoz ment.
Második lépés - a kérés beérkezett az IdentityServer engedélyezési oldalára, ahol az ügyfél regisztrált, és a régóta várt token megjelent az IdentityServer adatbázisban.
Harmadik lépés - az ügyfelet visszairányították ahhoz a kontextushoz, amelyből származott.
Az IdentityServer4 rendelkezik a következő funkcióval: HTTP-n keresztül adja vissza a választ a visszatérési kérésre. Bármennyire is küszködtünk a szerver beállításával, bármennyire is felvilágosítottuk magunkat a dokumentációval, minden alkalommal kaptunk egy kezdeti ügyfélkérést HTTPS-en keresztül érkezett URL-lel, és az IdentityServer ugyanazt a kontextust adta vissza, csak HTTP-vel. Megdöbbentünk! És mindezt az identitáskontextuson keresztül vittük át a HAProxy-ba, a fejlécekben pedig a HTTP protokollt kellett HTTPS-re módosítanunk.
Mi a javulás, és hol spóroltál?
Pénzt takarítottunk meg azzal, hogy egy ingyenes megoldást használtunk felhasználói csoportok, erőforrások engedélyezésére, mivel az IdentityServer4-et nem külön csomópontként helyeztük el külön szegmensben, hanem a háttérrel együtt használtuk ugyanazon a szerveren, ahol az alkalmazás háttérrendszere fut. .
Hogyan kell működnie
Szóval, ahogy ígértem - Magic Box. Már tudjuk, hogy garantáltan a Linux felé haladunk. Fogalmazzuk meg a konkrét megoldásokat igénylő feladatokat.
Bábos manifesztálódik. A szolgáltatás- és alkalmazáskonfiguráció szállításához és kezeléséhez klassz recepteket kellett írni. Egy tekercs ceruza ékesszólóan mutatja, milyen gyorsan és hatékonyan sikerült.
Szállítási mód. A szabvány az RPM. Mindenki megérti, hogy Linux alatt nem lehet nélküle, de maga a projekt az összeszerelés után egy futtatható DLL-fájlok halmaza volt. Körülbelül 150-en voltak, a projekt elég nehéz volt. Az egyetlen harmonikus megoldás, ha ezt a bináris fájlt RPM-be csomagoljuk, és onnan telepítjük az alkalmazást.
Verziószámítás. Nagyon gyakran kellett kiadnunk, és el kellett döntenünk, hogyan alakítsuk ki a csomag nevét. Ez a TFS-szel való integráció szintjének kérdése. Volt egy build ügynökünk Linuxon. Amikor a TFS egy feladatot küld egy kezelőnek - dolgozónak - a Build ügynöknek, akkor egy csomó változót is átad neki, amelyek a kezelőfolyamat környezetébe kerülnek. Ezek a környezeti változók tartalmazzák a Build nevét, a verzió nevét és egyéb változókat. Erről bővebben az „RPM-csomag készítése” részben olvashat.
A TFS beállítása leszállt a Pipeline felállítására. Korábban az összes Windows-projektet összegyűjtöttük Windows-ügynökökön, de most megjelenik egy Linux-ügynök - egy Build-ügynök, amelyet be kell vonni a build-csoportba, néhány műtermékkel gazdagítva, és megmondja, hogy milyen típusú projektek épülnek majd erre a Build-ügynökre. , és valahogy módosítsa a Pipeline-t.
IdentityServer. Az ADFS nem a mi utunk, mi a nyílt forráskódot választjuk.
Nézzük végig az összetevőket.
Magic Box
Négy részből áll.
Linux Build ügynök. Linux, mert mi erre építünk – ez logikus. Ez a rész három lépésben készült.
- Munkavállalók konfigurálása és nem egyedül, hiszen a projekten megosztott munka várható.
- Telepítse a .NET Core 1.x-et. Miért 1.x, ha a 2.0 már elérhető a szabványos tárolóban? Ugyanis amikor elkezdtük a fejlesztést, a stabil verzió 1.09 volt, és úgy döntöttek, hogy ez alapján készítik el a projektet.
- Git 2.x.
RPM-tár. Az RPM-csomagokat valahol tárolni kellett. Feltételeztük, hogy ugyanazt a vállalati RPM-tárat használjuk, amely az összes Linux-gazda számára elérhető. Ezt tették. A tárolókiszolgáló konfigurálva van webhorog amely letöltötte a szükséges RPM-csomagot a megadott helyről. A csomag verzióját a Build ügynök jelentette a webhooknak.
GitLab. Figyelem! A GitLabot itt nem a fejlesztők, hanem az üzemeltetési osztály használják az alkalmazások verzióinak, csomagverzióinak vezérlésére, az összes Linux-gép állapotának figyelésére, és tárolja a receptet - az összes Puppet manifestet.
Báb — megoldja az összes vitás kérdést, és pontosan azt a konfigurációt szállítja, amelyet szeretnénk a Gitlabtól.
Elkezdünk merülni. Hogyan működik a DLL kézbesítés az RPM-hez?
DDL szállítása RPM-ig
Tegyük fel, hogy van egy .NET fejlesztésű rocksztárunk. Visual Studio-t használ, és létrehoz egy kiadási ágat. Utána feltölti a Gitbe, és a Git itt egy TFS entitás, vagyis az az alkalmazástár, amellyel a fejlesztő dolgozik.
Ezután a TFS látja, hogy új commit érkezett. Melyik alkalmazás? A TFS-beállításokban van egy címke, amely jelzi, hogy egy adott Build-ügynök milyen erőforrásokkal rendelkezik. Ebben az esetben látja, hogy egy .NET Core projektet építünk, és kiválaszt egy Linux Build ügynököt a készletből.
A Build ügynök megkapja a forrásokat és letölti a szükségeseket függőségek a .NET tárolóból, npm stb. és magának az alkalmazásnak a felépítése és az azt követő csomagolás után elküldi az RPM-csomagot az RPM-tárba.
Másrészt a következő történik. Az üzemeltetési osztály mérnöke közvetlenül részt vesz a projekt bevezetésében: megváltoztatja a csomagok verzióit Hiera abban a tárolóban, ahol az alkalmazás receptje van tárolva, ami után a Puppet aktiválódik Yum, lekéri az új csomagot a tárolóból, és az alkalmazás új verziója használatra kész.
Szavakban minden egyszerű, de mi történik magában a Build ügynökben?
Csomagolás DLL RPM
Projektforrásokat és összeállítási feladatot kapott a TFS-től. Építőügynök elkezdi magát a projektet forrásokból felépíteni. Az összeszerelt projekt készletben kapható DLL fájlokat, amelyek a fájlrendszer terhelésének csökkentése érdekében zip-archívumba vannak csomagolva.
A ZIP archívumot kidobják az RPM-csomag összeállítási könyvtárába. Ezután a Bash parancsfájl inicializálja a környezeti változókat, megkeresi a Build verziót, a projekt verzióját, a build könyvtár elérési útját, és futtatja az RPM-build parancsot. A felépítés befejezése után a csomag közzétételre kerül helyi adattár, amely a Build ügynökön található.
Ezután a Build ügynöktől az RPM-lerakatban lévő kiszolgálóig JSON-kérés elküldve jelzi a verzió és a build nevét. A Webhook, amelyről korábban beszéltem, éppen ezt a csomagot tölti le a Build ügynök helyi tárolójából, és elérhetővé teszi az új összeállítást a telepítéshez.
Miért ez az adott csomagküldési séma az RPM-tárba? Miért nem tudom azonnal elküldeni az összeállított csomagot a tárolóba? A helyzet az, hogy ez a feltétele a biztonság biztosításának. Ez a forgatókönyv korlátozza annak lehetőségét, hogy illetéktelenek RPM-csomagokat töltsenek fel egy olyan kiszolgálóra, amely minden Linux-gép számára elérhető.
Adatbázis verziószámítás
A fejlesztőcsapattal történt egyeztetésen kiderült, hogy a srácok közelebb állnak az MS SQL-hez, de a legtöbb nem Windows-os projektben már minden erővel PostgreSQL-t használtunk. Mivel már úgy döntöttünk, hogy lemondunk minden fizetősről, itt is elkezdtük használni a PostgreSQL-t.
Ebben a részben szeretném elmondani, hogyan verzióztuk az adatbázist, és hogyan választottunk a Flyway és az Entity Framework Core között. Nézzük ezek előnyeit és hátrányait.
Hátrányok
A Flyway csak egy irányba halad, mi nem tekerhetünk vissza - ez jelentős hátrány. Más módon is összehasonlíthatja az Entity Framework Core-al – a fejlesztői kényelem szempontjából. Emlékszel, hogy ezt helyeztük előtérbe, és a fő kritérium az volt, hogy semmit ne változtassunk a Windows-fejlesztésben.
A Flyway nekünk valamiféle burkolóanyag kelletthogy a srácok ne írjanak SQL lekérdezések. Sokkal közelebb állnak az OOP kifejezésekhez. Utasításokat írtunk az adatbázis-objektumokkal való munkához, generáltunk egy SQL lekérdezést és végrehajtottuk azt. Az adatbázis új verziója készen van, tesztelve - minden rendben van, minden működik.
Az Entity Framework Core-nek van egy mínusza – nagy terhelés esetén szuboptimális SQL lekérdezéseket készít, és az adatbázis lehívása jelentős lehet. De mivel nincs nagy terhelésű szolgáltatásunk, nem több száz RPS-ben számoljuk a terhelést, vállaltuk ezeket a kockázatokat, és ránk bíztuk a problémát.
Érvek
Entitás-keretrendszer mag a dobozból kivéve működik és könnyen fejleszthetőés Flyway Könnyen integrálható a meglévő CI-be. De a fejlesztők számára kényelmessé tesszük :)
Roll-up eljárás
A Puppet úgy látja, hogy változás jön a csomag verziójában, beleértve azt is, amelyik a migrációért felelős. Először is telepít egy csomagot, amely áttelepítési parancsfájlokat és adatbázissal kapcsolatos funkciókat tartalmaz. Ezt követően az adatbázissal működő alkalmazás újraindul. Ezután következik a többi komponens telepítése. A csomagok telepítésének és az alkalmazások indításának sorrendjét a Puppet jegyzék írja le.
Az alkalmazások érzékeny adatokat használnak, például tokeneket, adatbázis jelszavakat, mindezt a Puppet masterből húzzák be a konfigurációba, ahol titkosított formában tárolódnak.
TFS problémák
Miután eldöntöttük, és rájöttünk, hogy minden valóban működik nekünk, úgy döntöttem, hogy megnézem, mi történik a Win fejlesztői részlegének összességében a TFS-ben a szerelvényekkel más projektekben – akár gyorsan építünk/kiadunk, akár nem, és jelentős problémákat fedezett fel a sebességgel kapcsolatban.
Az egyik fő projekt összeszerelése 12-15 percet vesz igénybe – ez hosszú idő, nem lehet így élni. Egy gyors elemzés szörnyű leállást mutatott ki az I/O-ban, és ez a tömbökön volt.
A komponensenkénti elemzés után három gócot azonosítottam. Első - "Kaspersky vírusirtó", amely az összes Windows Build ügynök forrását vizsgálja. Második - Windows Indexelő. Nem volt letiltva, és mindent valós időben indexeltek a Build ügynökökön a telepítési folyamat során.
Harmadik - Npm telepítés. Kiderült, hogy a legtöbb Pipeline-nál pontosan ezt a forgatókönyvet alkalmaztuk. Miért rossz? Az Npm telepítési eljárás akkor fut le, amikor a függőségi fa létrejön package-lock.json, ahol rögzítésre kerülnek a projekt felépítéséhez használt csomagok verziói. Hátránya, hogy az Npm install minden alkalommal lekéri a csomagok legfrissebb verzióit az internetről, és ez nagy projektek esetén sok időt vesz igénybe.
A fejlesztők néha kísérleteznek egy helyi gépen, hogy teszteljék egy adott rész vagy teljes projekt működését. Néha kiderült, hogy helyben minden menő, de összerakták, kigurították, és semmi sem működött. Kezdjük kitalálni, mi a probléma – igen, a csomagok különböző verziói függőséggel.
döntés
- Források az AV kivételekben.
- Indexelés letiltása.
- Menj npm ci.
Az npm ci előnyei az, hogy mi Egyszer összegyűjtjük a függőségi fát, és lehetőséget kapunk arra, hogy a fejlesztőt biztosítsuk csomagok aktuális listája, amellyel helyben kedve szerint kísérletezhet. Ez időt spórol fejlesztők, akik kódot írnak.
Configuration
Most egy kicsit a tároló konfigurációjáról. Történelmileg mi használjuk összefüggés adattárak kezeléséhez, beleértve Belső REPO. Ez a belső repository tartalmazza az összes olyan összetevőt, amelyet belső célokra használunk, például az ön által írt monitorozáshoz.
Mi is használjuk NuGet, mivel a többi csomagkezelőhöz képest jobb a gyorsítótár.
Eredmény
A Build Agents optimalizálása után az átlagos összeállítási idő 12 percről 7-re csökkent.
Ha összeszámoljuk az összes gépet, amit használhattunk volna Windowshoz, de ebben a projektben Linuxra váltottunk, körülbelül 10 000 dollárt takarítottunk meg, és ez csak a licenceken van, és ha a tartalmat is figyelembe vesszük, még többet.
Tervek
A következő negyedévben azt terveztük, hogy optimalizáljuk a kódszolgáltatást.
Váltás előre elkészített Docker-képre. A TFS egy klassz dolog, sok olyan beépülő modullal, amelyek lehetővé teszik a Pipeline-ba való integrálást, beleértve például egy Docker-kép trigger-alapú összeállítását. Ezt a triggert ugyanarra szeretnénk beállítani package-lock.json. Ha a projekt felépítéséhez használt komponensek összetétele valahogy megváltozik, akkor új Docker-képet készítünk. Később a tároló telepítésére használják az összeállított alkalmazással. Ez most nem így van, de tervezzük az átállást a cégünkben aktívan fejlődő, termelési megoldásokat hosszú ideje kiszolgáló Kubernetesben a mikroszolgáltatási architektúrára.
Összegzés
Mindenkit arra biztatok, hogy dobja ki a Windowst, de nem azért, mert nem tudom, hogyan kell megfőzni. Ennek az az oka, hogy a legtöbb nyílt forráskódú megoldás igen Linux verem. jól vagy spórolni az erőforrásokon. Véleményem szerint a jövő a nyílt forráskódú Linux-megoldásoké, erős közösséggel.
Alexander Sinchinov előadói profilja .
konferencia a fejlesztési, tesztelési és üzemeltetési folyamatok szakemberek általi integrációjáról. Ezért van az a projekt, amelyről Alexander beszélt? megvalósult és működik, és az előadás napján két sikeres kiadás is volt. Tovább Május 27-én és 28-án még több hasonló eset lesz a gyakorló orvosoktól. Még beugorhat az utolsó hintóba és vagy szánjon rá időt jegy. Találkozzunk Szkolkovóban!
Forrás: will.com