Docker-el hogy megy a build & deploy?
Érdekelne, hogy mi a best practice, ha docker container-ben szeretném futtatni az alkalmazásom. Több kérdésem is van.
- Érdemes ugyanabba a container-be tenni az adatbázist szervert, mint az alkalmazást? Abból indulok ki, hogy a docker-nek az a lényege, hogyha elszáll egy container-rel egy alkalmazás, az nem zavarja a többit, és ugyanúgy futnak tovább. Ebből gondoltam, hogy nem jó, ha közös adatbázis szerver van, mert ha az elszáll, akkor magával rántja az összes alkalmazást. Arra gondoltam helyette, hogy minden alkalmazás kapjon dedikált szervert. Ebből meg már következett, hogy talán jó, ha minden alkalmazás kap egy container-t, aztán abba megy minden ilyen infrastruktúrális dolog is. Jól gondolom?
- Hogyan megy a tesztelés? Addig eljutottam, hogy a sebesség érdekében a fejlesztői gépen érdemes a unit meg integrációs tesztek egy részét lefuttatni, mielőtt az éles környezetre hasonlító container-ben tesztelném. Arra gondoltam, hogy minden commit előtt érdemes egy ilyen container-ben történő, valamivel lassabb teszt. Nem teljesen világos, hogy hogyan rakjam össze az image-t, ami az ilyen teszteket végzi majd.
- Az sem teljesen világos, hogy a tesztelés után hogyan kerül majd az éles környezetre a jól működő build-elt kód anélkül, hogy az éles környezetben lévő adatok elvesznének. Tippre le kell állítani az éles rendszer előző verzióját, megtartani a volume-t, ami az adatokat tárolja, backup-olni a volume-t, aztán elindítani az új verzió image-ét, és csekkolni, hogy minden okés e. Ez elég időigényes. Nekem mondjuk nem gond saját célra készülő alkalmazásoknál, de azért érdekel, hogy olyan környezetben mindez hogy zajlik, amiben nem lehet hosszabb megállás.
Jó lenne néhány támpont ezzel kapcsolatban. Egyelőre nagyon kezdő vagyok docker-ezésben. Ezek az elméleti kérdések érdekelnek, a gyakorlatban meg tudom valósítani a dokumentáció végignyálazásával.
■ - Érdemes ugyanabba a container-be tenni az adatbázist szervert, mint az alkalmazást? Abból indulok ki, hogy a docker-nek az a lényege, hogyha elszáll egy container-rel egy alkalmazás, az nem zavarja a többit, és ugyanúgy futnak tovább. Ebből gondoltam, hogy nem jó, ha közös adatbázis szerver van, mert ha az elszáll, akkor magával rántja az összes alkalmazást. Arra gondoltam helyette, hogy minden alkalmazás kapjon dedikált szervert. Ebből meg már következett, hogy talán jó, ha minden alkalmazás kap egy container-t, aztán abba megy minden ilyen infrastruktúrális dolog is. Jól gondolom?
- Hogyan megy a tesztelés? Addig eljutottam, hogy a sebesség érdekében a fejlesztői gépen érdemes a unit meg integrációs tesztek egy részét lefuttatni, mielőtt az éles környezetre hasonlító container-ben tesztelném. Arra gondoltam, hogy minden commit előtt érdemes egy ilyen container-ben történő, valamivel lassabb teszt. Nem teljesen világos, hogy hogyan rakjam össze az image-t, ami az ilyen teszteket végzi majd.
- Az sem teljesen világos, hogy a tesztelés után hogyan kerül majd az éles környezetre a jól működő build-elt kód anélkül, hogy az éles környezetben lévő adatok elvesznének. Tippre le kell állítani az éles rendszer előző verzióját, megtartani a volume-t, ami az adatokat tárolja, backup-olni a volume-t, aztán elindítani az új verzió image-ét, és csekkolni, hogy minden okés e. Ez elég időigényes. Nekem mondjuk nem gond saját célra készülő alkalmazásoknál, de azért érdekel, hogy olyan környezetben mindez hogy zajlik, amiben nem lehet hosszabb megállás.
Jó lenne néhány támpont ezzel kapcsolatban. Egyelőre nagyon kezdő vagyok docker-ezésben. Ezek az elméleti kérdések érdekelnek, a gyakorlatban meg tudom valósítani a dokumentáció végignyálazásával.
Ökölszabály: minden logikai
A tesztelés ugyanúgy zajlik, mint máskor, jó esetben ezt a CI szerver végzi. Fejlesztőként szerintem nem érdemes integrációs teszteket futtatni (mivel többnyire túl hosszadalmas).
Ha jól csinálod, akkor eleve stateless a service (nyilván az adatbázis nem, de azt meg azért nem deployolod minden nap), és nincs mit backupolni. Persze ha feltétel a HA, akkor amúgy is több instance-ban fut a service (de biztos van előtte valamilyen proxy), ilyenkor elindítod az új verziót, elkezded fokozatosan felé irányítani a kéréseket, ha pedig a régihez már nem mennek, akkor azt le tudod állítani.
A több instance-nél még
Máshol is azt olvasom, hogy a
Létezik még ilyen, hogy docker in docker, amivel össze lehetne fogni, hogy az összetartozó szolgáltatások egyszerre induljanak, stb., de elég instabilnak tűnt az írások alapján. Gondolom helyette a csoportosítás valami prefix-es megoldással működhet, esetleg van egy külön container locator a service locator mintájára, ami összehangolja több szolgáltatás működését. Ezt csak így vakon mondom, gondolom majd ez is kiderül.
Esetleg pingeld meg pp-t,
Saját tapasztalatok: -
- Adatbázis szervert NE rakj konténerbe. A Docker előnye abban rejtőzik, hogy az alkalmazásodat egy konténerbe pakolva tudod szállítani annak a futtatókörnyezetével együtt. Ha így nézzük, az adatbázis szerver nem tartozik az alkalmazásod környezetéhez, az egy külső szolgáltatás amit az alkalmazásod használ, teljesen felesleges konténerben szállítani, csak a performanciát rontod és a komplexitást növeled.
- A tesztelést jól látod, mehet a fejlesztői gépen, felesleges konténerben tesztelni.
- A harmadik pontnál visszakanyarodnék az elsőhöz, a konténerbe stateless alkalmazások kerüljenek a futtatókörnyezetével együtt, adatbázis szerver, storage szolgáltatás, stb mind "külső" szolgáltatásként kezelendők, tedd fel magadnak a kérdést: látod valamilyen előnyét is annak, hogy ezeket konténerbe pakolod? Minden egyes alkalommal akarsz adatbázis szervert is deployolni?
Én két lehetőséget
a.) ahogy írod külön szolgáltatásba teszem az adatbázist.
b.) az adatbázist run-al telepítem, így kesselve lesz, az adatok meg megmaradnak, mert volume-ra mennek. az alkalmazást cmd-vel telepítem minden indításkor, így az alkalmazás deploy automatikus minden restart-nál az adatbázis deploy-ra meg csak image rebuild-nél kerül sor.
én jelenleg a b.) felé hajlok, mert jobban szeretek mindent egy helyen tudni. könnyebb a backup is, meg nem kell fejből tudni, hogy melyik adatbázis melyik alkalmazáshoz tartozik, szóval balesetek sem történnek. az adatbázis neveken sem kell módosítani, ha egy alkalmazás két eltérő verzióját akarom futtatni két külön container-ben.
szerk:
nem vagyok nagyon tapasztalt a témában, de úgy sejtem, hogy érdemes valami alkalmazás szerver szerűséget csinálni, amit a docker container indítása indít el. ez az alkalmazás szerver indítja vagy állítja le magát az alkalmazást, és csinálja meg a migrációt, deploy-t, build-et, rollback-et, stb. ha éppen arra van szükség. figyelhet ugyanúgy http kéréseket másik porton, mint maga az alkalmazás. nem tudom, hogy pontosan ezek hogyan nevezik, az egyik része szerintem a CI szerver munkaköre, szóval hogy release-t készísen, migráljon, stb. a másik része, az alkalmazás futtatása, leállítása meg alkalmazás szerver feladatkörnek tűnik. de ebbe nagyon nem folytam még bele.
Nekem van némi tapasztalatom
Egyébként minden új eszköz/fejlesztés esetén felteszem magamnak ezeket a kérdéseket:
- nyerek-e vele valamit?
- növelem-e vele a komplexitást?
- a nyert előny és a behozott komplexitás milyen arányban áll egymással?
Általában az "mert szeretek mindent egy helyre rakni" típusú döntésekből születnek az olyan projektek, amikor egy év múlva jön két új fejlesztő, és megkérdezik, hogy ez miért lett így megbonyolítva?
Amúgy nem tudom HA rendszer lesz-e, mert ha igen, akkor elég sz**ás lesz a deploy leállás nélkül.
Nem az lesz, de már írtam, ez
Mire jó a Docker?
Ha meg egyéb szolgáltatásokat használunk a szerveren belül, miért kéne a verzióknak teljesen megegyezniük? Ki gyárt manapság verzióspecifikus kódot? Az éles szerveren a szolgáltatások nem frissülnének? Vagy azoknak érdemes Dockert használni, akik függenek az adott nyelv/szolgáltatás legújabb frissítéseitől? És ha azok nem elég kiforrottak?
Én nem átlagos, webes
Van egy host rendszerem, amire különböző szolgáltatásokat akarok telepíteni. A dockerről olvasottak alapján eleve nem tiszta, hogy mire lenne jó, hiszen ha jól értem, ez processzeket zár konténerbe(1processz/konténer). Ha ez így van, akkor mi értelme mondjuk egy apparmor mellett, ami részben a hozzáférési jogokat korlátozza, de mellesleg van benne némi resource management is.
Eredetileg lxc-t akartam használni, de nem vagyok biztos abban, hogy akár virtualbox-szal vagy kvm-mel nem járnék-e jobban. Igaz, ezeknek nagyobb az overheadje, viszont egyelőre úgy érzem, valamivel egyszerűbb pl. mentést készíteni róluk, meg úgy általában, kényelmesebbnek tűnik a kezelésük.
Esetemben nincs szó nagy terhelésről vagy épp nagy rendelkezésre állásról, a vasam vidáman elbírja azt a két-három guestet. Vajon van értelme konténerekkel próbálkoznom?
Írták, hogy thin vs fat
Nem muszáj használni a docker-t. Szvsz shared host készítésénél jöhet ki igazán az előnye, mert szemben a virtuális gépekkel ez sokkal kevésbé erőforrás igényes. Én szeretnék beletanulni, de azért látni kell, hogy erős a hype mellette, és ha dedikált szervered van, akkor fele annyi előnye sincs, mint mondják.
Én is értelmezem még a
Én olvasom közben MadBence
Ahogy én látom a docker azért
Erre szerintem egy