Javaslom, hogy olvassák el Alexander Sigachev, az Inventos "Fejlesztési és tesztelési folyamata Docker + Gitlab CI-vel" című jelentésének átiratát.
Azok, akik most kezdik a Docker + Gitlab CI-re épülő fejlesztési és tesztelési folyamat bevezetését, gyakran tesznek fel alapvető kérdéseket. Hol kezdjem? Hogyan kell megszervezni? Hogyan kell tesztelni?
Ez a jelentés jó, mert strukturált módon beszél a fejlesztési és tesztelési folyamatról a Docker és a Gitlab CI használatával. Maga a jelentés 2017-ből származik. Szerintem ebből a beszámolóból megtudhatod a használat alapjait, módszertanát, ötletét, tapasztalatait.
Akit érdekel, kérem a macska alá.
A nevem Alekszandr Szigacsov. Az Inventosnál dolgozom. Mesélek a Docker használatával kapcsolatos tapasztalataimról, és arról, hogy hogyan alkalmazzuk fokozatosan a vállalat projektjein.
Az előadás témája: Fejlesztési folyamat Docker és Gitlab CI használatával.
Ez a második előadásom a Dockerről. Az első jelentés idején csak a Docker in Development alkalmazást használtuk fejlesztői gépeken. A Dockert használó alkalmazottak száma körülbelül 2-3 fő volt. Fokozatosan gyűltek a tapasztalatok, és egy kicsit előrébb léptünk. Link a mi oldalunkra .
Mi lesz ebben a jelentésben? Megosztjuk tapasztalatainkat, hogy milyen gereblyét gyűjtöttünk, milyen problémákat oldottunk meg. Nem mindenhol volt szép, de engedték továbblépni.
Mottónk: dokkoljunk le mindent, ami a kezünkbe kerül.
Milyen problémákat oldunk meg?
Ha több csapat van egy vállalaton belül, a programozó megosztott erőforrás. Vannak olyan szakaszok, amikor egy programozót kihúznak az egyik projektből, és egy időre átadják egy másik projektnek.
Ahhoz, hogy a programozó gyorsan megértse, le kell töltenie a projekt forráskódját, és a lehető leghamarabb el kell indítania a környezetet, amely lehetővé teszi számára, hogy továbblépjen a projekt problémáinak megoldásában.
Általában, ha a nulláról kezdi, akkor kevés a dokumentáció a projektben. A beállítással kapcsolatos információk csak a régiek számára állnak rendelkezésre. A dolgozók egy-két nap alatt önállóan alakítják ki munkahelyüket. Ennek felgyorsítására Dockert használtunk.
A következő ok a fejlesztési beállítások szabványosítása. Tapasztalatom szerint mindig a fejlesztők kezdeményeznek. Minden ötödik esetben egyéni domain kerül megadásra, például vasya.dev. Mellette ül a szomszédja, Petya, akinek a domain a petya.dev. Ezzel a domain névvel weboldalt vagy a rendszer valamely összetevőjét fejlesztik.
Amikor a rendszer növekszik, és ezek a tartománynevek elkezdenek bekerülni a konfigurációkba, fejlesztői környezeti konfliktus keletkezik, és a webhely elérési útja átíródik.
Ugyanez történik az adatbázis-beállításokkal is. Valaki nem törődik a biztonsággal, és üres root jelszóval dolgozik. A telepítés során a MySQL jelszót kért valakitől, és kiderült, hogy a jelszó 123. Gyakran előfordul, hogy az adatbázis konfigurációja folyamatosan változik a fejlesztő commit függvényében. Valaki javította, valaki nem javította a konfigurációt. Voltak trükkök, amikor kivettünk valami tesztkonfigurációt .gitignore és minden fejlesztőnek telepítenie kellett az adatbázist. Ez megnehezítette az indulást. Emlékezni kell többek között az adatbázisra is. Az adatbázist inicializálni kell, jelszót kell megadni, felhasználót kell regisztrálni, táblát kell létrehozni stb.
Egy másik probléma a könyvtárak különböző verziói. Gyakran előfordul, hogy egy fejlesztő különböző projektekkel dolgozik. Van egy Legacy projekt, ami öt éve indult (2017-től – a szerk. megjegyzése). Az induláskor a MySQL 5.5-tel kezdtük. Vannak olyan modern projektek is, ahol a MySQL modernebb verzióit próbáljuk megvalósítani, például 5.7 vagy régebbi (2017-ben - a szerk. megjegyzése)
Bárki, aki MySQL-lel dolgozik, tudja, hogy ezek a könyvtárak függőséget hoznak magukkal. Elég problémás 2 bázist együtt futtatni. Legalábbis a régi kliensek nehezen tudnak csatlakozni az új adatbázishoz. Ez viszont számos problémát okoz.
A következő probléma az, amikor egy fejlesztő helyi gépen dolgozik, helyi erőforrásokat, helyi fájlokat, helyi RAM-ot használ. A problémák megoldásának kidolgozásakor minden interakció azon a tényen belül történik, hogy egy gépen működik. Példa erre, amikor a Production 3-ban háttérkiszolgálóink vannak, és a fejlesztő a fájlokat a gyökérkönyvtárba menti, és onnan az nginx fájlokat vesz fel, hogy válaszoljon a kérésre. Amikor egy ilyen kód bekerül a termelésbe, kiderül, hogy a fájl jelen van a 3 szerver egyikén.
A mikroszolgáltatások iránya most fejlődik. Amikor a nagy alkalmazásainkat néhány kis komponensre osztjuk, amelyek kölcsönhatásba lépnek egymással. Ez lehetővé teszi a technológiák kiválasztását egy adott feladatköteghez. Lehetővé teszi továbbá a munka és a felelősség megosztását a fejlesztők között.
A JS-en fejlesztő Frondend-fejlesztőnek szinte nincs befolyása a Backendre. A háttérfejlesztő viszont a mi esetünkben a Ruby on Rails-t fejleszti, és nem zavarja a Frondendot. Az interakció az API segítségével történik.
Bónuszként a Docker segítségével újrahasznosíthattuk a Staging erőforrásait. Minden projekt sajátosságaiból adódóan bizonyos beállításokat igényelt. Fizikailag vagy egy virtuális szervert kellett lefoglalni és külön konfigurálni, vagy valamilyen változó környezet megosztására volt szükség, és a projektek a könyvtárak verziójától függően befolyásolhatják egymást.
Eszközök. Mit használunk?
- Maga a Docker. A Dockerfile egyetlen alkalmazás függőségeit írja le.
- A Docker-compose egy csomag, amely egyesíti néhány Docker-alkalmazásunkat.
- A forráskód tárolására GitLabot használunk.
- A rendszerintegrációhoz GitLab-CI-t használunk.
A jelentés két részből áll.
Az első részben arról lesz szó, hogyan futott a Docker a fejlesztők gépein.
A második rész arról fog szólni, hogyan kommunikáljunk a GitLabbal, hogyan futtassunk teszteket, és hogyan lépjünk át a Staging-be.
A Docker egy olyan technológia, amely lehetővé teszi (deklaratív megközelítéssel) a szükséges összetevők leírását. Ez egy példa a Dockerfile-ra. Itt kijelentjük, hogy a hivatalos Ruby:2.3.0 Docker képből örököljük. A Ruby 2.3-as verzióját tartalmazza. Telepítjük a szükséges build könyvtárakat és a NodeJS-t. Leírjuk, hogy létrehozunk egy könyvtárat /app. Állítsa be az alkalmazáskönyvtárat munkakönyvtárként. Ebben a könyvtárban helyezzük el a szükséges minimális Gemfile-t és Gemfile.lock-ot. Ezután elkészítjük azokat a projekteket, amelyek telepítik ezt a függőségi lemezképet. Jelezzük, hogy a tároló készen áll a figyelésre a 3000-es külső porton. Az utolsó parancs az alkalmazásunkat közvetlenül elindító parancs. Ha végrehajtjuk a projektindítási parancsot, az alkalmazás megpróbálja lefuttatni és futtatni a megadott parancsot.
Ez egy minimális példa a docker-compose fájlra. Ebben az esetben megmutatjuk, hogy két konténer között van kapcsolat. Ez közvetlenül az adatbázis-szolgáltatásba és a webszolgáltatásba kerül. Webes alkalmazásaink a legtöbb esetben valamilyen adatbázist igényelnek háttérként az adatok tárolására. Mivel MySQL-t használunk, a példa a MySQL-re vonatkozik, de semmi sem akadályozza meg, hogy más adatbázist (PostgreSQL, Redis) használjunk.
A hivatalos forrásból a Docker hubból vesszük át a MySQL 5.7.14 képét változtatás nélkül. A webalkalmazásunkért felelős képet az aktuális könyvtárból gyűjtjük. Az első indításkor képet gyűjt nekünk. Ezután lefuttatja az itt végrehajtott parancsot. Ha visszamegyünk, látni fogjuk, hogy a Puma-n keresztüli indítási parancs definiálva van. A Puma egy Ruby nyelven írt szolgáltatás. A második esetben felülírjuk. Ez a parancs tetszőleges lehet igényeinktől vagy feladatainktól függően.
Azt is leírjuk, hogy a fejlesztői gazdagépünkön egy portot kell továbbítanunk 3000-ről 3000-re a konténerporton. Ez automatikusan megtörténik az iptables és annak mechanizmusa segítségével, amely közvetlenül be van ágyazva a Dockerbe.
A fejlesztő a korábbiakhoz hasonlóan hozzáférhet bármely elérhető IP-címhez, például a 127.0.0.1 a gép helyi vagy külső IP-címe.
Az utolsó sor azt mondja, hogy a webtároló a db tárolótól függ. Amikor meghívjuk a webtároló kezdetét, a docker-compose először elindítja helyettünk az adatbázist. Már az adatbázis indulásakor (sőt, a konténer elindítása után! Ez nem garantálja az adatbázis készenlétét) elindul az alkalmazás, a háttérrendszerünk.
Ez elkerüli a hibákat, amikor az adatbázis nem jelenik meg, és erőforrásokat takarít meg, amikor leállítjuk az adatbázis-tárolót, így erőforrásokat szabadít fel más projektek számára.
Mi biztosítja számunkra az adatbázis-dokkolás használatát a projektben. Javítjuk a MySQL verzióját minden fejlesztő számára. Ezzel elkerülhető néhány hiba, amely akkor fordulhat elő, ha a verziók eltérnek, amikor a szintaxis, a konfiguráció és az alapértelmezett beállítások megváltoznak. Ez lehetővé teszi, hogy megadjon egy közös hosztnevet az adatbázishoz, bejelentkezési nevet és jelszót. Eltávolodunk a nevek és konfliktusok állatkertétől a konfigurációs fájlokban, amelyek korábban voltak.
Lehetőségünk van egy optimálisabb konfigurációt használni a Fejlesztői környezethez, amely eltér az alapértelmezetttől. A MySQL alapértelmezés szerint gyenge gépekhez van konfigurálva, és a teljesítménye nagyon gyenge.
A Docker lehetővé teszi a kívánt verzió Python, Ruby, NodeJS, PHP értelmezőjének használatát. Megszabadulunk attól, hogy valamilyen verziókezelőt használjunk. Korábban a Ruby egy rpm csomagot használt, amely lehetővé tette a verzió módosítását a projekttől függően. A Docker-tárolónak köszönhetően lehetővé teszi a kód zökkenőmentes áttelepítését és a függőségekkel együtt történő verziózását is. Nem okoz gondot megérteni az értelmező és a kód verzióját. A verzió frissítéséhez engedje le a régi tárolót, majd emelje fel az új tárolót. Ha valami elromlott, leengedhetjük az új konténert, megemelhetjük a régit.
Az arculat felépítése után a konténerek a fejlesztésben és a gyártásban is ugyanazok lesznek. Ez különösen igaz a nagy telepítésekre.
A Frontenden JavaScipt-et és NodeJS-t használunk.
Most megvan az utolsó projekt a ReacJS-en. A fejlesztő mindent futtatott a tárolóban, és hot-reload segítségével fejlesztette.
Ezután elindul a JavaScipt összeállítási feladat, és az nginx mentési erőforrásokon keresztül megkapja a statikába fordított kódot.
Itt adtam meg legutóbbi projektünk sémáját.
Milyen feladatokat oldottak meg? Szükségünk volt egy olyan rendszer kiépítésére, amellyel a mobil eszközök együttműködnek. Adatokat kapnak. Az egyik lehetőség push értesítések küldése erre az eszközre.
Mit tettünk ennek érdekében?
Az alkalmazásba olyan komponenseket osztottunk, mint: a JS rendszergazdai része, a backend, amely a REST felületen keresztül működik Ruby on Rails alatt. A háttérrendszer kölcsönhatásba lép az adatbázissal. A kapott eredményt megkapja az ügyfél. Az adminisztrációs panel a REST felületen keresztül kommunikál a háttérrel és az adatbázissal.
Szükségünk volt push értesítések küldésére is. Ezt megelőzően volt egy projektünk, amely egy olyan mechanizmust vezetett be, amely az értesítések mobilplatformokra való eljuttatásáért felelős.
A következő sémát dolgoztuk ki: a böngésző operátora interakcióba lép az adminisztrációs panellel, az adminisztrációs panel a háttérrel, a feladat Push értesítések küldése.
A push értesítések kölcsönhatásba lépnek a NodeJS-ben megvalósított másik összetevővel.
Várólisták épülnek fel, majd az értesítéseket a rendszerüknek megfelelően küldik el.
Itt két adatbázis készült. Jelenleg a Docker segítségével 2 független, egymással semmilyen kapcsolatban nem álló adatbázist használunk. Ezen kívül közös virtuális hálózatuk van, a fizikai adatokat a fejlesztő gépén különböző könyvtárakban tárolják.
Ugyanaz, de számokban. Itt fontos a kód újrafelhasználása.
Ha korábban a kódok könyvtárak formájában történő újrafelhasználásáról beszéltünk, akkor ebben a példában a Push értesítésekre válaszoló szolgáltatásunkat teljes szerverként használjuk újra. API-t biztosít. Az új fejlesztésünk pedig már kölcsönhatásban van vele.
Akkoriban a NodeJS 4-es verzióját használtuk. Most (2017-ben - a szerk. megjegyzése) a legújabb fejlesztésekben a NodeJS 7-es verzióját használjuk. Az új komponensekkel nem jelent gondot a könyvtárak új verzióinak bevonása.
Ha szükséges, a NodeJS-verziót a Push értesítési szolgáltatásból újraaktiválhatja és emelheti.
Ha pedig fenn tudjuk tartani az API-kompatibilitást, akkor azt más, korábban használt projektekkel is le tudjuk majd cserélni.
Mi kell hozzá a Dockerhez? Hozzáadunk egy Dockerfile-t a tárhelyünkhöz, amely leírja a szükséges függőségeket. Ebben a példában az összetevők logikailag vannak lebontva. Ez a háttérfejlesztő minimális készlete.
Új projekt létrehozásakor létrehozunk egy Dockerfile-t, leírjuk a kívánt ökoszisztémát (Python, Ruby, NodeJS). A docker-compose programban leírja a szükséges függőséget - az adatbázist. Leírjuk, hogy kell egy ilyen-olyan verziójú adatbázis, tároljunk ott-ott adatokat.
A statikus kiszolgáláshoz egy külön harmadik tárolót használunk nginx-szel. Lehetőség van képek feltöltésére. A Backend egy előre elkészített kötetbe teszi őket, ami szintén egy konténerbe van szerelve nginx-szel, ami a statikusságot adja.
Az nginx, mysql konfiguráció tárolásához hozzáadtunk egy Docker mappát, amelyben tároljuk a szükséges konfigurációkat. Amikor egy fejlesztő git klónt készít egy adattárról a gépén, már van egy projektje, amely készen áll a helyi fejlesztésre. Nem kérdés, hogy milyen portot vagy milyen beállításokat kell alkalmazni.
Ezután több összetevőnk van: admin, inform-API, push értesítések.
Mindezek elindítása érdekében létrehoztunk egy másik tárolót, amelyet dockerized-app-nak neveztünk el. Jelenleg több tárolót használunk minden egyes komponens előtt. Csak logikailag különböznek egymástól – a GitLabban úgy néz ki, mint egy mappa, de a fejlesztő gépén egy adott projekt mappája. Egy szinttel lejjebb vannak az egyesítendő összetevők.
Ez egy példa csak a dockerized-app tartalmára. Ide hozzuk a Docker könyvtárat is, amelyben minden komponens interakciójához szükséges konfigurációkat kitöltjük. Van egy README.md, amely röviden leírja a projekt futtatását.
Itt két docker-compose fájlt alkalmaztunk. Ez azért történik, hogy lépésekben tudjon futni. Amikor a fejlesztő a maggal dolgozik, nincs szüksége push értesítésekre, egyszerűen elindít egy docker-compose fájlt, és ennek megfelelően az erőforrás mentésre kerül.
Ha szükség van a push értesítésekkel való integrációra, akkor a docker-compose.yaml és a docker-compose-push.yaml elindul.
Mivel a docker-compose.yaml és a docker-compose-push.yaml egy mappában található, a rendszer automatikusan egyetlen virtuális hálózatot hoz létre.
Az összetevők leírása. Ez egy fejlettebb fájl, amely az összetevők gyűjtéséért felelős. Mi a figyelemre méltó itt? Itt bemutatjuk a kiegyenlítő komponenst.
Ez egy kész Docker-kép, amely az nginx-et és egy olyan alkalmazást futtat, amely a Docker socketen figyel. Dinamikus, mivel a konténereket be- és kikapcsolják, újragenerálja az nginx konfigurációt. A komponensek kezelését harmadik szintű domain nevekkel osztjuk meg.
A fejlesztői környezethez a .dev tartományt használjuk – api.informer.dev. A .dev domainnel rendelkező alkalmazások elérhetők a fejlesztő helyi gépén.
Továbbá a konfigurációk átvitelre kerülnek minden projektbe, és az összes projekt egyszerre indul el.
Grafikusan kiderül, hogy a kliens a mi böngészőnk vagy valamilyen eszköz, amellyel kéréseket intézünk az egyensúlyozó felé.
A tartománynév-kiegyenlítő határozza meg, hogy melyik tárolóhoz kell fordulni.
Lehet nginx, ami az admin JS-t ad. Ez lehet az nginx, amely az API-t adja, vagy a statikus fájlok, amelyeket képfeltöltés formájában kap az nginx.
Az ábra azt mutatja, hogy a konténereket egy virtuális hálózat köti össze, és egy proxy mögé rejtve vannak.
A fejlesztő gépén az IP ismeretében lehet hozzáférni a konténerhez, de elvileg ezt nem használjuk. Gyakorlatilag nincs szükség közvetlen hozzáférésre.
Melyik példát érdemes megnézni az alkalmazás dockerizálásához? Véleményem szerint jó példa erre a MySQL hivatalos docker-képe.
Ez elég nagy kihívás. Sok változat létezik. De funkcionalitása lehetővé teszi számos olyan igény kielégítését, amelyek a további fejlesztés során felmerülhetnek. Ha időt szánsz és rájössz, hogy mindez hogyan hat egymásra, akkor szerintem nem lesz gondod az önmegvalósítással.
A Hub.docker.com általában a github.com webhelyre mutató hivatkozásokat tartalmaz, amelyek nyers adatokat tartalmaznak, amelyekből közvetlenül összeállíthatja a képet.
Továbbá ebben a tárolóban található egy docker-endpoint.sh szkript, amely a kezdeti inicializálásért és az alkalmazás indításának további feldolgozásáért felelős.
Ebben a példában is lehetőség van környezeti változók használatával történő konfigurálásra. Egy környezeti változó definiálásával egyetlen tároló futtatásakor vagy a docker-compose segítségével azt mondhatjuk, hogy be kell állítanunk egy üres jelszót, hogy a docker rootolhasson a MySQL-en vagy bármi máson.
Lehetőség van véletlenszerű jelszó létrehozására. Azt mondjuk, hogy szükségünk van egy felhasználóra, be kell állítanunk egy jelszót a felhasználó számára, és létre kell hoznunk egy adatbázist.
Projektjeinkben kissé egységesítettük az inicializálásért felelős Dockerfile-t. Ott kijavítottuk az igényeinknek megfelelően, hogy csak az alkalmazás által használt felhasználói jogok kiterjesztése legyen. Ez lehetővé tette számunkra, hogy a későbbiekben egyszerűen létrehozzunk egy adatbázist az alkalmazáskonzolból. A Ruby alkalmazásoknak van parancsa adatbázisok létrehozására, módosítására és törlésére.
Ez egy példa arra, hogyan néz ki a MySQL egy adott verziója a github.com webhelyen. Megnyithatja a Dockerfile-t, és megnézheti, hogyan folyik ott a telepítés.
A docker-endpoint.sh a belépési pontért felelős szkript. A kezdeti inicializálás során néhány előkészítő lépésre van szükség, és ezek a műveletek csak az inicializálási parancsfájlban kerülnek végrehajtásra.
Térjünk át a második részre.
A forráskódok tárolására a gitlab-ra váltottunk. Ez egy meglehetősen erős rendszer, amely vizuális felülettel rendelkezik.
A Gitlab egyik összetevője a Gitlab CI. Lehetővé teszi egy parancssorozat leírását, amelyet később a kódküldő rendszer megszervezéséhez vagy az automatikus tesztelés futtatásához használnak fel.
Gitlab CI 2 beszélgetés - riport a Ruby Russia klubtól - elég részletes, és talán érdekelni fogja.
Most megnézzük, mi szükséges a Gitlab CI aktiválásához. A Gitlab CI elindításához csak el kell helyeznünk a .gitlab-ci.yml fájlt a projekt gyökerébe.
Itt leírjuk, hogy egy állapotsorozatot szeretnénk végrehajtani, például egy tesztet, telepítést.
Olyan szkripteket hajtunk végre, amelyek közvetlenül hívják a docker-compose-t az alkalmazás elkészítéséhez. Ez csak egy háttér példa.
Ezt követően azt mondjuk, hogy az adatbázis módosításához és a tesztek futtatásához migrációt kell futtatni.
Ha a parancsfájlok megfelelően futnak, és nem adnak vissza hibakódot, akkor a rendszer a telepítés második szakaszába lép.
A telepítési szakasz jelenleg szakaszolásra van megvalósítva. Nem szerveztünk leállás nélküli újraindítást.
Minden edényt erőszakkal eloltunk, majd a tesztelés során az első szakaszban összegyűjtött edényeket ismét felemeljük.
Az aktuális környezeti változóra a fejlesztők által írt adatbázis-áttelepítéseket futtatjuk.
Van egy megjegyzés, hogy ez csak a fő ágra vonatkozik.
Más ágak megváltoztatásakor nem hajtódik végre.
Lehetőség van a kihelyezések fiókonkénti megszervezésére.
Ennek továbbszervezéséhez telepítenünk kell a Gitlab Runner-t.
Ez a segédprogram Golang nyelven íródott. Ez egy egyetlen fájl, ahogy az a Golang világban megszokott, és nem igényel semmilyen függőséget.
Indításkor regisztráljuk a Gitlab Runnert.
A kulcsot a Gitlab webes felületén kapjuk meg.
Ezután a parancssorban meghívjuk az inicializálási parancsot.
A Gitlab Runner interaktív beállítása (Shell, Docker, VirtualBox, SSH)
A Gitlab Runner kódja minden véglegesítéskor lefut, a .gitlab-ci.yml beállítástól függően.
Hogyan néz ki vizuálisan a Gitlabban a webes felületen. Miután csatlakoztattuk a GItlab CI-t, van egy jelzőnk, amely a build pillanatnyi állapotát mutatja.
Látjuk, hogy 4 perce történt egy commit, ami minden teszten megfelelt és nem okozott gondot.
Megnézhetjük közelebbről az építményeket. Itt azt látjuk, hogy két állapot már elmúlt. Tesztelési állapot és üzembe helyezés állapota szakaszoláskor.
Ha rákattintunk egy adott buildre, akkor a folyamatban lefutott parancsok konzol kimenete lesz a .gitlab-ci.yml szerint.
Így néz ki terméktörténetünk. Úgy látjuk, voltak sikeres próbálkozások. A tesztek benyújtásakor nem lép tovább a következő lépésre, és az állomáskód nem frissül.
Milyen feladatokat oldottunk meg a színpadon a docker bevezetésekor? Rendszerünk komponensekből áll, és újra kellett indítanunk, csak a tárolóban frissített összetevők egy részét, és nem a teljes rendszert.
Ehhez mindent külön mappákba kellett összetörnünk.
Miután ezt megtettük, azzal a ténnyel volt gondunk, hogy a Docker-compose minden apának saját hálózati teret hoz létre, és nem látja a szomszéd összetevőit.
Az átjárás érdekében manuálisan hoztuk létre a hálózatot a Dockerben. Docker-compose-ban írták, hogy ilyen hálózatot használsz ehhez a projekthez.
Így minden egyes komponens, amely ezzel a hálóval kezdődik, a rendszer más részeiben lévő alkatrészeket látja.
A következő probléma a szakaszosítás több projektre való felosztása.
Mivel ahhoz, hogy mindez gyönyörűen és a termeléshez minél közelebb kerüljön, célszerű a WEB-en mindenhol használt 80-as vagy 443-as portot használni.
Hogyan oldottuk meg? Minden nagyobb projekthez egy Gitlab Runner-t rendeltünk.
A Gitlab lehetővé teszi több elosztott Gitlab Runner futtatását, amelyek egyszerűen kaotikus módon veszik sorra az összes feladatot, és futtatják azokat.
Hogy ne legyen házunk, projektjeink csoportját egy Gitlab Runnerre korlátoztuk, amely gond nélkül megbirkózik a köteteinkkel.
Az nginx-proxyt egy külön indító szkriptbe helyeztük át, és rácsokat adtunk hozzá az összes projekthez.
Projektünknek egy gridje van, a kiegyenlítőnek pedig több projektnevű gridje van. Tovább tud proxyzni domain nevek alapján.
Kérelmeink a 80-as port tartományán keresztül érkeznek, és egy tárolócsoportba kerülnek feloldásra, amely ezt a tartományt szolgálja ki.
Milyen egyéb problémák voltak? Ez az, amit minden tároló alapértelmezés szerint rootként futtat. Ez a gyökér nem egyenlő a rendszer gyökérgazdájával.
Ha azonban megadja a tárolót, az root lesz, és az ebben a tárolóban létrehozott fájl root jogokat kap.
Ha a fejlesztő belépett a tárolóba, és végrehajtott néhány parancsot, amelyek fájlokat generálnak, majd elhagyták a tárolót, akkor van egy fájl a munkakönyvtárában, amelyhez nem fér hozzá.
Hogyan lehet megoldani? Hozzáadhat felhasználókat, akik a tárolóban lesznek.
Milyen problémák merültek fel a felhasználó hozzáadásakor?
A felhasználó létrehozásakor gyakran nem ugyanazt a csoportazonosítót (UID) és felhasználói azonosítót (GID) használjuk.
A probléma megoldásához a tárolóban 1000-es azonosítójú felhasználókat használunk.
Esetünkben ez egybeesett azzal, hogy szinte minden fejlesztő az Ubuntu operációs rendszert használja. Ubuntuban pedig az első felhasználó azonosítója 1000.
Vannak terveink?
Olvassa el a Docker dokumentációját. A projekt aktívan fejlődik, a dokumentáció változik. A két-három hónapja beérkezett adatok már lassan elavultak.
Az általunk megoldott problémák egy része valószínűleg már szabványos eszközökkel megoldott.
Így már tovább akarok menni, hogy közvetlenül a hangszerelésre menjek.
Az egyik példa a Docker beépített Docker Swarm mechanizmusa, amely a dobozból kerül ki. Valamit a Docker Swarm technológián alapuló termelésben szeretnék futtatni.
Az ívási konténerek kényelmetlenné teszik a rönkökkel való munkát. Most a naplók elszigeteltek. Konténerekben szétszórva vannak. Az egyik feladat a naplók kényelmes elérése a webes felületen keresztül.
Forrás: will.com