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 í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.
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 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 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.
- Digest szerinti kiadás: A telepítés az új image digestjére hivatkozik, nem egy vándorló tagre.
- Először staging, azután éles: Egy másolaton futó automatikus tesztek elkapják az új alapimage-ek okozta töréseket.
- Ellenőrzés üzem közben: A kiadás után futtassa a
php -vparancsot a futó konténerben, és vesse össze a digestet a builddel. - 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 oldalon vannak.
Tipikus hézagok a láncban
- Build-gyorsítótár a runneren: A
--pullés a--no-cachené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.
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 í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 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.