# Obratovanje PHP v vsebnikih

> PHP v vsebniku: različice slik, produkcijski php.ini, razširitve, meje pomnilnika, dnevniki in posodobitve. S primeri in povezavo s PHP2Shell.

Vir: https://phpsos.de/sl/php/php-in-containern/  
Stanje: 25.10.2026  
Ponudnik: PHP SOS, Nujna pomoč za PHP in varnost strežnikov. Takojšnja pomoč po WhatsAppu: https://wa.me/491736494914?text=Pozdravljeni%2C%20PHP%20SOS%2C%20potrebujemo%20pomo%C4%8D%20z%20na%C5%A1im%20stre%C5%BEnikom%20PHP.%20Podjetje%3A%20%E2%80%A6%20Spletna%20stran%3A%20%E2%80%A6

**Na kratko:** Za obratovanje PHP v vsebnikih izberite ustrezno različico uradne slike (`fpm`, `apache` ali `cli`), vklopite produkcijski php.ini, namestite samo potrebne razširitve in nastavite meje pomnilnika in procesov, ki se med seboj ujemajo. Vsebniki so nespremenljivi: varnostna posodobitev PHP, kot tista za PHP2Shell, učinkuje šele, ko je slika zgrajena znova in je vsak vsebnik znova zagnan. Ta ponovna gradnja zato sodi kot fiksen postopek v vsako obratovanje vsebnikov.

## Zakaj PHP v vsebnikih?

Vsebniki PHP, razširitve in konfiguracijo zapakirajo v sliko, ki na vsakem strežniku teče enako. Za podjetja to pomeni: manj presenečenj med testom in produkcijo, hitrejša obnovitev in jasna stanja različic. Za varnost pa pomeni tudi novo obveznost: v vsebniku nihče samodejno ne nameša posodobitev.

