# PHP üzemeltetése konténerekben

> PHP üzemeltetése konténerben: képváltozatok, éles php.ini, bővítmények, memóriahatárok, naplók és frissítések. Példákkal és PHP2Shell-kapcsolattal.

Forrás: https://phpsos.de/hu/php/php-in-containern/  
Á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:** Ha a PHP-t konténerekben üzemelteti, válassza ki a hivatalos kép megfelelő változatát (`fpm`, `apache` vagy `cli`), kapcsolja be az éles php.ini-t, csak a szükséges bővítményeket telepítse, és olyan memória- és folyamathatárokat állítson be, amelyek illeszkednek egymáshoz. A konténerek megváltoztathatatlanok: egy PHP-os biztonsági frissítés, mint a PHP2Shellhez tartozó, csak akkor hat, ha a képet újraépítették, és minden konténert újraindítottak. Ez az újraépítés ezért fix folyamatként minden konténeres üzem része legyen.

## Miért PHP a konténerekben?

A konténerek a PHP-t, a bővítményeket és a konfigurációt egyetlen képbe csomagolják, amely minden szerveren ugyanúgy fut. A vállalatoknak ez kevesebb meglepetést jelent a teszt és az éles üzem között, gyorsabb helyreállítást és világos verzióállapotokat. A biztonság szempontjából viszont új kötelezettséget is jelent: a konténerben senki nem telepít automatikusan frissítéseket.

