# Rad PHP-a u containerima

> Rad PHP-a u containeru: varijante slika, produkcijski php.ini, ekstenzije, ograničenja memorije, zapisnici i ažuriranja. S primjerima i vezom s PHP2Shellom.

Izvor: https://phpsos.de/hr/php/php-in-containern/  
Stanje: 25.10.2026  
Pružatelj: PHP SOS, PHP hitna pomoć i sigurnost poslužitelja. Hitna pomoć putem WhatsAppa: https://wa.me/491736494914?text=Pozdrav%20PHP%20SOS%2C%20trebamo%20pomo%C4%87%20s%20na%C5%A1im%20PHP%20poslu%C5%BEiteljem.%20Tvrtka%3A%20%E2%80%A6%20Web-stranica%3A%20%E2%80%A6

**Ukratko:** Za rad PHP-a u containerima odaberite odgovarajuću varijantu službene slike (`fpm`, `apache` ili `cli`), aktivirajte produkcijski php.ini, instalirajte samo potrebne ekstenzije i postavite granice memorije i procesa koje su međusobno usklađene. Containeri su nepromjenjivi: PHP sigurnosno ažuriranje, kao ono za PHP2Shell, djeluje tek kad se slika iznova izgradi i svaki se container ponovno pokrene. Ta ponovna gradnja zato u svaki rad s containerima pripada kao čvrst proces.

## Zašto PHP u containerima?

Containeri pakiraju PHP, ekstenzije i konfiguraciju u sliku koja na svakom poslužitelju radi jednako. Za poduzeća to znači: manje iznenađenja između testa i produkcije, brži oporavak i jasna stanja verzija. Za sigurnost to ipak znači i novu obvezu: u containeru nitko automatski ne instalira ažuriranja.