Ta stran obravnava tekoče obratovanje. Kako obstoječe vsebnike konkretno popraviti proti PHP2Shell, je pod [Popravljanje PHP v vsebnikih Docker](https://phpsos.de/sl/php2shell/docker-container-patchen/).

## Izbira prave različice slike

| Različica | Vsebina | Tipična uporaba |
|---|---|---|
| `php:<version>-fpm` | PHP-FPM, potrebuje predhodni spletni strežnik | produkcija z Nginxom, Caddyjem ali ingressom |
| `php:<version>-apache` | Apache z mod_php, privzeto mpm_prefork | preproste postavitve, starejše aplikacije |
| `php:<version>-cli` | ukazna vrstica, kot edina različica vsebuje tudi php-cgi | cronjobi, delavci čakalnih vrst, koraki gradnje |
| `…-alpine` | na Alpine Linux z musl | majhne slike, pri nekaterih razširitvah potrebne prilagoditve |
| `…-bookworm`, `…-trixie` | na navedeni različici Debian | fiksna osnova za ponovljive gradnje |

Za nove projekte se praviloma priporoča različica `fpm` z ločenim vsebnikom spletnega strežnika. Pri mod_php ekipa PHP v zvezi s PHP2Shell vidi najvišje tveganje; kdor uporablja sliko `apache`, deluje ravno v tem načinu.

## Gradnja produkcijske slike

Vitek primer za aplikacijo z dostopom do MySQL:

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

# Vklopiti produkcijsko konfiguracijo (po dokumentaciji slike nujno priporočeno)
RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"

# Samo potrebne razširitve
RUN docker-php-ext-install -j"$(nproc)" pdo_mysql

# Lastne nastavitve
COPY zz-sicherheit.ini "$PHP_INI_DIR/conf.d/"

# Koda pripada uporabniku root; workerji FPM tečejo kot www-data in jo lahko samo berejo
COPY . /var/www/html
```

Pomožne skripte slike prevzamejo gradnjo razširitev: `docker-php-ext-configure` za možnosti, `docker-php-ext-install` za gradnjo, `docker-php-ext-enable` za vklop, na primer po `pecl install`. Če se z `docker-php-source` razpakira izvorna koda, jo je treba po dokumentaciji v isti plasti znova izbrisati. Datoteka `zz-sicherheit.ini` bi lahko izgledala takole:

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

Dve nadaljnji načeli slike naredita robustnejše. Prvič, dostavljena slika vsebuje samo to, kar je potrebno med izvajanjem; prevajalniki, predpomnilniki paketov in testne datoteke sodijo v lastno stopnjo gradnje. Drugič, uporabnik, pod katerim teče PHP, sme pisati samo tam, kjer je potrebno, na primer v imenikih za nalaganje ali predpomnilnik na vključenih nosilcih (volume). Številne ekipe vsebnik dodatno poganjajo z datotečnim sistemom, zaščitenim pred pisanjem. Vrinjeni datoteki PHP je tedaj bistveno težje ostati trajno, vsak ponovni zagon pa znova vzpostavi čisto stanje slike. To ne nadomesti preiskave po incidentu, opazno pa zmanjša napadalno površino.

## Procesi, pomnilnik in dnevniki v vsebniku

Tri nastavitve določajo, ali vsebnik PHP stabilno teče.

1. **Število workerjev:** `pm.max_children` v poolu FPM določa, koliko zahtev se obdeluje hkrati. Vsak worker lahko zaseda do `memory_limit`.
2. **Meja pomnilnika vsebnika:** omejuje vse procese skupaj. Kot groba velja: število workerjev krat pomnilnik na workerja plus rezerva mora ustrezati meji, sicer sistem procese konča.
3. **Dnevniki:** vsebniki dnevnike pišejo na standardni izhod. V PHP-FPM `catch_workers_output = yes` izpise workerjev preusmeri v glavni dnevnik; brez te nastavitve po priročniku pristanejo v nič.

Koristen je tudi `request_terminate_timeout`, ki posamezne zahteve po določenem času konča, kadar `max_execution_time` ne deluje. Kako vsebnike obratovati v gruči, opisuje [Popravljanje PHP v Kubernetes](https://phpsos.de/sl/server/kubernetes/).

## Vsebniki in varnost: kaj je pokazal PHP2Shell

Pri PHP2Shell imajo vsebniki dvojno vlogo. Na eni strani so pomoč: php.net kot prehodni ukrep za CVE-2026-109618 priporoča kombinacijo `memory_limit=-1` z mejo pomnilnika prek vsebnika ali cgroup, idealno tako, da se konča samo prizadeti worker. `RLIMIT_AS` in `RLIMIT_DATA` sta za to po php.net neprimerna. Ta ukrep ni popolna zaščita in posodobitve ne nadomesti.

Na drugi strani so vsebniki past, če se slike ne zgradijo znova. Slika s PHP 8.4.26 ostane ranljiva, ne glede na to, kako pogosto se vsebnik znova zažene. Šele ponovna gradnja na 8.4.27 ali novejši in zamenjava vseh tekočih vsebnikov vrzel zapreta. Stanje je mogoče preveriti neposredno v tekočem vsebniku:

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

Če zadnji ukaz vrne `bool(false)`, PHP ne pozna direktive, uvedene s popravljenimi različicami; po priročniku je različica tedaj prizadeta. Trajno pomaga samo samodejna ponovna gradnja, kot je opisana pod [CI/CD: samodejna ponovna gradnja slik PHP](https://phpsos.de/sl/blog/php-images-in-ci-neu-bauen/).

> **Nasvet:**
> V Dockerfile določite natančno različico PHP v oznaki in jo zvišujte zavestno. Tako je v kodi sledljivo, kdaj je bila katera različica razdeljena.

## Kako PHP SOS pomaga konkretno?

Pri [utrjevanju strežnikov PHP](https://phpsos.de/sl/leistungen/server-haertung/) skrbimo tudi za vsebnike:

- **Preveriti slike:** osnovna slika, različica PHP, razširitve in konfiguracija vsake slike.
- **Utrditi konfiguracijo:** produkcijski ini, vitek seznam razširitev, ustrezne meje workerjev in pomnilnika.
- **Vzpostaviti ponovno gradnjo:** potek, ki slike ob novih izdajah PHP zgradi znova in jih razdeli.
- **Nadzorovati izvajalno okolje:** dokažemo, da v vsakem tekočem vsebniku teče popravljena različica.


## Pogosta vprašanja

**Katera različica slike PHP je prava?**  
Za Nginx ali drug proxy različica fpm, za preprosto postavitev z Apacheem različica apache, za skripte in cronjobe različica cli. Različice Alpine so manjše, a temeljijo na musl namesto glibc, kar pri nekaterih razširitvah pride do izraza.

**Ali se PHP v vsebniku posodablja samodejno?**  
Ne. Tekoči vsebnik se ne spreminja. Sliko z novo različico PHP je treba zgraditi znova in vsebnike znova zagnati. Šele potem teče popravljena različica.

**Kako sta povezana memory_limit in meja vsebnika?**  
memory_limit omejuje vsako posamezno zahtevo PHP, meja vsebnika pa celoten vsebnik. Obe se morata ujemati: število workerjev krat pomnilnik na workerja naj bo pod mejo vsebnika.

**Ali v vsebnikih potrebujem php.ini?**  
Da. Uradne slike kot predlogi prinašajo php.ini-development in php.ini-production. Za produkcijo dokumentacija slik izrecno priporoča produkcijsko predlogo; lastne nastavitve pridejo v conf.d.

## Viri

- [Docker Official Image: PHP](https://hub.docker.com/_/php)
- [Priročnik PHP: konfiguracija FPM](https://www.php.net/manual/en/install.fpm.configuration.php)
- [php.net: varnostno obvestilo z dne 21. 10. 2026](https://www.php.net/)