Megvalósítható a következő alkalmazás infrastruktúra?
2022-02-19T20:48:14+01:00
2022-02-19T23:42:03+01:00
2022-07-20T06:38:28+02:00
  • Általánosságban erre nehéz lesz hasznosat mondani, de talán abban segíteni tudok, hogy milyen területekre kell odafigyelned.

    Úgy látom, a Heroku ad managed Postgres adatbázist, amely valószínűleg elég könnyen felkonfigurálható olyan dolgokra, mint automatikus biztonsági mentés, magas rendelkezésre állás, stb. Nem szívesen venném magamra azt a terhet, hogy még a Postgres üzemeltetéséért is én feleljek. Tudom, írtad, hogy a free plan korlátos, de szerintem gondold át még egyszer!

    Nem tudom, hogy a spring boot backend szolgálja-e ki az Angular frontendet is, de ha a backend alatt azt érted, hogy tényleg csak valamilyen API-t szolgál ki, érdemes két külön containerbe tenni őket.

    Egyébként valóban jól látod, ez meglehetősen komplex témakör, három ok miatt:
    1) Függőségek
    2) Breaking change-ek
    3) Downtime
    Vegyük azt a példát, hogy van egy frontendet és egy backendet is érintő változás. A backend oldalon törekedni kell a visszafelé kompatibilitásra, tehát az új verziójú backendnek együtt kell tudnia működni a régi verziójú frontenddel. Ugyanez érvényes a backend és az adatbázis viszonyára. Ez mind-mind olyan függőség, amelyet a deploy során figyelembe kell venni, és a legalsó szintű komponens változásait kitelepíteni először.

    El kell tehát gondolkozni a deployment stratégián, amiből több is szóba jöhet.
    A legnaivabb módszer az, hogy olyan időben, amikor a rendszert senki sem használja, egyszerűen csak fogom, leállítom a rendszert, lefuttatom a Postgres backupot, majd a migrációs scripteket, végül kiteszem a frontend és a backend service-ek új verzióját, tesztelem őket, majd beindítom a gépezetet.
    Létezik a blue-green deployment. Ez azt jelenti, hogy a prod környezetből egyidejűleg két példányt építesz fel, és az egyiket blue-nak, a másikat green-nek hívod. A kettő között a különbség az, hogy az egyik környezet az új verzió, míg a másik a régi, de a kezdetben minden request-et a régi verzió kap meg. Ez a módszer tökéletes a breaking change-ek kezelésében, de a módszer nehézségét az okozza, hogy a két rendszer közt az adatokat szinkronban kell tartanod valamilyen úton-módon. Miután meggyőződtél arról, hogy az új verzió jól működik, szükség van egy mindenképp atomikus módon végzett átállásra a régi környezetről az újra.
    Van továbbá a canary deployment, amely két fázisból áll. Miután kitelepítetted az új verziót, a bejövő request-ek kis százalékát átirányítod a régiről az újra, és közben figyeled, hogy az új verzió hogyan viselkedik. Ez a fázis a canary testing. Mint azt láthatod, a két verzió egymás mellett él és dolgozik élesben, tehát tapasztalataim szerint breaking change-ek kezelésére nem annyira jó, mint a blue-green, de ha hiba van, a látogatóknak csak kis része tapasztal problémát, nem mindenki. Ha úgy látod, hogy minden oké, egyre több és több requestet irányíthatsz az új verzióra. Az, hogy a canary testing mennyi idő alatt fut le, sok dologtól függ, de megtörténhet fél óra alatt is, de akár napokig is húzódhat. A végső fázis a canary promotion, amikor az új verzió megkapja a requestek 100%-át, a régi verzió pedig kivezetésre kerül.
    Létezik még A/B testing, rolling deployment, stb., itt olvashatsz róluk.

    Adatbázist illetően az én véleményem az, hogy ilyen jellegű környezetekbe jobban illik egy (például dokumentum-elvű) NoSQL adatbázis-kezelő rendszer, mivel azoknak nincs annyira szigorú értelemben vett schema változása, mint egy SQL adatbázisnak, így nincs szükség migrációs scriptekre sem, hanem magát az alkalmazást lehet felkészíteni úgy, hogy önmaga lássa el verzióval a dokumentumot, és ezáltal könnyebben szinkronban tartható az adat a régi és az új verzió között. Természetesen tudom, hogy sok mindentől függ, hogy milyen adatbázisra van szükség, és SQL-re is léteznek jó migrációs eszközök, mint pl. a LiquiBase, aminek szintén érdemes utánaolvasni.

    Downtime-ot illetően pedig szintén jó mélyre lehet ásni. Ha a high availability a cél, valószínűleg a docker image-ekből sem egy-egy példány fog futni, hanem több, amelyek felett load balancer működik. Ezt jelenti a horizontálisan skálázhatóság, és abban különbözik a vertikálistól, hogy nem úgy növelsz teljesítményt, hogy erősebb procit és több ramot teszel a gépbe, hanem több példányban futtatod a szoftvered. Ez szintén alapos tervezést igényel, mert azok a rendszerek jók horizontális skálázhatóság terén, amelyek nem stateful app-ok. (Persze utóbbi esetén is meg lehet oldani, de nem ennyire egyszerű.) Az, hogy egy app nem stateful, az azt jelenti, hogy az end user szempontjából teljesen mindegy, hogy a request melyik példányhoz érkezik be, a kiszolgált eredmény ugyanaz marad, mintha az összes request ugyanarra a példányra futott volna be. De ha már ez a helyzet, lehet, érdemes megfontolni a Kubernetes világát Istioval, Prometheusszal és Flaggerrel megtámogatva (esetleg Grafana, Kiali és Elastic stack [Logstash, Filebeat, Kibana]).

    Nyilván nem kell egy hobbi projektet ennyire túltolni (és amúgy is túl sok ez egy embernek), de ha egy cégnél dockert használnak, valószínűleg hallani fogsz ezekről a technológiákról és módszerekről is előbb-utóbb, így ha másért nem, emiatt érdemes olvasnod róluk.
    Mutasd a teljes hozzászólást!
  • A futó Docker konténer fájlrendszere csak az adott konténerből érhető el, és a konténer törlésekor vele együtt törlődik. Ha nem raksz volume-ot az egész megoldásodba, akkor minden konténered saját adatbázissal fog dolgozni, újraindulás után pedig üres adatbázist fog látni.

    Tudtommal a postgres-t skálázni nem annyiból áll, hogy indítasz belőle sokat és megadod mindnek ugyanazt a foldert, bár nem nagyon néztem utána. Tehát ha a heroku-n tudsz kérni perzisztens fájlrendeszert amit mountolhatsz a Docker containereidbe, akkor is érdemes lehet különválasztani a postgres-t, hogy függetlenül tudjon skálázódni.
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Már régebb óta dolgozom egy spring boot rest api back-end-en (heroku-n lévő postgresql adatbázissal) és egy angular front-end-en. Ez egy hobby projekt egyébként. Mindegyik szépen funkcionál, a back-end-et postman-nel tesztelem, a front-end esetében pedig az app-ba írtam rövid mintaadatokat (hogy legyen mit megjeleníteni), amiket majd api call-okra cserélek (megvannak a service fájlok a megfelelő api call-okkal, már csak élesíteni kell a back-end-et).

    Mostanra értem el oda, hogy érdemesnek látom a kettőt összekötni ill. deploy-olni. A kérdésem pedig ehhez kapcsolódik. Ezen a téren eléggé tapasztalatlan vagyok, interneten olvasgatok blog post-okat, hogyan is működhet, milyen lehetőségek vannak.

    Az elképzelésem a következő:

    - készítek egy docker image-t, belerakom a postgresql-t meg a spring boot back-end-et (természetesen a megfelelő összeköttetéssel - értem ezalatt, hogy a back-end tudja, hol van az adatbázis, tehát itt nem a heroku-s postgresql-t használnám)
    - ugyanebbe a docker image-be teszem az angular app-ot is
    - a kész docker image megy a heroku-ra

    Működhet ez így? Vagy javasolnátok valami mást? És ilyenkor lényegében korlátlan mennyiségű adatot írhatok a db-be? Csak mert a heroku postgresql free plan-ja alapesetben korlátos

    Tudom, hogy a heroku-t git-en lévő repository-val is össze lehet kötni (a legtöbb tutorial inkább ezt taglalja), és a heroku abból build-olja az app-ot, de gyakorlás/új ismeretek miatt inkább a docker megoldást választanám.

    Aztán ha ez működik, akkor az egészhez még hozzáadnék egy CI/CD pipeline-t (Jenkins?), hogy ahogy haladok előre a fejlesztéssel, tudjam frissíteni a back-end-et és a front-end-et? Ennek így van értelme? Ez is teljesen új lenne számomra. Ilyenkor lényegében az image-ben lévő app-okat frissíteném/írnám felül, ha jól gondolom?

    Előre is köszi a válaszokat.

    ui: ha a témakör rossz, akkor kérem áttenni (nem igazán találtam megfelelőt)
    Mutasd a teljes hozzászólást!
abcd