CI/CD és monitoring DevOps szolgáltatás

A commit-tól az éles kiadásig, kézi lépés nélkül

Egy jó pipeline minden alkalommal ugyanazt teszi, ugyanabban a sorrendben. Megépítjük az image-et, lefuttatjuk a teszteket, ellenőrizzük a függőségeket és a konfigurációt, aláírjuk az artifactot, majd GitOps-on keresztül léptetjük tesztkörnyezetbe és élesbe. Senki nem másol fájlokat kézzel a szerverre, és senki nem tart titkot a tárolóban. Ha a csapatod több ágon dolgozik, védelmet és kötelező ellenőrzést teszünk a fő ágra, hogy egy merge ne csúszhasson át a tesztek nélkül.

• A tárolóban verziózott, kódként definiált pipeline
• Tesztek, linting és függőség-ellenőrzés kötelező kapuként
• Titkok trezorban, futáskor injektálva, soha nem a kódban
• Léptetés GitOps-on keresztül, minden változtatás naplózva

Bevált gyakorlatok, amelyeket alkalmazunk

A segítő és a zavaró pipeline közti különbség néhány, nálunk nem alku tárgyát képező szabályon múlik. Ezeket minden átadásnál alkalmazzuk, és a csapatod dokumentációjában is rögzítjük, minden riasztáshoz tartozó eljárásrenddel együtt. A cél egyszerűen megfogalmazható, de nehezen elérhető: egy kiadásnak unalmasnak kell lennie, egy hajnal háromkor érkező riasztásnak pedig azt kell jelentenie, hogy egy ügyfélnek valódi problémája van. Ezt a fegyelmet mindig a te csapatod munkarendjéhez igazítjuk, nem egy elvont sablonhoz.

• Kódként kezelt pipeline, védelemmel a fő ágon és teszt-kapukkal
• Artifact-aláírás és szoftverlista (SBOM) minden build után
• Titkok a tárolón kívül, trezorban, dokumentált rotációval
• GitOps-alapú kiadás: a kívánt állapot a gitben van, nem kézi parancsokban
• SLO hibakerettel, és a riasztás a megfelelő személyhez irányítva

Megfigyelhetőség, amelyet tényleg használnak

Egy irányítópult, amelyet senki nem néz meg, nem megfigyelhetőség. Metrikákat teszünk fel Prometheusszal, a naplókat Lokival központosítjuk, szükség esetén a kérésnyomon-követést Tempóval, majd csak azokat a paneleket építjük fel, amelyeket a csapatod tényleg megnyit egy incidens közben: kérésszám, hibaarány, válaszidő, telítettség. A riasztások rendelkezésre állási célokból indulnak ki, hibakerettel, hogy ne szokj rá a figyelmeztetések figyelmen kívül hagyására. Csak azt a panelt hagyjuk meg, amelyet a csapatod valóban megnyit egy incidens alatt, semmi mást.

• Metrikák, naplók és kérésnyomon-követés egy helyen
• A négy alapvető jelre épülő panelek
• Ellenőrzött lépéseket tartalmazó eljárásrend minden riasztáshoz

Hogyan illeszkedik az előfizetéshez

A pipeline felépítése és a monitoring beállítása a havi órák terhére történik: 1–8 óra havonta a VPS-terveken, csomagtól függően 5–10 óra a dedikált és 10 óra a GPU szervereken, 1 óra a cPanelen az Advanced tervtől kezdve. A munkát az ügyfélpanel DevOps szolgáltatások menüpontjából kéred, javasolt határidővel. Mivel az óraszám naptári hónaponként számít, és nem gördül át, jellemzően szakaszoljuk: egyik hónapban a pipeline, a másikban a monitoring és az eljárásrend. A kereten felüli munkát külön számlázzuk.

Hogyan dolgozunk

1. Igényled a panelből

   Kérést nyitsz a DevOps szolgáltatások menüpontban, elmondod, hol tárolod a kódot, hogyan telepítesz most, és mi segítene a legtöbbet ebben a hónapban.

2. Egyeztetjük a kereteket

   Megbeszéljük a pipeline lépéseit, a környezeteket és a rendelkezésre állási célokat, majd a rendelkezésre álló órák szerint felosztjuk a munkát.

3. Megvalósítjuk és párhuzamosan futtatjuk

   Felépítjük a pipeline-t, a régi folyamat mellett futtatjuk, amíg megbízhatóvá válik, majd beállítjuk a metrikákat, a naplókat és a riasztásokat.

4. Dokumentálva átadjuk

   Megkapod a pipeline-t a tárolóban, az exportált paneleket, a riasztási definíciókat és az eljárásrendet, hogy a csapatod nélkülünk is tudjon reagálni.

Felhasználási esetek

Technológiák

• GitHub Actions
• GitLab CI
• Argo CD
• Prometheus
• Grafana
• Loki
• Tempo
• Alertmanager
• Renovate

Gyakori kérdések

• Mi az a DevOps, és konkrétan mit csinál egy DevOps mérnök?

  A DevOps az a munkamódszer, amelyben a fejlesztés és az üzemeltetés ugyanazokat az eszközöket és ugyanazokat a szabályokat használja. Konkrétan a mérnök felépíti a kiadási pipeline-t, automatizálja az infrastruktúrát, beállítja a monitoringot és a riasztást, majd incidenskor beavatkozik, és csökkenti azok kiváltó okait.

• Mi az a CI/CD, és miért számít egy kisebb csapatnak?

  A CI azt jelenti, hogy minden változtatást automatikusan felépítenek és tesztelnek, a CD pedig, hogy kézi lépés nélkül kerül a környezetekbe. Egy kisebb csapatnak ez különösen sokat ér: nem függsz attól a személytől, aki tudja, hogyan kell telepíteni, és gyakran, alacsony kockázattal tudsz kiadni.

• Hogyan monitorozod az infrastruktúrát Prometheusszal és Grafanával?

  A Prometheus metrikákat gyűjt a szerverekről, a konténerekről és az alkalmazásból, a Grafana megjeleníti őket, az Alertmanager pedig kiküldi a riasztásokat. A Lokit hozzáadjuk a naplókhoz, hogy egy incidens közben egy helyen lásd a grafikont és a napló sorait, SSH-munkamenetek nélkül.

• GitLab CI vagy GitHub Actions?

  Attól függ, hol tárolod a kódot. A GitHub Actions egyszerűbben indítható, és nagy akció-ökoszisztémával rendelkezik. A GitLab CI finomabb kontrollt ad saját futtatott runnerekkel, és jól illik azoknak, akik saját maguk üzemeltetik az instanciájukat. A pipeline mindkét esetben hordozható marad.

• Mi történik, ha átlépem a beleértett órákat?

  A munka folytatódik. A havi keretet meghaladó órákat vállaljuk, és óradíj alapján, külön számlázzuk, a felhasználást pedig a panelben látod. Ha előre tervezünk, jellemzően a nagyobb szakaszokat illesztjük a keretbe, a finomításokat pedig a következő hónapra hagyjuk.

• Hogyan skálázod a monitoringot több száz szerverre?

  Szétválasztjuk a gyűjtést a tárolástól, következetes címkéket használunk, és hosszú távon aggregátumokat tartunk meg, nem minden egyes mintát. A riasztásokat szolgáltatásokra definiáljuk, nem gépekre, különben a jelzések száma gyorsabban nő, mint a csapat kapacitása, hogy elolvassa őket.