Új hozzászólás Aktív témák

• Drizzt nagyúr

  #14853

  #14844 instantwater

  2020-10-18 11:09:36

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Drizzt

  nagyúr

  #14844 instantwater

  #14844 instantwater

  A DevOps topik kihalt, úgyhogy bedobom ide.

  Egy kis brainstormingot szeretnék indítani az alábbiakról.

  Continuous Deployment környezetben ki melyik branching strategyt használja, és miért? Mi triggereli a promotiont stagingből productionbe?

  Melyik azonosítót használnád a deploymentek jelölésére? Semver, git hash, vagy build id?

  A semver igényel emberi közreműködést, mert default a patch számot növelné a rendszer, de a fejlesztő belátásán múlik, hogy a kód amit beküld az inkább egy minor bump legyen patch bump helyett.

  Git hash egyértelmű, könnyen visszavezethető pontosan a forrás commitra. Viszont nincs benne szekvencia, nehéz megmondani 2 git hashról, hogy melyik a későbbi anélkül, hogy valaki megnézi a git historyt és megkeresi a commitokat ID alapján.

  Build number szekvenciális, és nem igényel emberi beavatkozást, viszont nehéz visszavezetni commitra.

  Viszont, ha nem kap verzió taget egy-egy commit, akkor mi triggereli a production deployt, ha stagingben megfelelt a kód?

  Van erre valami best practice? Itt vissza térünk a kérdés elejére, hogy melyik branching strategy lenne a legideálisabb.

  Jelenleg GitFlowot használunk, de macerás a dupla PR a hotfixekhez (master, develop), és a develop PRrel kerül a masterbe (és deployolásra) hetente 2x, amit szintén szeretnénk lecserélni napi többszöri deploymentre.

  Az eszközökkel nincs baj, GitHub Actions, Docker, Terraform, Ansible tapasztalat megvan, inkább a mit mikor és hogyan lenne a kérdés.

  A deployment jelenleg egy több szerverre kitolt kódbázissal megy ahol a függőségek az összes szerveren helyben újra és újra telepítve vannak ami írtó sávszél pazarló, és fragile, mert boldog-boldogtalan root joggal bír a szervereken, és gyakran elb.rmolják az ownershipeket.

  Ezt le akarom cserélni immutable image alapú deploymentre, ahol egyszer vannak telepítve a függőségek, majd ez az image van kitolva a szerverekre.

  Ez lehet akár machine image buildeléssel aztán Terraformmal lecserélni a szervereket és újrakonfigurálni a routingot, de ezt lassúnak érzem. A másik opció Docker image buildelés lenne, mert az könnyen és gyorsan lehet kitolni a szerverekre.

  Hosszabb távon a cél Kubernetesre költözés, de mivel egy monolit alkalmazásról van szó ezért úgy érzem az azonnali Kubernetesre váltás túl sok új komplikációt hozna, és jelenlegi archirektúra automatizálása egy jó köztes lépés lenne.

  Vagy ahogy egy szakadékot sem lehet két ugrással átugrani, több értelme lenne egyből Kubernetesbe tolni az egészet, aztán lassan refaktorálni microservices architektúrára?

  Kinek mi jött be, mi működött, nem működött?

  Egy tanács:
  - Nem tudom ugyan, hogy milyen nyelven/frameworkon fejlesztetek, de ha Spring boot, akkor semmiképpen ne fat jarba package-eljetek docker image esetén, hanem a dependency-k, meg az alkalmazás források legyenek külön docker layerben. Ezzel az össz. helyfoglalás jóval kisebb lesz, illetve amíg nem változik a dependency-k összetétele, addig az a layer ott tud csücsülni azon a gépen, ahol a docker már találkozott vele, így nem kell letölteni se újra.
  - Még érdekes kérdés, amit tisztázni kell, hogy hol tároljátok az alkalmazáshoz tartozó környezetfüggő konfigurációkat. Különös tekintettel a szenzitív adatokra(db cred, etc.).
  - "A deployment jelenleg egy több szerverre kitolt kódbázissal megy ahol a függőségek az összes szerveren helyben újra és újra telepítve vannak ami írtó sávszél pazarló, és fragile, mert boldog-boldogtalan root joggal bír a szervereken, és gyakran elb.rmolják az ownershipeket." Ez nagy baj, de docker használatával kapásból meg tudjátok oldani.

Új hozzászólás Aktív témák