HU

Docker és infrastruktúra kódként

A legtöbb weboldal és alkalmazás olyan szerveren fut, amit egyszer, manuálisan állított be valaki, aki azóta már máshol dolgozik. Működik, amíg működik, de hiba esetén szinte lehetetlen ugyanúgy újraépíteni. Ezt váltjuk ki egy fájlokban leírt környezettel, ami bármikor automatikusan felépíthető, tesztelhető és visszaállítható.

services:  app:    image: registry.example.com/app:1.4.0    restart: unless-stopped    depends_on: [db, cache]  db:    image: mariadb:11    volumes: ['db-data:/var/lib/mysql']volumes:  db-data:

Szolgáltatások

Miben segítünk?

Ugyanaz fut a fejlesztő gépén, a tesztkörnyezeten és élesben, nem egy hasonló verzió, hanem pontosan ugyanaz a csomag.

A futtatókörnyezet egyetlen forrásból épül fel. Ami működik a tesztelés során, az ugyanúgy működik élesben is, hiszen ugyanaz a csomag fut a háttérben, azonos PHP-verzióval, ugyanazokkal a kiterjesztésekkel, rögzített függőségekkel és egyforma szerverbeállításokkal.

FROM php:8.4-fpm-alpine AS baseRUN docker-php-ext-install pdo_mysql opcacheCOPY --from=composer:2 /usr/bin/composer /usr/bin/composerCOPY composer.json composer.lock ./RUN composer install --no-dev --optimize-autoloaderCOPY . /appCMD ["php-fpm"]

Az eredmény

Miért jobb ez a megközelítés?

Ez a működés megszünteti azoknak a hibáknak az egész osztályát, amik kizárólag az éles szerveren bukkannak fel a legrosszabb pillanatban, és sehol máshol nem reprodukálhatók.

Az élesítés így nem esemény, hanem munkaidőben lefutó rutin. Ha egy kiadás mégis rossznak bizonyul, a visszalépés egyetlen parancs, nem pedig egy este manuális javítgatás. A mentésekben pedig azért lehet bízni, mert a visszaállításukat rendszeresen kipróbáljuk.

A kiszámíthatóság nem emberi odafigyelés kérdése. A szerver állapota nem a kollégák fejében létezik, hanem a verziókövetett kódbázisban. A folyamatokat a gép pontosan ugyanúgy hajtja végre századszorra is, mint legelőször.

A frissítés folyamata előtte és utána

A hagyományos működésnél a verziók kiadása egy fejből végzett, kockázatos lépéssorozat. Amíg a felelős kolléga elérhető, működik a dolog, de a távollétében megállnak a frissítések, egy-egy kihagyott lépés pedig csak élesben okoz meglepetést.

Az automatizált pipeline minden alkalommal pontosan ugyanúgy fut le, hiba esetén pedig azonnal leáll. Nem az a kérdés, kinek van épp ideje az élesítésre, hanem az, hogy elkészült-e a feladat. Egy javítás azonnal kikerülhet a felhasználókhoz, hiba esetén pedig egyetlen lépéssel visszaállítható a korábbi állapot.

.gitlab-ci.yml

#1482 main a3f19c2 4m 12s
  1. build lefutott 1m 12s

    Az image elkészül a repóból.

    • docker build 1m 04s
    • push registry 8s
  2. test lefutott 2m 08s

    Lefut minden ellenőrzés, és egy hiba megállítja a futást.

    • phpunit 1m 31s
    • phpstan analyse 29s
    • pint --test 8s
  3. deploy lefutott 46s

    A staging ugyanazt az image-et kapja meg.

    • compose pull 31s
    • migrate --force 15s
  4. release folyamatban 6s

    Élesbe is a pipeline teszi ki, tagre indulva.

    • tag v1.4.0 2s
    • rollback: previous image 4s
Mind a négy szakasz gépen fut. Élesbe egy tag indítja, és ugyanaz a lépéssor megy le.

Az átvétel

Mit veszünk át pontosan?

Az üzemeltetés átvétele konkrét, jól definiált feladatokat jelent. Nem szükséges egyszerre mindent kérned, mert a legtöbb együttműködés felméréssel és konténerizálással indul, a többi lépés pedig igény szerint követi.

  1. Felmérés

    Részletesen feltérképezzük a jelenleg futó szolgáltatásokat, verziókat, adattárolási pontokat és hozzáféréseket. Végül egy teljes, tiszta technikai leírást adunk át a kezedbe.

  2. Konténerizálás

    Az alkalmazást és a futtatókörnyezetet egyetlen verziózott csomagba rendezzük. A költözés szakaszosan zajlik, folyamatos visszaállási útvonalat biztosítva.

  3. CI/CD

    Automatizált tesztek és kódellenőrzések minden módosításkor, egyszerűsített élesítési folyamattal. A jogosultságokat ti határozzátok meg a csapaton belül.

  4. Mentések

    Rendszeres fájl- és adatbázismentések automatizált visszaállítási próbákkal. Egy mentés csak akkor megbízható, ha a visszaállítása a gyakorlatban is ellenőrzött.

  5. Monitorozás

    Folyamatosan mérjük a válaszidőket, a tárhelykapacitást és a tanúsítványok érvényességét. A riasztások közvetlenül a megfelelő felelőshöz futnak be.

  6. Jogosultságok

    Pontosan rögzítjük a szerverhozzáféréseket, a telepítési jogokat, valamint a jelszavak és kulcsok biztonságos tárolását.

