ugrás a tartalomhoz

Docker-el hogy megy a build & deploy?

inf3rno · 2016. Jan. 30. (Szo), 03.36
É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.
 
1

Ökölszabály: minden logikai

MadBence · 2016. Jan. 30. (Szo), 16.10
Ökölszabály: minden logikai service kapjon saját konténert, de több megközelítés is van (fat vs thin container probléma). Én jobban kedvelem ha egy processz fut minden konténerben (redis/mysql/amqp/solr/nginx/node/stb külön-külön).

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.
5

A több instance-nél még

inf3rno · 2016. Feb. 1. (H), 14.59
A több instance-nél még nagyon nem tartok. Meg ez most csak egyelőre itthonra lesz, nem hiszem, hogy csinálok magamnak akkora terhelést, hogy több instance kellene. Egyelőre még azzal küzdök, hogy átlássam mi az, ami a migrációt, adatbázis deploy-t, release build-et végzi (gondolom a CI szerver) és mi az, ami az alkalmazás indítást, leállítást, stb. összehangolja ezzel (gondolom alkalmazás szerver, de talán ez is CI szerver hatáskör). Egyelőre a responsibility-k ezzel kapcsolatban nem teljesen tiszták még.
9

Máshol is azt olvasom, hogy a

inf3rno · 2016. Feb. 13. (Szo), 19.33
Máshol is azt olvasom, hogy a thin container a nyerő, illetve hogy az adatokat el kell választani az alkalmazástól data container-ekbe. Egyelőre még az elején járok a dolognak, de úgy néz ki, hogy az eredeti elgondolásom kuka, és jobb elindulni a mások által lefektetett alapokon.

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.
2

Esetleg pingeld meg pp-t,

Joó Ádám · 2016. Jan. 30. (Szo), 16.39
Esetleg pingeld meg pp-t, most tartott a Webkonfon előadást a Dockerről.
3

Saját tapasztalatok: -

webproghu · 2016. Jan. 31. (V), 22.31
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?
4

Én két lehetőséget

inf3rno · 2016. Feb. 1. (H), 13.31
Én két lehetőséget látok.

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.
7

Nekem van némi tapasztalatom

webproghu · 2016. Feb. 1. (H), 21.12
Nekem van némi tapasztalatom production környezetben Docker-el, és teljesen felesleges a db szervert konténerbe rakni. Ne vedd rossz néven, de a szeretek mindent egy helyen tudni nem igazán érv. Azt gondold át minden esetben, hogy nyersz-e valamit azzal ha a db szervert konténerbe teszed?

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.
8

Nem az lesz, de már írtam, ez

inf3rno · 2016. Feb. 2. (K), 06.40
Nem az lesz, de már írtam, ez csak egy kis terhelésű szolgáltatás saját magamnak otthonra. Nyilván máshogy állnék neki egy HA rendszernek. Egyelőre csak próbálgatom, hogy mit lehet, és mit nem.
6

Mire jó a Docker?

Hidvégi Gábor · 2016. Feb. 1. (H), 17.43
Kinek éri meg használni? Egy átlagos webes környezetben van az adatbázis, vannak a szerveroldali fájlok és a szerveroldali egyéb szolgáltatások. A fejlesztői környezet adatbázisa és a futtatókörnyezet konfigurációs beállításai mások, mint élesben, ezért ezek nem másolhatóak. Adatbázis esetében frissítéseknél általában csak az eltérések mennek át. Fájloknál meg csak át kell másolni mindent.

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?
10

Én nem átlagos, webes

Há.Zé. · 2016. Feb. 14. (V), 14.18
Én nem átlagos, webes környezetben gondolkodom pillanatnyilag, de valami hasonló kérdések foglalkoztatnak engem is.
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?
12

Írták, hogy thin vs fat

inf3rno · 2016. Feb. 14. (V), 18.39
Írták, hogy thin vs fat container még mindig kérdés. Én személy szerint szeretem ha valamilyen logika mentén csoportosítva vannak a processek, mondjuk egy alkalmazáshoz tartoznak. Viszont a container-eknek nem kell ezt a csoportosítást követniük. Az igazi az lenne, ha valamilyen formában a docker támogatná a hierarchiát és a symlinket, hogy gráfot le lehessen írni vele. Jelenleg az van, hogy minden container-nek van id-je, és gondolom prefix-el lehet valamennyire hierarchikussá tenni az egészet, mert nincsenek névterek. Nem vagyok benne biztos, de ha egy container-nek két neve is lehet, akkor gráfot is le lehet így írni. Pl egy adatbázis container-t több másik is tud használni eltérő alkalmazásokból. Nagyjából így látom értelmét ennek a thin container-es kialakításnak. Illetve talán érdemes alkalmazásonként írni olyan szolgáltatást, ami a container-ek fellövését, leállítását végzni, pl ha ugyanazt a processzorigényes műveletet szeretnénk több worker-el csináltatni, akkor esetleg új thread helyett esetleg megfontolandó új container (process) felvétele.

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.
13

Én is értelmezem még a

Joó Ádám · 2016. Feb. 14. (V), 19.36
Én is értelmezem még a Dockert. Tény, hogy nem olvastam utána mélységében, de ha jól látom, olyan technológiákat csomagol össze (LXC és egy rétegzett fájlrendszer), amikről külön-külön látom, hol tudnám hasznosítani, de így együtt nem tiszta, hogy mi is a cél.
15

Én olvasom közben MadBence

inf3rno · 2016. Feb. 15. (H), 09.55
Én olvasom közben MadBence linkjét a base docker image-ről. Azt írják, hogy van egy ilyen PID 1 zombie reaping probléma. Nem biztos, hogy jól értem, de elvileg arról szól, hogyha a container kezdő process-e kinyíródik, akkor ad egy csomó child process-t az oprendszernek, amik ha daemon-ok, akkor sose kerülnek lelövésre. Ez már több éves probléma, és workaround rá, ha egy jól megírt init process-t használsz, viszont szerintem gáz, hogy nem a docker fejlesztői javítják ezt alacsony szinten, hanem a felhasználókra bízzák, akik egy jó része nem is biztos, hogy tud róla, hogy ez gond. Itthonra arra a néhány alkalmazáshoz, amihez nekem kell, én szerintem nem fogom használni a docker-t. Nem igazán látom az előnyét az én esetemben, macera meg ezek alapján sok van vele.
11

Ahogy én látom a docker azért

inf3rno · 2016. Feb. 14. (V), 18.32
Ahogy én látom a docker azért éri meg, mert ha elszáll egy container, az nem rántja magával az összes többit. A másik része, hogy a production környezettel teljesen megegyezőt tudsz csinálni bármilyen számítógépen, mert az oprendszer telepítésétől kezdve minden alkalmazás telepítését a docker image írja le. Így a szerver fellövésének munkáját teljes mértékben automatizálod. Tudsz image-eket mergelni, szóval akár még azt is megspórolhatod, hogy te rakd össze manuálisan a neked való image-et, elég ha valaki által összerakott image-eket mergelsz olyan formában ahogy neked szükséged van rá. Összességében sokkal kevesebb munka így beállítani bármilyen szervert, és sokkal stabilabb a működés.
14

Erre szerintem egy

Joó Ádám · 2016. Feb. 14. (V), 19.39
Erre szerintem egy konfigurációmenedzsment eszköz való, a speciális fájlrendszernek csak mint optimalizációnak látom létjogosultságát.