( kallaics | 2022. 12. 09., p – 07:22 )

A konténerizáció nem annyi, hogy ez mostantól konténerben fut. Ebbe sokan belefutnak.

Első lépésként legyen kimondva, hogy ebbe az irányba mentek. Utána le kell ülni a fejlesztőkkel és megkeresni mind üzemeltetés, mind fejlesztés oldalról milyen akadályok lehetnek, majd erre kell egy előzetes becslés, hogy ezt mennyi idő lefejleszteni. Ha megvannak az idők és a módosítandó részek a szoftverben, akkor az Ops oldalon meg lehet kezdeni a tervezést.

Az ops oldalon a fenti információk alapján az alábbi kérdések merülnének fel a teljesség igénye nélkül:

  • Adatbázis:
    • hol tároljuk? (RDS vs saját konténer)
    • Lehet-e  gy nagy adatbázis clusterben tárolni az összes DB-t?
    • DB mentési stratégia
    • Ha saját konténerek, akkor minden DB server cluster módban fusson? Hány példányban legyen replikálva? Milyen szinten legyen kiesés ellen védelem? (Elég ha a db cluster módban fut és a két példány mondjuk külön worker node-n vagy a ló másik oldala és több EKS más régiókban load balancerrel. Az igazság valahol a kettő között lesz)
    • Ügyfelek elszeparálásának meghatározása (egy namespace per ügyfél vagy egy cluster per ügyfél)
    • ktg-ek alakulása (javasolt 2-3 verziót megtervezni,  majd megvizsgálni költség hatékonyság oldalról is.
    • Konténerek biztonsága
  • Applikáció
    • Kód biztonsága (konténerizálás módja, kód védelem)
    • Ingess-ek
    • Buildek áttervezése
    • Akartok-e technológiákban is modernizálódni, mint pl. GitOps (megvalósításban: FluxCD, ArgoCD stb.)
    • Verzió upgradek és rollback-ek.

Még sok minden más előjöhet a konténerizáció és a Kubernetes kapcsán, de ez ad egy elég jó képet arról,  hogy 2 teljesen más világról van szó és egy az egyben nem feltétlenül átvihető, ill. nem nyer semmit vele akkor pl. az OPS.