Stručně: Pro provoz PHP v kontejnerech zvolte vhodnou variantu oficiálního image (fpm, apache nebo cli), aktivujte produkční php.ini, nainstalujte jen potřebná rozšíření a nastavte limity paměti a procesů, které spolu souvisejí. Kontejnery jsou neměnné: bezpečnostní aktualizace PHP jako u PHP2Shell se projeví, teprve když je image sestaven znovu a každý kontejner restartován. Toto nové sestavení proto patří jako pevný proces do každého provozu kontejnerů.
Proč PHP v kontejnerech?
Kontejnery zabalí PHP, rozšíření a konfiguraci do image, který běží na každém serveru stejně. Pro firmy to znamená: méně překvapení mezi testem a produkcí, rychlejší obnovu a jasné stavy verzí. Pro bezpečnost to ale znamená také novou povinnost: v kontejneru nikdo automaticky nenasazuje aktualizace.
Tato stránka se věnuje běžícímu provozu. Jak konkrétně záplatovat stávající kontejnery proti PHP2Shell, najdete v článku Záplatování PHP v kontejnerech Dockeru.
Volba správné varianty image
| Varianta | Obsah | Typické nasazení |
|---|---|---|
php:<version>-fpm |
PHP-FPM, vyžaduje předřazený webový server | produkce s Nginx, Caddy nebo ingressem |
php:<version>-apache |
Apache s mod_php, standardně mpm_prefork | jednoduchá sestavení, starší aplikace |
php:<version>-cli |
příkazová řádka, jako jediná varianta obsahuje i php-cgi | cron úlohy, workery front, kroky buildu |
…-alpine |
na Alpine Linux s musl | malé image, u některých rozšíření nutné úpravy |
…-bookworm, …-trixie |
na uvedené verzi Debianu | pevný základ pro reprodukovatelné buildy |
Pro nové projekty se zpravidla doporučuje varianta fpm s odděleným kontejnerem webového serveru. U mod_php vidí tým PHP v souvislosti s PHP2Shell nejvyšší riziko; kdo používá image apache, provozuje právě tento režim.
Sestavení produkčního image
Štíhlý příklad pro aplikaci s přístupem k MySQL:
FROM php:8.4-fpm-alpine
# Aktivovat produkční konfiguraci (podle dokumentace image důrazně doporučeno)
RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"
# Jen potřebná rozšíření
RUN docker-php-ext-install -j"$(nproc)" pdo_mysql
# Vlastní nastavení
COPY zz-sicherheit.ini "$PHP_INI_DIR/conf.d/"
# Kód patří rootovi; workery FPM běží jako www-data a mohou jej jen číst
COPY . /var/www/html
Pomocné skripty image přebírají sestavování rozšíření: docker-php-ext-configure pro volby, docker-php-ext-install pro sestavení, docker-php-ext-enable pro aktivaci, například po pecl install. Pokud se pomocí docker-php-source rozbalí zdrojový kód, měl by se podle dokumentace ve stejné vrstvě zase smazat. Soubor zz-sicherheit.ini by mohl vypadat takto:
expose_php = Off
display_errors = Off
log_errors = On
session.use_strict_mode = 1
session.cookie_httponly = 1
Dvě další zásady činí image odolnějšími. Zaprvé, dodávaný image obsahuje jen to, co je za běhu potřeba; překladače, cache balíčků a testovací soubory patří do vlastního stupně buildu. Zadruhé, uživatel, pod kterým PHP běží, smí zapisovat jen tam, kde je to nutné, například do adresářů pro nahrávání nebo cache na připojených svazcích. Mnoho týmů navíc provozuje kontejner se souborovým systémem chráněným proti zápisu. Vložený soubor PHP to má výrazně těžší zůstat natrvalo a každý restart obnoví čistý stav image. To nenahrazuje vyšetřování po incidentu, ale citelně zmenšuje plochu pro útok.
Procesy, paměť a logy v kontejneru
O tom, zda PHP kontejner běží stabilně, rozhodují tři nastavovací šrouby.
- Počet workerů:
pm.max_childrenv poolu FPM určuje, kolik požadavků se vyřizuje současně. Každý worker může obsadit ažmemory_limit. - Limit paměti kontejneru: omezuje všechny procesy dohromady. Jako hrubé pravidlo platí: počet workerů krát paměť na workera plus rezerva se musí vejít pod limit, jinak systém procesy ukončí.
- Logy: kontejnery zapisují logy na standardní výstup. V PHP-FPM přesměruje
catch_workers_output = yesvýstupy workerů do hlavního logu; bez tohoto nastavení podle příručky zmizí v prázdnu.
Užitečné je také request_terminate_timeout, které ukončí jednotlivé požadavky po uplynutí časového úseku, pokud nezabere max_execution_time. Jak provozovat kontejnery v clusteru, popisuje článek Záplatování PHP v Kubernetes.
Kontejnery a bezpečnost: co ukázala PHP2Shell
U PHP2Shell hrají kontejnery dvojí roli. Jednak jsou pomocí: php.net doporučuje jako přechodné opatření k CVE-2026-109618 kombinovat memory_limit=-1 s limitem paměti přes kontejner nebo cgroup, ideálně tak, aby se ukončil jen dotčený worker. RLIMIT_AS a RLIMIT_DATA jsou k tomu podle php.net nevhodné. Toto opatření není úplnou ochranou a aktualizaci nenahrazuje.
Jednak jsou kontejnery pastí, pokud se image nesestavují znovu. Image s PHP 8.4.26 zůstává zranitelný, bez ohledu na to, jak často se kontejner restartuje. Teprve nové sestavení na 8.4.27 nebo novější a výměna všech běžících kontejnerů zranitelnost uzavřou. Stav lze zkontrolovat přímo v běžícím kontejneru:
docker exec <container> php -v
docker exec <container> php-fpm -v
docker exec <container> php -r 'var_dump(ini_get("memory_hard_limit_percent"));'
Pokud poslední příkaz vrátí bool(false), PHP nezná direktivu zavedenou s opravenými verzemi; podle příručky je pak verze dotčena. Trvale pomáhá jen automatické nové sestavení, jak popisuje článek CI/CD: automatické nové sestavení image PHP.
V Dockerfile určete přesnou verzi PHP v tagu a zvyšujte ji vědomě. V kódu je pak dohledatelné, kdy byla nasazena která verze.
Jak konkrétně pomáhá PHP SOS?
U zpevnění serveru pro webové servery s PHP se staráme i o kontejnery:
- Zkontrolovat image: základní image, verze PHP, rozšíření a konfigurace každého image.
- Zpevnit konfiguraci: produkční ini, štíhlý seznam rozšíření, odpovídající limity workerů a paměti.
- Zavést nové sestavování: postup, který image při nových vydáních PHP sestaví znovu a nasadí.
- Kontrolovat běh: doložíme, že v každém běžícím kontejneru běží opravená verze.
Časté dotazy
Která varianta image PHP je ta správná?
Pro Nginx nebo jinou proxy variantu fpm, pro jednoduché sestavení s Apache variantu apache, pro skripty a cron úlohy variantu cli. Varianty Alpine jsou menší, ale vycházejí z musl místo glibc, což se u některých rozšíření projeví.
Aktualizuje se PHP v kontejneru automaticky?
Ne. Běžící kontejner se nemění. Musíte image s novou verzí PHP sestavit znovu a kontejnery restartovat. Teprve pak běží opravená verze.
Jak spolu souvisí memory_limit a limit kontejneru?
memory_limit omezuje každý jednotlivý požadavek PHP, limit kontejneru celý kontejner. Oba musí do sebe zapadat: počet workerů krát paměť na workera by měl ležet pod limitem kontejneru.
Potřebuji v kontejnerech php.ini?
Ano. Oficiální image dodávají php.ini-development a php.ini-production jako šablony. Pro produkci dokumentace image výslovně doporučuje produkční šablonu; vlastní nastavení patří do conf.d.