Szeretnék tényleg "IaC" módon megépíteni egy-két dolgot.
Jelenleg ott tartok, hogy portainer-el installálok git repóból docker stacket, ez megy is szépen.
Most azzal szembesültem, hogy ha van egy volume egy service-nek (containernek) ami meg kéne maradjon (perzisztensen) akkor azt hogyan kell "jól" csinálni ?
Ha megcsinálom external volume-ként akkor triviális a dolog, úgy működik ahogy elvárnám, azaz ott marad két deploy között is.
Ott kell legyen előre (ha nincs akkor hibát dob a stack deploy), ha disaster van akkor nekem kell gondoskodni a volume restore-ról, akárhogy.
Ha ez a "normái út" akkor ezt a restore folyamatot hogyan szokás (és mennyire lehet) automatizálni?
Ezt le kell magamnak scriptelni mondjuk egy external backup location-ből visszaszedni mindent?
Hozzászólások
sub
A docker kontener stateless, az nginx+php kombomat (minden projekthez sajat) ugy allitottam be hogy leallaskor torlodjon is a kontener. De ahol adat is van (projekt mysql-je) ott nevesitett volume-ot hozok letre is latszik is a WSL alatt. Ugyanez pgsql eseten. Ezeket mentem a projekttel egyutt. De mivel a projektjeim db migrationt hasznalnak, a teljes db felipitheto ujra, persze adatok nelkul.
Mondjuk ez dev kornyezet.
Prodban fogd fel ugy hogy a mysql adatokat (nem a mappat, hanem dump) ugyis mentened kellene. A docker csak a bin-t segit gyorsan eloallitani.
Ennyire már eljutottam köszönöm :)
Nem is az alap docker hanem a stack viselkedése az érdekes.
Gábriel Ákos
nem divat containereknél a backup, ha szeretnél, akkor neked kell megoldani. tele van az internet howtokkal, hogyan futtass adatbázist containerben, de a backupról kevés szó esik.
nemrég openshift-en futó postgresql-hez kerestem megoldást (egy egyszerü napi dumphoz), de nincs "standard". vannak 3rd party megoldások, ami olyan extrákat kinál, amire nem volt szükseg. végül egy openshift conrjob mellett döntöttem, ami indít egy új containert, amiben fut egy script, ami indítja a dumpot. egy 2. volumera.... mint legegyszerübb megoldás.
En nem ertem a kerdesed.
Az erdekel, h lehet-e visszallitast automatizalni? Lehet.
Vagy az, hogy erdemes-e? Azt csak te tudhatod.
Vagy ezek kozul egyik sem? Akkor mi?
igen-igen, ebben az irányban menjünk tovább.
prod rendszer üzemeltetéséről van szó.
az image-ek valahol megvannak
a stack configját vissza tudom szedni gitből (IaC)
vannak volume-jaim ahol az éles adatok laknak, na ezeket hogyan tudnám a lehető legszebben
- menteni
- visszatölteni
Gábriel Ákos
Nincs uj a nap alatt, ugyanazt futtatod, mint az iac es a docker elott.
Menteni es visszallitani is ugyanugy lehet. Dumpolhatsz, snapshotolhatsz stb.
Az az erzesem, h vmi kesz toolt keresel. En nem ismerek olyat.
Milyen adatod van?
én úgy vettem észre, hogy a konténer platformok (pl. kubernetes, OpenShift) nem foglalkoznak ezzel a kérdéssel, nem akarják megoldani, de ez nem baj. Adnak neked facility-t (API-t) hozzá, hogy tudd kezelni a perzisztens volume-okat, de onnantól rád bízzák, hogy milyen módon oldod meg az adatok backupolását vagy a redundancia biztosítását. Erre meg az a válasz, hogy az adott rendszerhez már bevált dolgokat (pl. SQL-nél a dump) lehet alkalmazni itt is, semmi nem változik attól, hogy amúgy konténerben fut az adott bináris.
Szóval igen, a rövid válasz az, hogy úgy oldod meg ahogy neked a legjobb, vagy ahogy a helyzet vagy rendszer megkívánja.
Kellő távolságból nézve(!) tekintheted a docker konténeredet egy statikusan linkelt binárisnak, ami x feladatot lát el. Innentől kezdve tiszta sor, hogy az, amit egy staikus binárisba nem fordítanál bele, azt attól függetlenül kell majd tárolni/menteni/visszatölteni.
Ha mégis szeretnél benne változó tartalmat tárolni, akkor azt neked kell kezelned, hogy a konténer állapotváltozásaikor mi és hogyan történjen vele.
Lehet, hogy marhára félreértem, de miért nem úgy indul a CI/CD folyamat, hogy megnézi, van-e adatbázis és ha nincs, leteszi, mindjuk restore-ral? És akkor ez a legelső step, ami kihúzza az akármilyen backup-ból az utolsó verziót és leteszi, aztán épülhet a stack többi része. Igazából az a kérdés, hol és milyen backup-od van (elérhető-e pl. API-n át).