Ova stranica obrađuje tekući rad. Kako postojeće containere konkretno zakrpati protiv PHP2Shella, piše na stranici [Zakrpa PHP-a u Docker containerima](https://phpsos.de/hr/php2shell/docker-container-patchen/).

## Odabir prave varijante slike

| Varijanta | Sadržaj | Tipična uporaba |
|---|---|---|
| `php:<version>-fpm` | PHP-FPM, treba web-poslužitelj ispred sebe | produkcija s Nginxom, Caddyjem ili ingressom |
| `php:<version>-apache` | Apache s mod_php-om, prema zadanim postavkama mpm_prefork | jednostavne izvedbe, starije aplikacije |
| `php:<version>-cli` | naredbeni redak, jedina varijanta koja sadrži i php-cgi | cron poslovi, queue workeri, koraci gradnje |
| `…-alpine` | na Alpine Linuxu s musl-om | male slike, kod nekih ekstenzija potrebna prilagodba |
| `…-bookworm`, `…-trixie` | na navedenoj verziji Debiana | čvrsta osnova za ponovljive gradnje |

Za nove projekte u pravilu se preporučuje varijanta `fpm` sa zasebnim containerom web-poslužitelja. Kod mod_php-a PHP tim u vezi s PHP2Shellom vidi najviši rizik; tko koristi sliku `apache`, upravo taj način rada i vodi.

## Izgradnja produkcijske slike

Vitak primjer za aplikaciju s pristupom MySQL-u:

```dockerfile
FROM php:8.4-fpm-alpine

# Aktivirati produkcijsku konfiguraciju (prema dokumentaciji slike dosta preporučeno)
RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"

# Samo potrebne ekstenzije
RUN docker-php-ext-install -j"$(nproc)" pdo_mysql

# Vlastite postavke
COPY zz-sicherheit.ini "$PHP_INI_DIR/conf.d/"

# Kod pripada rootu; FPM workeri rade kao www-data i mogu ga samo čitati
COPY . /var/www/html
```

Pomoćne skripte slike preuzimaju gradnju ekstenzija: `docker-php-ext-configure` za opcije, `docker-php-ext-install` za gradnju, `docker-php-ext-enable` za aktiviranje, primjerice nakon `pecl install`. Ako se s `docker-php-source` raspakira izvorni kod, prema dokumentaciji treba ga obrisati u istom sloju. Datoteka `zz-sicherheit.ini` mogla bi izgledati ovako:

```ini
expose_php = Off
display_errors = Off
log_errors = On
session.use_strict_mode = 1
session.cookie_httponly = 1
```

Još dva načela čine slike otpornijima. Prvo, isporučena slika sadrži samo ono što je potrebno tijekom izvođenja; kompilatori, predmemorije paketa i testne datoteke pripadaju u zasebnu fazu gradnje. Drugo, korisnik pod kojim PHP radi smije pisati samo ondje gdje je nužno, primjerice u direktorije za upload ili cache na priključenim volumenima. Mnogi timovi container dodatno pokreću sa zaštićenim od pisanja datotečnim sustavom. Ubačena PHP datoteka tada se znatno teže trajno zadržava, a svako ponovno pokretanje vraća čisto stanje slike. To ne zamjenjuje istragu nakon incidenta, ali osjetno smanjuje površinu napada.

## Procesi, memorija i zapisnici u containeru

Tri vijka određuju radi li PHP container stabilno.

1. **Broj workera:** `pm.max_children` u FPM poolu određuje koliko se zahtjeva istodobno obrađuje. Svaki worker može zauzeti do `memory_limit`.
2. **Ograničenje memorije containera:** Ograničava sve procese zajedno. Kao gruba pravila vrijedi: broj workera puta memorija po workeru plus rezerva mora stati ispod ograničenja, inače sustav prekida procese.
3. **Zapisnici:** Containeri zapisnike pišu na standardni izlaz. U PHP-FPM-u `catch_workers_output = yes` izlaze workera preusmjerava u glavni zapisnik; bez te postavke prema priručniku nestaju u ništa.

Korisna je i `request_terminate_timeout`, koja pojedine zahtjeve prekida nakon određenog vremena ako `max_execution_time` ne djeluje. Kako containere voditi u klasteru, opisuje [Zakrpa PHP-a u Kubernetesu](https://phpsos.de/hr/server/kubernetes/).

## Containeri i sigurnost: što je pokazao PHP2Shell

Kod PHP2Shella containeri imaju dvostruku ulogu. S jedne strane pomažu: php.net kao prijelaznu mjeru za CVE-2026-109618 preporučuje kombiniranje `memory_limit=-1` s ograničenjem memorije putem containera ili cgroupa, idealno tako da se prekida samo pogođeni worker. `RLIMIT_AS` i `RLIMIT_DATA` prema php.net za to nisu prikladni. Ta mjera nije potpuna zaštita i ne zamjenjuje ažuriranje.

S druge strane, containeri su zamka ako se slike ne grade iznova. Slika s PHP-om 8.4.26 ostaje ranjiva koliko god puta se container ponovno pokrenuo. Tek ponovna gradnja na 8.4.27 ili noviju i zamjena svih pokrenutih containera zatvaraju ranjivost. Stanje se može provjeriti izravno u pokrenutom containeru:

```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"));'
```

Ako posljednja naredba vrati `bool(false)`, PHP ne poznaje direktivu uvedenu s verzijama s ispravkom; prema priručniku je verzija tada pogođena. Trajno pomaže samo automatska ponovna gradnja, kako je opisano u članku [CI/CD: automatska ponovna gradnja PHP slika](https://phpsos.de/hr/blog/php-images-in-ci-neu-bauen/).

> **Savjet:**
> U Dockerfileu točnu verziju PHP-a odredite u tagu i povećavajte je svjesno. Tako je u kodu sljedivo kada je koja verzija puštena.

## Kako PHP SOS konkretno pomaže?

Pri [ojačavanju poslužitelja za PHP web-poslužitelje](https://phpsos.de/hr/leistungen/server-haertung/) brinemo se i za containere:

- **Provjeriti slike:** Osnovna slika, verzija PHP-a, ekstenzije i konfiguracija svake slike.
- **Ojačati konfiguraciju:** Produkcijski ini, vitak popis ekstenzija, odgovarajuće granice workera i memorije.
- **Postaviti ponovnu gradnju:** Tijek koji slike iznova gradi i pušta pri novim PHP izdanjima.
- **Kontrolirati vrijeme izvođenja:** Dokazujemo da u svakom pokrenutom containeru radi ispravljena verzija.


## Česta pitanja

**Koja je varijanta PHP slike prava?**  
Za Nginx ili drugi proxy varijanta fpm, za jednostavnu izvedbu s Apacheom varijanta apache, za skripte i cron poslove varijanta cli. Alpine varijante su manje, ali se temelje na musl umjesto glibc, što kod nekih ekstenzija dolazi do izražaja.

**Ažurira li se PHP u containeru automatski?**  
Ne. Pokrenuti container se ne mijenja. Morate iznova izgraditi sliku s novom verzijom PHP-a i ponovno pokrenuti containere. Tek tada radi ispravljena verzija.

**Kako se odnose memory_limit i ograničenje containera?**  
memory_limit ograničava svaki pojedini PHP zahtjev, a ograničenje containera cijeli container. Oba se moraju uskladiti: broj workera puta memorija po workeru trebao bi biti ispod ograničenja containera.

**Treba li mi php.ini u containerima?**  
Da. Službene slike isporučuju php.ini-development i php.ini-production kao predloške. Za produkciju dokumentacija slike izričito preporučuje produkcijski predložak; vlastite postavke idu u conf.d.

## Izvori

- [Docker Official Image: PHP](https://hub.docker.com/_/php)
- [PHP priručnik: FPM konfiguracija](https://www.php.net/manual/en/install.fpm.configuration.php)
- [php.net: Sigurnosna obavijest od 21. 10. 2026.](https://www.php.net/)
