# Provoz PHP v kontejnerech

> Provoz PHP v kontejneru: varianty image, produkční php.ini, rozšíření, limity paměti, logy a aktualizace. S příklady a souvislostí s PHP2Shell.

Zdroj: https://phpsos.de/cs/php/php-in-containern/  
Stav: 25.10.2026  
Poskytovatel: PHP SOS, Nouzová pomoc pro PHP a bezpečnost serverů. Okamžitá pomoc přes WhatsApp: https://wa.me/491736494914?text=Dobr%C3%BD%20den%2C%20PHP%20SOS%2C%20pot%C5%99ebujeme%20pomoc%20s%20na%C5%A1%C3%ADm%20PHP%20serverem.%20Firma%3A%20%E2%80%A6%20Web%3A%20%E2%80%A6

**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](https://phpsos.de/cs/php2shell/docker-container-patchen/).

## 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:

```dockerfile
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:

```ini
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.

1. **Počet workerů:** `pm.max_children` v poolu FPM určuje, kolik požadavků se vyřizuje současně. Každý worker může obsadit až `memory_limit`.
2. **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čí.
3. **Logy:** kontejnery zapisují logy na standardní výstup. V PHP-FPM přesměruje `catch_workers_output = yes` vý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](https://phpsos.de/cs/server/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:

```bash
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](https://phpsos.de/cs/blog/php-images-in-ci-neu-bauen/).

> **Tip:**
> 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](https://phpsos.de/cs/leistungen/server-haertung/) 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.

## Zdroje

- [Docker Official Image: PHP](https://hub.docker.com/_/php)
- [Příručka PHP: Konfigurace FPM](https://www.php.net/manual/en/install.fpm.configuration.php)
- [php.net: Bezpečnostní oznámení z 21. 10. 2026](https://www.php.net/)