Ez az oldal a folyamatos üzemmel foglalkozik. Hogyan javíthatja meg konkrétan a meglévő konténereket a PHP2Shell ellen, azt a [PHP javítása Docker-konténerekben](https://phpsos.de/hu/php2shell/docker-container-patchen/) oldal írja le.

## A megfelelő képváltozat kiválasztása

| Változat | Tartalom | Tipikus felhasználás |
|---|---|---|
| `php:<version>-fpm` | PHP-FPM, előtte webszerver kell | éles üzem Nginxszel, Caddyvel vagy ingresszel |
| `php:<version>-apache` | Apache mod_php-val, alapértelmezés szerint mpm_prefork | egyszerű felépítések, régebbi alkalmazások |
| `php:<version>-cli` | parancssor, egyedül ez a változat tartalmazza a php-cgi-t is | cronjobok, queue-workerek, build-lépések |
| `…-alpine` | Alpine Linuxon musl-lal | kis képek, egyes bővítményeknél módosítások szükségesek |
| `…-bookworm`, `…-trixie` | a megnevezett Debian-verzión | fix alap a reprodukálható buildekhez |

Új projektekhez általában az `fpm`-változat ajánlott külön webszerver-konténerrel. A mod_php-nál a PHP-csapat a PHP2Shell kapcsán a legmagasabb kockázatot látja; aki az `apache` képet használja, éppen ezt az üzemmódot üzemelteti.

## Éles kép építése

Egy karcsú példa egy MySQL-hozzáférésű alkalmazáshoz:

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

# Az éles konfiguráció bekapcsolása (a képdokumentáció szerint erősen ajánlott)
RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"

# Csak a szükséges bővítmények
RUN docker-php-ext-install -j"$(nproc)" pdo_mysql

# Saját beállítások
COPY zz-sicherheit.ini "$PHP_INI_DIR/conf.d/"

# A kód a rooté; az FPM-workerek www-data-ként futnak, és csak olvasni tudják
COPY . /var/www/html
```

A kép segédszkriptjei átveszik a bővítmények építését: a `docker-php-ext-configure` az opciókhoz, a `docker-php-ext-install` az építéshez, a `docker-php-ext-enable` a bekapcsoláshoz, például egy `pecl install` után. Ha a `docker-php-source`-szal kicsomagolják a forráskódot, a dokumentáció szerint ugyanabban a rétegben ismét törölni kell. A `zz-sicherheit.ini` fájl így nézhet ki:

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

Két további alapelv teszi robusztusabbá a képeket. Először, a kiszállított kép csak azt tartalmazza, amit futásidőben használnak; a fordítók, a csomaggyorsítótárak és a tesztfájlok külön build-szakaszba valók. Másodszor, az a felhasználó, amelyként a PHP fut, csak ott írhat, ahol szükséges, például a feltöltési vagy gyorsítótár-könyvtárakban a csatolt volume-okon. Sok csapat emellett írásvédett fájlrendszerrel üzemelteti a konténert. Egy beszivárogtatott PHP-fájlnak ekkor sokkal nehezebb tartósan megmaradnia, és minden újraindítás visszaállítja a kép tiszta állapotát. Ez nem helyettesíti az incidens utáni vizsgálatot, de érezhetően csökkenti a támadási felületet.

## Folyamatok, memória és naplók a konténerben

Három állítócsavar dönti el, hogy egy PHP-konténer stabilan fut-e.

1. **A workerek száma:** az FPM-pool `pm.max_children` értéke határozza meg, hány kérést dolgoznak fel egyidejűleg. Minden worker legfeljebb a `memory_limit`-ig foglalhat.
2. **A konténer memóriahatára:** az összes folyamatot együtt korlátozza. Durva szabály: a workerek száma szorozva a workerenkénti memóriával plusz tartalék a korlát alá kell, hogy férjen, különben a rendszer folyamatokat állít le.
3. **Naplók:** a konténerek a naplókat a szabványos kimenetre írják. A PHP-FPM-ben a `catch_workers_output = yes` a workerek kimeneteit a fő naplóba irányítja; e beállítás nélkül a kézikönyv szerint a semmibe vesznek.

Hasznos emellett a `request_terminate_timeout`, amely egy időtartam után leállítja az egyes kéréseket, ha a `max_execution_time` nem érvényesül. Hogyan üzemeltethet konténereket fürtben, azt a [PHP javítása Kubernetesben](https://phpsos.de/hu/server/kubernetes/) írja le.

## Konténerek és biztonság: amit a PHP2Shell megmutatott

A PHP2Shellnél a konténerek kettős szerepet játszanak. Egyfelől segítséget jelentenek: a php.net a CVE-2026-109618 elleni átmeneti intézkedésként azt ajánlja, hogy a `memory_limit=-1` értéket konténeren vagy cgroupon keresztüli memóriahatárral kombinálják, ideális esetben úgy, hogy csak az érintett worker álljon le. Az `RLIMIT_AS` és az `RLIMIT_DATA` erre a php.net szerint alkalmatlan. Ez az intézkedés nem teljes védelem, és nem helyettesíti a frissítést.

Másfelől a konténerek csapdát jelentenek, ha a képeket nem építik újra. Egy PHP 8.4.26-os kép sebezhető marad, akárhányszor indul újra a konténer. Csak a 8.4.27-re vagy újabbra való újraépítés és az összes futó konténer cseréje zárja be a rést. Az állapotot közvetlenül a futó konténerben lehet ellenőrizni:

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

Ha az utolsó parancs `bool(false)` értéket ad, a PHP nem ismeri a javított verziókkal bevezetett direktívát; a kézikönyv szerint a verzió ilyenkor érintett. Tartósan csak az automatikus újraépítés segít, ahogyan a [CI/CD: PHP-képek automatikus újraépítése](https://phpsos.de/hu/blog/php-images-in-ci-neu-bauen/) cikk leírja.

> **Tipp:**
> A Dockerfile-ban a pontos PHP-verziót rögzítse a tagben, és tudatosan emelje. Így a kódban nyomon követhető, mikor melyik verziót állították üzembe.

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

A [PHP-webszerverek keményítésénél](https://phpsos.de/hu/leistungen/server-haertung/) a konténerekkel is foglalkozunk:

- **Képek ellenőrzése:** az alapkép, a PHP-verzió, a bővítmények és az egyes képek konfigurációja.
- **A konfiguráció keményítése:** éles ini, karcsú bővítménylista, megfelelő worker- és memóriahatárok.
- **Az újraépítés beállítása:** olyan folyamat, amely az új PHP-kiadásoknál újraépíti és kiadja a képeket.
- **Futásidő ellenőrzése:** igazoljuk, hogy minden futó konténerben a javított verzió fut.


## Gyakori kérdések

**Melyik a megfelelő PHP-képváltozat?**  
Nginxhez vagy más proxyhoz az fpm-változat, Apache-csal egyszerű felépítéshez az apache-változat, szkriptekhez és cronjobokhoz a cli-változat. Az Alpine-változatok kisebbek, de glibc helyett musl-ra épülnek, ami egyes bővítményeknél feltűnik.

**Automatikusan frissül a PHP a konténerben?**  
Nem. Egy futó konténer nem változik. A képet az új PHP-verzióval újra kell építeni, és a konténereket újra kell indítani. Csak ezután fut a javított verzió.

**Hogyan viszonyul egymáshoz a memory_limit és a konténerkorlát?**  
A memory_limit minden egyes PHP-kérést korlátoz, a konténerkorlát az egész konténert. Kettőjüknek illeszkednie kell: a workerek száma szorozva a workerenkénti memóriával a konténerkorlát alatt legyen.

**Kell php.ini a konténerekben?**  
Igen. A hivatalos képek a php.ini-development és a php.ini-production sablont mellékelik. Éles üzemre a képdokumentáció kifejezetten az éles sablont ajánlja; a saját beállítások a conf.d-be kerülnek.

## Források

- [Docker Official Image: PHP](https://hub.docker.com/_/php)
- [PHP-kézikönyv: FPM-konfiguráció](https://www.php.net/manual/en/install.fpm.configuration.php)
- [php.net: Biztonsági közlemény, 2026. 10. 21.](https://www.php.net/)