Kort sagt: För att driva PHP i containrar väljer ni lämplig variant av den officiella imagen (fpm, apache eller cli), aktiverar produktions-php.ini, installerar bara nödvändiga tillägg och sätter minnes- och proceßgränser som passar ihop. Containrar är oföränderliga: En PHP-säkerhetsuppdatering som den för PHP2Shell verkar först när imagen har byggts om och varje container har startats om. Ombyggnaden hör därför som fast process hemma i all containerdrift.
Varför PHP i containrar?
Containrar paketerar PHP, tillägg och konfiguration i en image som körs lika på varje server. För företag betyder det: färre överraskningar mellan test och produktion, snabbare återställning och tydliga versionslägen. För säkerheten betyder det dock också en ny skyldighet: Ingen installerar automatiskt uppdateringar i en container.
Den här sidan behandlar den löpande driften. Hur ni konkret patchar befintliga containrar mot PHP2Shell står under Patcha PHP i Docker-containrar.
Välja rätt image-variant
| Variant | Innehåll | Typisk användning |
|---|---|---|
php:<version>-fpm |
PHP-FPM, kräver en förkopplad webbserver | produktion med Nginx, Caddy eller en ingress |
php:<version>-apache |
Apache med mod_php, som standard mpm_prefork | enkla uppbyggnader, äldre applikationer |
php:<version>-cli |
kommandorad, innehåller som enda variant även php-cgi | cronjobs, kö-workers, byggsteg |
…-alpine |
på Alpine Linux med musl | små images, vid vissa tillägg behövs anpassningar |
…-bookworm, …-trixie |
på den angivna Debian-versionen | fast bas för reproducerbara byggen |
För nya projekt rekommenderas i regel fpm-varianten med separat webbservercontainer. Vid mod_php ser PHP-teamet i samband med PHP2Shell den högsta risken; den som använder apache-imagen driver just det driftläget.
Bygga en produktions-image
Ett slimmat exempel för en applikation med MySQL-åtkomst:
FROM php:8.4-fpm-alpine
# Aktivera produktionskonfigurationen (enligt image-dokumentationen starkt rekommenderat)
RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"
# Endast nödvändiga tillägg
RUN docker-php-ext-install -j"$(nproc)" pdo_mysql
# Egna inställningar
COPY zz-sicherheit.ini "$PHP_INI_DIR/conf.d/"
# Koden ägs av root; FPM-workers körs som www-data och kan bara läsa den
COPY . /var/www/html
Imagens hjälpskript tar hand om att bygga tillägg: docker-php-ext-configure för alternativ, docker-php-ext-install för att bygga, docker-php-ext-enable för att aktivera, till exempel efter pecl install. Packas källkoden upp med docker-php-source bör den enligt dokumentationen raderas igen i samma lager. Filen zz-sicherheit.ini kan se ut så här:
expose_php = Off
display_errors = Off
log_errors = On
session.use_strict_mode = 1
session.cookie_httponly = 1
Två ytterligare principer gör images mer robusta. För det första innehåller den levererade imagen bara det som behövs vid körning; kompilatorer, paketcacher och testfiler hör hemma i ett eget byggsteg. För det andra får användaren som PHP körs som bara skriva där det är nödvändigt, till exempel i uppladdnings- eller cachekataloger på monterade volymer. Många team driver dessutom containern med skrivskyddat filsystem. En inplanterad PHP-fil har det då betydligt svårare att bli kvar, och varje omstart återställer imagens rena läge. Det ersätter ingen undersökning efter en incident men minskar angreppsytan märkbart.
Processer, minne och loggar i containern
Tre skruvar avgör om en PHP-container körs stabilt.
- Antal workers:
pm.max_childreni FPM-poolen anger hur många förfrågningar som hanteras samtidigt. Varje worker kan uppta upp tillmemory_limit. - Containerns minnesgräns: Den begränsar alla processer tillsammans. Som grov regel gäller: Antal workers gånger minne per worker plus reserv måste rymmas under gränsen, annars avslutar systemet processer.
- Loggar: Containrar skriver loggar till standardutdata. I PHP-FPM skickar
catch_workers_output = yesworkers utdata till huvudloggen; utan inställningen försvinner den enligt manualen i intet.
Användbart är dessutom request_terminate_timeout, som avslutar enskilda förfrågningar efter en tidsrymd när max_execution_time inte slår till. Hur ni driver containrar i kluster beskriver Patcha PHP i Kubernetes.
Containrar och säkerhet: vad PHP2Shell har visat
Vid PHP2Shell spelar containrar en dubbel roll. Dels är de en hjälp: php.net rekommenderar som tillfällig åtgärd för CVE-2026-109618 att kombinera memory_limit=-1 med en minnesgräns via container eller cgroup, helst så att bara den drabbade workern avslutas. RLIMIT_AS och RLIMIT_DATA är enligt php.net olämpliga för det. Den här åtgärden är inget fullständigt skydd och ersätter inte uppdateringen.
Dels är containrar en fälla om images inte byggs om. En image med PHP 8.4.26 förblir sårbar, oavsett hur ofta containern startas om. Först en ombyggnad till 8.4.27 eller nyare och utbyte av alla körande containrar stänger luckan. Läget kan kontrolleras direkt i den körande containern:
docker exec <container> php -v
docker exec <container> php-fpm -v
docker exec <container> php -r 'var_dump(ini_get("memory_hard_limit_percent"));'
Ger det sista kommandot bool(false) känner PHP inte till direktivet som infördes med de åtgärdade versionerna; enligt manualen är versionen då drabbad. Varaktigt hjälper bara en automatisk ombyggnad, som beskrivet under CI/CD: bygg om PHP-images automatiskt.
Fastlägg den exakta PHP-versionen i taggen i Dockerfile och höj den medvetet. Då går det att följa i koden när vilken version rullades ut.
Hur hjälper PHP SOS konkret?
Vid serverhärdning för PHP-webbservrar tar vi hand även om containrar:
- Kontrollera images: Basimage, PHP-version, tillägg och konfiguration för varje image.
- Härda konfigurationen: Produktions-ini, slimmad tilläggslista, lämpliga worker- och minnesgränser.
- Ställa in ombyggnad: Ett förlopp som bygger om och rullar ut images vid nya PHP-releaser.
- Kontrollera körmiljön: Vi styrker att den rättade versionen körs i varje körande container.
Vanliga frågor
Vilken variant av PHP-imagen är rätt?
För Nginx eller en annan proxy fpm-varianten, för en enkel uppbyggnad med Apache apache-varianten, för skript och cronjobs cli-varianten. Alpine-varianter är mindre men bygger på musl i stället för glibc, vilket märks hos vissa tillägg.
Uppdateras PHP i containern automatiskt?
Nej. En körande container ändras inte. Ni måste bygga om imagen med den nya PHP-versionen och starta om containrarna. Först då körs den rättade versionen.
Hur förhåller sig memory_limit till containergränsen?
memory_limit begränsar varje enskild PHP-förfrågan, containergränsen hela containern. Båda måste passa ihop: Antalet workers gånger minne per worker bör ligga under containergränsen.
Behöver jag en php.ini i containrar?
Ja. De officiella images levererar php.ini-development och php.ini-production som mallar. För produktion rekommenderar image-dokumentationen uttryckligen produktionsmallen; egna inställningar läggs i conf.d.