#!/bin/shset -eu# A backup on its own is hope. The restore test is the evidence.docker compose exec -T db mysqldump app > /backup/app-$(date +%F).sqlrestic backup /backup /var/www/storage# Once a week: the latest backup restored into a throwaway database.restic restore latest --target /tmp/verifydocker compose exec -T db-verify mysql verify < /tmp/verify/app-*.sql
A második fele visszatölti a mentést: attól mentés, hogy ki van próbálva.

Saját fejlesztőcsapat esetén

Nem vesszük el a munkát, hanem tehermentesítjük a fejlesztőiteket. A csapatod ideje felszabadul a környezet folyamatos foltozgatása, a manuális verzióváltások és a tanúsítványok kézi megújítása alól.

A szervermódosítások átlátható, verziókövetett kóddá válnak, ahol pontosan látszik minden változtatás oka és iránya. A folyamatokat közösen visszük végig, és a későbbi módosításokat már a ti embereitek írják a támogatásunkkal.

Meglévő üzemeltető esetén

Nem szükséges szolgáltatót váltanotok. Sokszor az a jó megoldás, hogy a meglévő környezetet kódban rögzítjük, és onnan a jelenlegi partneretek üzemelteti tovább, ugyanezekkel az eszközökkel.

A konténeres felépítés független attól, hogy melyik szerveren vagy szolgáltatónál fut a rendszer. A felmérés után teljes képet kaptok a helyzetről, és ha minden ideálisan működik, azt is nyíltan megmondjuk.

Baj esetén

Mi történik váratlan hiba esetén?

Ez a legfontosabb kérdés az üzemeltetési megállapodások előtt, és négy helyzetre kell választ adni.

  • Ha hibás frissítés került ki, a visszalépés az előző stabil verzióra egyetlen parancs.
  • Ha adat veszik el, a mentésből állítjuk vissza, és tudjuk, hogy működik, mert a visszaállítást kipróbáltuk.
  • Ha leáll a szerver, a környezet kódban van leírva, tehát újraépíthető, nem emlékezetből rakjuk össze.
  • Ha kérdésed van, konkrét szakemberhez és előre egyeztetett reakcióidőhöz jutsz, nem egy személytelen ügyfélszolgálati postafiókhoz.

A reakcióidőket és a garanciákat a szerződésben pontosan rögzítjük. A hibák feltárása után nemcsak elhárítjuk a problémát, hanem a kód szintjén biztosítjuk, hogy ugyanaz a helyzet többé ne fordulhasson elő.

A rendelkezésre állást folyamatosan mérjük, és a mért értéket meg is mutatjuk. Az üzemeltetési szerződésben ez vállalt szám, nem ígéret, és ugyanaz a háttér áll mögötte, amin az intrapp.io rendszerei futnak.

Referenciák

Rendszerek, amiket mi építettünk és mi is üzemeltetünk

Néhány példa a munkáinkból. Mindegyiket mi fejlesztettük, és a futtatókörnyezetük is nálunk van, tehát konténerben futnak, kódban leírt infrastruktúrával és automatizált élesítéssel.

A saját munkánkat is így építjük

Ez a weboldal és az összes belső rendszerünk is konténerben fut, ugyanezzel az automatizált folyamattal.

Ugyanez fut az intrapp.io alatt is, amire az egyedi fejlesztéseink épülnek. Ott is konténerből indul a környezet, ott is a pipeline teszi ki élesbe, és ott is hetente megy ki kiadás. Amit nálad bevezetünk, azt nálunk minden nap használjuk.

deploy:  stage: deploy  image: docker:27  script:    - docker compose pull    - docker compose up -d --wait  rules:    - if: $CI_COMMIT_TAG      when: manual
Élesbe csak tagre indul: a kiadás dátumát az szabja meg, mikor tesszük ki a tagot.
A Telefonszám tudakozó nyitólapja, középen a keresőmezővel, alatta a leggyakoribb hívástípusokkal.
A Telefonszám tudakozó nálunk fut, konténerben, kódból felépülő környezettel, 2003 óta gyűlő adattal és napi több tízezer kereséssel.

Nézzük meg, mi fut ma nálatok

Írd le röviden a mostani állapotot, tehát hogy milyen alkalmazást használtok, hol fut, és mi az, ami a mindennapokban nehézkes. Átnézzük a részleteket, és reális javaslatot adunk a konténerizálásra és a stabilizálásra.

Írok nektek