# CI/CD: PHP-image-ek automatikus újraépítése

> Docker image automatikus újraépítése: időzített buildek, verzióellenőrzés a pipeline-ban és digest szerinti kiadás, hogy a PHP-javítások megbízhatóan megérkezzenek.

Forrás: https://phpsos.de/hu/blog/php-images-in-ci-neu-bauen/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**Röviden:** Egy Docker image a PHP-t a build időpontjának állapotában tartalmazza, és kódmódosítás nélkül is elavul. Aki az image-eket automatikusan újraépíti, időzítve és biztonsági közleményeknél, a PHP-verziót a pipeline-ban ellenőrzi, és digest szerint adja ki, a PHP2Shell elleni javításokhoz hasonlókat tervezhetően juttat az éles rendszerbe. Egy zöld build önmagában nem igazolás; a futó konténerben lévő verzió számít.

## Miért avulnak el az image-ek kódmódosítás nélkül

Sok csapatnál a build pipeline csak akkor indul, ha valaki kódot módosít. Az alkalmazás szempontjából ez logikus. A biztonság szempontjából probléma, mert az image PHP-je az utolsó build napján érvényes alapimage-ből származik.

A PHP2Shell ezt láthatóvá tette. A kijavított 8.5.12, 8.4.27, 8.3.36 és 8.2.35 verzió 2026. október 21-én jelent meg. Az a projekt, amelyen ezekben a napokban senki sem dolgozott, nem kapott új buildet, és a régi PHP-vel futott tovább, noha az alapimage már rég frissítve volt. A kézi utat ebből a helyzetből a [PHP javítása Docker-konténerekben](https://phpsos.de/hu/php2shell/docker-container-patchen/) írja le. Ez a cikk azt mutatja meg, hogyan automatizálja.

## Docker image automatikus újraépítése: három kiváltó ok

Egy robusztus folyamat több kiváltót kombinál, hogy egyiknek se kelljen egyedül tartania.

| Kiváltó | Megvalósítás | Tudnivalók |
|---|---|---|
| Időterv | időzített workflow, pl. hetente | kódmódosítás nélkül is begyűjti a javításokat |
| Új alapimage | az alapimage-eket figyelő és módosításokat javasló eszköz | főként rögzített verziótageknél hat |
| Biztonsági közlemény | a pipeline kézi indítása az üzemeltető csapat által | egyértelmű felelős kell hozzá |

GitHub Actionsnél a `schedule` esemény adja az időtervet. A GitHub-dokumentáció szerint öt mezős cron-szintaxist használ, UTC-ben fut, és csak az alapértelmezett branchen. Az ütemezett futások nagy terhelésnél késve indulhatnak, és a nyilvános repositorykban a GitHub 60 napnyi tevékenység nélkül kikapcsolja őket. Éppen ez utóbbi érinti a csendes projekteket, vagyis pontosan azokat, amelyeknek a legsürgősebben szükségük van az automatikus újraépítésre.

A második kiváltóhoz a Dependabot a GitHub-dokumentáció szerint támogatja a `docker` ökoszisztémát, és az alapimage-ek új állapotait pull requestként javasolja. Két megszorítást érdemes ismernie. Először: valakinek át kell néznie és össze kell fűznie a pull requestet, különben ott marad. Másodszor: egy olyan ágtagnél, mint a `php:8.3-fpm` a Dockerfile-ban, semmi sem változik, ha az alapimage-et újraépítik. Egy szövegmódosításokat javasoló eszköznek ilyenkor nincs mit javasolnia. Éppen ezért kell emellett az időzített újraépítés.

A harmadik kiváltó banálisan hangzik, de a gyakorlatban gyakran azon bukik, ki indítja. Rögzítse, ki követi a PHP-ra vonatkozó biztonsági közleményeket, és ki indíthatja a pipeline-t, hétvégén is. A PHP2Shellnél az előzetes bejelentés és a javítás között csak egy nap telt el.

## Egy pipeline, amely elkapja az elavult PHP-t

A következő GitHub Actions példa hetente és gombnyomásra újraépíti az image-et, ellenőrzi a PHP-verziót, és megszakad, ha az a kijavított állapot alatt van. A registryt, a neveket és a minimális verziót igazítsa a sajátjához.

```yaml
name: php-image-rebuild
on:
  schedule:
    - cron: "0 3 * * 1"      # hétfőnként 03:00 UTC
  workflow_dispatch: {}      # kézi indítás biztonsági közleményeknél

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Image ohne Cache und mit frischem Basis-Image bauen
        run: docker build --pull --no-cache -t app:${{ github.run_id }} .
      - name: PHP-Version prüfen (Mindeststand des Zweigs 8.3)
        run: |
          docker run --rm app:${{ github.run_id }} php -v
          docker run --rm app:${{ github.run_id }} \
            php -r 'exit(version_compare(PHP_VERSION, "8.3.36", ">=") ? 0 : 1);'
```

A verzióellenőrzés a hivatalos PHP image-eknél működik, amelyek verziószáma a tényleges állapotot adja meg. Ha az Ön image-e egy disztribúció PHP-csomagjait használja, a szám egy backport után gyakran ugyanaz marad. Ilyenkor a szám helyett a csomag changelogját ellenőrizze a CVE-számokra, ahogyan a [CVE-számok igazolása a csomag changelogjában](https://phpsos.de/hu/blog/cve-im-changelog-nachweisen/) cikk leírja.

Az ellenőrzés után a gyakorlatban három további lépés következik: az image átvizsgálása ismert sebezhetőségekre, feltöltése a registrybe dátummal és digesttel, és a digest átadása a telepítésnek. Hogy mely tagek és változatok alkalmasak alapnak, azt a [Hivatalos PHP Docker image-ek](https://phpsos.de/hu/blog/offizielle-php-docker-images/) cikk magyarázza.

## A buildtől a futó konténerig

A leggyakoribb gondolkodási hiba: a pipeline zöld, tehát minden javított. Valójában az új image csak a registryben van. A javítás csak akkor lesz hatékony, ha minden konténert újra létrehoztak az új image-ből.

1. **Digest szerinti kiadás:** A telepítés az új image digestjére hivatkozik, nem egy vándorló tagre.
2. **Először staging, azután éles:** Egy másolaton futó automatikus tesztek elkapják az új alapimage-ek okozta töréseket.
3. **Ellenőrzés üzem közben:** A kiadás után futtassa a `php -v` parancsot a futó konténerben, és vesse össze a digestet a builddel.
4. **A visszaút korlátozása:** A régi image rövid visszaútra elérhető marad, de a sebezhető PHP-t tartalmazza.

Kubernetesben erre saját szabályok vonatkoznak, például a pull policyra; ezek a [PHP javítása Kubernetesben](https://phpsos.de/hu/server/kubernetes/) oldalon vannak.

## Tipikus hézagok a láncban

- **Build-gyorsítótár a runneren:** A `--pull` és a `--no-cache` nélkül a régi alapimage-et használják újra.
- **Registry-tükör:** Egy belső köztes tároló még az alapimage régi állapotát szolgáltatja.
- **Többlépcsős buildek:** Az utolsó lépcső PHP-verziója számít, de gyakran csak az elsőt ellenőrzik.
- **Mellékimage-ek:** A queue-workereknek, a cron-konténereknek és a belső eszközöknek saját pipeline-juk van, vagy egyáltalán nincs.
- **Rögzített digestek:** Az alapimage egyszer rögzített digestjét soha nem frissítik, ha nincs eszköz, amely figyeli.

> **Fontos:**
> Az újraépítés a PHP-t váltja le, nem az adatokat. A javítás előtt köteteken, feltöltési mappákban vagy az adatbázisban lévő kártékony kód megmarad, és külön ellenőrizni kell.

## Ki reagál, ha az újraépítés meghiúsul?

Az automatikus újraépítés csak annyit ér, amennyit a meghiúsulására adott reakció. Ha a verzióellenőrzés riaszt, vagy a build egy módosult alapimage miatt megszakad, azt valakinek észre kell vennie. Sok csapatnál az ilyen jelzések egy olyan postafiókba kerülnek, amelyet senki sem olvas, vagy egy olyan csatornába, ahol a piros buildek már rég a mindennapok részei.

Egyértelmű szabály vált be: egy meghiúsult biztonsági újraépítés jegy, felelőssel és határidővel, nem egy a sok közlemény közül. Rögzítse ezenkívül minden kiadott image-hez a dátumot, a digestet és az ellenőrzött PHP-verziót. Ez a lista a következő közleménynél percek alatt megválaszolja, mely alkalmazások érintettek, és ellenőröknek vagy biztosítóknak igazolásul szolgál. Hogyan lesz ebből tartós folyamat, azt a [Javításkezelés folyamatként, nem tűzoltásként](https://phpsos.de/hu/blog/patch-management-prozess/) írja le.

## Hogyan segít konkrétan a PHP SOS?

- **Pipeline-ok ellenőrzése:** Megnézzük a build- és kiadási láncait, és megmutatjuk, hol akadhat el egy javítás.
- **Az újraépítés automatizálása:** Beállítjuk az időzített buildeket, a verzióellenőrzést és a digest szerinti kiadást.
- **Az összes image felvétele:** Minden futó konténerhez hozzárendeljük a pipeline-ját, a mellék- és régi image-ekét is.
- **Tartós gondozás:** A [biztonsági karbantartási szerződés](https://phpsos.de/hu/leistungen/security-wartungsvertrag/) keretében követjük a biztonsági közleményeket, és elindítjuk az újraépítéseket.


## Gyakori kérdések

**Milyen gyakran kell újraépíteni egy PHP-image-et?**  
Fix szám nincs. Bevált a rendszeres időzített build, például hetente, plusz azonnali build biztonsági közleményeknél. Az a döntő, hogy egy új javításnak ne kelljen a következő kódmódosításra várnia.

**Elég igazolásnak egy sikeres build?**  
Nem. A build csak azt bizonyítja, hogy létezik egy új image. Csak ha a futó konténereket újra létrehozták ebből az image-ből, és a php -v benne a kijavított verziót mutatja, akkor hatékony a javítás.

**Miért jelenik meg az újraépítés után mégis a régi PHP-verzió?**  
Gyakori okok: egy build-gyorsítótár, amely újrahasznosítja a régi alapimage-et, egy régi állapotú registry-tükör, vagy egy második FROM sor egy többlépcsős buildben. Építsen a --pull és --no-cache kapcsolókkal, és ellenőrizzen minden lépcsőt.

**Frissítheti a Dependabot az alapimage-eket?**  
A GitHub-dokumentáció szerint a Dependabot a Docker ökoszisztémát verzió- és biztonsági frissítésekhez támogatja. Az alapimage-ek módosításait pull requestként javasolja. Az azonos tagű újraépítést ez nem pótolja.

## Források

- [GitHub Docs: a workflow-kat indító események (schedule)](https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows)
- [GitHub Docs: a Dependabot által támogatott ökoszisztémák](https://docs.github.com/en/code-security/dependabot/ecosystems-supported-by-dependabot/supported-ecosystems-and-repositories)
- [Docker Hub: hivatalos PHP image](https://hub.docker.com/_/php)
- [PHP: támogatott verziók](https://www.php.net/supported-versions.php)