# Prevádzka PHP v kontajneroch

> Prevádzka PHP v kontajneri: varianty obrazov, produkčný php.ini, rozšírenia, limity pamäte, logy a aktualizácie. S príkladmi a väzbou na PHP2Shell.

Zdroj: https://phpsos.de/sk/php/php-in-containern/  
Stav: 25.10.2026  
Poskytovateľ: PHP SOS, Núdzová pomoc pri PHP a bezpečnosť serverov. Okamžitá pomoc cez WhatsApp: https://wa.me/491736494914?text=Dobr%C3%BD%20de%C5%88%2C%20PHP%20SOS%2C%20potrebujeme%20pomoc%20s%20na%C5%A1%C3%ADm%20serverom%20s%20PHP.%20Spolo%C4%8Dnos%C5%A5%3A%20%E2%80%A6%20Web%3A%20%E2%80%A6

**Stručne:** Ak chcete prevádzkovať PHP v kontajneroch, zvoľte vhodný variant oficiálneho obrazu (`fpm`, `apache` alebo `cli`), aktivujte produkčný php.ini, nainštalujte len potrebné rozšírenia a nastavte limity pamäte a procesov, ktoré k sebe pasujú. Kontajnery sú nemenné: bezpečnostná aktualizácia PHP, ako pri PHP2Shell, zaberie až vtedy, keď je obraz zostavený znova a každý kontajner reštartovaný. Toto nové zostavenie preto patrí ako pevný proces do každej prevádzky kontajnerov.

## Prečo PHP v kontajneroch?

Kontajnery zabalia PHP, rozšírenia a konfiguráciu do obrazu, ktorý beží na každom serveri rovnako. Pre firmy to znamená: menej prekvapení medzi testom a produkciou, rýchlejšie obnovenie a jasné stavy verzií. Pre bezpečnosť to však znamená aj novú povinnosť: v kontajneri nikto automaticky nenasadzuje aktualizácie.

Táto stránka sa venuje prebiehajúcej prevádzke. Ako konkrétne záplatovať existujúce kontajnery proti PHP2Shell, je uvedené v [Záplatovanie PHP v kontajneroch Docker](https://phpsos.de/sk/php2shell/docker-container-patchen/).

## Voľba správneho variantu obrazu

| Variant | Obsah | Typické použitie |
|---|---|---|
| `php:<version>-fpm` | PHP-FPM, vyžaduje predradený webový server | produkcia s Nginx, Caddy alebo ingressom |
| `php:<version>-apache` | Apache s mod_php, štandardne mpm_prefork | jednoduché nasadenia, staršie aplikácie |
| `php:<version>-cli` | príkazový riadok, ako jediný variant obsahuje aj php-cgi | cronjoby, queue workery, kroky zostavenia |
| `…-alpine` | na Alpine Linux s musl | malé obrazy, pri niektorých rozšíreniach sú potrebné úpravy |
| `…-bookworm`, `…-trixie` | na uvedenej verzii Debianu | pevný základ pre reprodukovateľné zostavenia |

Pre nové projekty sa spravidla odporúča variant `fpm` so samostatným kontajnerom webového servera. Pri mod_php vidí tím PHP v súvislosti s PHP2Shell najvyššie riziko; kto používa obraz `apache`, prevádzkuje práve tento spôsob prevádzky.

## Zostavenie produkčného obrazu

Štíhly príklad pre aplikáciu s prístupom k MySQL:

```dockerfile
FROM php:8.4-fpm-alpine

# Aktivovať produkčnú konfiguráciu (podľa dokumentácie obrazu dôrazne odporúčané)
RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"

# Iba potrebné rozšírenia
RUN docker-php-ext-install -j"$(nproc)" pdo_mysql

# Vlastné nastavenia
COPY zz-sicherheit.ini "$PHP_INI_DIR/conf.d/"

# Kód patrí používateľovi root; workeri FPM bežia ako www-data a môžu ho iba čítať
COPY . /var/www/html
```

Pomocné skripty obrazu preberajú zostavovanie rozšírení: `docker-php-ext-configure` pre voľby, `docker-php-ext-install` na zostavenie, `docker-php-ext-enable` na aktiváciu, napríklad po `pecl install`. Ak sa pomocou `docker-php-source` rozbalí zdrojový kód, má sa podľa dokumentácie v tej istej vrstve opäť zmazať. Súbor `zz-sicherheit.ini` by mohol vyzerať takto:

```ini
expose_php = Off
display_errors = Off
log_errors = On
session.use_strict_mode = 1
session.cookie_httponly = 1
```

Dva ďalšie zásady robia obrazy odolnejšími. Po prvé, dodávaný obraz obsahuje iba to, čo sa potrebuje za behu; kompilátory, cache balíkov a testovacie súbory patria do samostatného stupňa zostavenia. Po druhé, používateľ, pod ktorým PHP beží, smie zapisovať iba tam, kde je to nevyhnutné, napríklad do adresárov na nahrávanie alebo cache na pripojených volumes. Mnohé tímy prevádzkujú kontajner navyše so súborovým systémom chráneným proti zápisu. Votknutý súbor PHP má potom výrazne ťažšie zostať natrvalo a každý reštart obnoví čistý stav obrazu. To nenahrádza vyšetrovanie po incidente, ale citeľne zmenšuje plochu útoku.

## Procesy, pamäť a logy v kontajneri

Tri nastavovacie skrutky rozhodujú o tom, či PHP kontajner beží stabilne.

1. **Počet workerov:** `pm.max_children` v poole FPM určuje, koľko požiadaviek sa vybavuje súčasne. Každý worker môže obsadiť až `memory_limit`.
2. **Limit pamäte kontajnera:** Obmedzuje všetky procesy dohromady. Ako hrubé pravidlo platí: počet workerov krát pamäť na workera plus rezerva musí vojsť pod limit, inak systém procesy ukončí.
3. **Logy:** Kontajnery zapisujú logy na štandardný výstup. V PHP-FPM presmeruje `catch_workers_output = yes` výstupy workerov do hlavného logu; bez tohto nastavenia skončia podľa príručky v prázdne.

Užitočný je aj `request_terminate_timeout`, ktorý jednotlivé požiadavky po určitom čase ukončí, ak `max_execution_time` nezaberie. Ako prevádzkovať kontajnery v klastri, opisuje [Záplatovanie PHP v Kubernetes](https://phpsos.de/sk/server/kubernetes/).

## Kontajnery a bezpečnosť: čo ukázal PHP2Shell

Pri PHP2Shell zohrávajú kontajnery dvojakú úlohu. Na jednej strane sú pomocou: php.net odporúča ako prechodné opatrenie k CVE-2026-109618 kombinovať `memory_limit=-1` s limitom pamäte cez kontajner alebo cgroup, ideálne tak, aby sa ukončil iba dotknutý worker. `RLIMIT_AS` a `RLIMIT_DATA` sú na to podľa php.net nevhodné. Toto opatrenie nie je úplnou ochranou a aktualizáciu nenahrádza.

Na druhej strane sú kontajnery pascou, ak sa obrazy nezostavia znova. Obraz s PHP 8.4.26 zostáva zraniteľný, bez ohľadu na to, ako často sa kontajner reštartuje. Až nové zostavenie na 8.4.27 alebo novšie a výmena všetkých bežiacich kontajnerov zraniteľnosť uzavrie. Stav sa dá skontrolovať priamo v bežiacom kontajneri:

```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"));'
```

Ak posledný príkaz vráti `bool(false)`, PHP nepozná direktívu zavedenú s opravenými verziami; podľa príručky je potom verzia dotknutá. Trvalo pomôže iba automatické nové zostavenie, ako je opísané v [CI/CD: automatické nové zostavenie obrazov PHP](https://phpsos.de/sk/blog/php-images-in-ci-neu-bauen/).

> **Tip:**
> V Dockerfile určte presnú verziu PHP v tagu a zvyšujte ju vedome. V kóde je tak dohľadateľné, kedy sa ktorá verzia nasadila.

## Ako PHP SOS konkrétne pomáha?

Pri [zabezpečení servera pre webové servery PHP](https://phpsos.de/sk/leistungen/server-haertung/) sa staráme aj o kontajnery:

- **Kontrola obrazov:** Základný obraz, verzia PHP, rozšírenia a konfigurácia každého obrazu.
- **Sprísnenie konfigurácie:** Produkčný ini, štíhly zoznam rozšírení, vhodné limity workerov a pamäte.
- **Nastavenie nového zostavovania:** Postup, ktorý obrazy pri nových vydaniach PHP zostaví znova a nasadí.
- **Kontrola za behu:** Dokladujeme, že v každom bežiacom kontajneri beží opravená verzia.


## Časté otázky

**Ktorý variant obrazu PHP je správny?**  
Pre Nginx alebo iný proxy variant fpm, pre jednoduché nasadenie s Apache variant apache, pre skripty a cronjoby variant cli. Varianty Alpine sú menšie, ale stavajú na musl namiesto glibc, čo sa pri niektorých rozšíreniach prejaví.

**Aktualizuje sa PHP v kontajneri automaticky?**  
Nie. Bežiaci kontajner sa nemení. Obraz musíte zostaviť znova s novou verziou PHP a kontajnery reštartovať. Až potom beží opravená verzia.

**Ako spolu súvisia memory_limit a limit kontajnera?**  
memory_limit obmedzuje každú jednotlivú požiadavku PHP, limit kontajnera celý kontajner. Oba musia k sebe pasovať: počet workerov krát pamäť na workera by mal byť pod limitom kontajnera.

**Potrebujem v kontajneroch php.ini?**  
Áno. Oficiálne obrazy dodávajú php.ini-development a php.ini-production ako šablóny. Pre produkciu dokumentácia obrazu výslovne odporúča produkčnú šablónu; vlastné nastavenia patria do conf.d.

## Zdroje

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