Containerisering af en PHP-applikation

Reproducerbar levering af PHP betyder, at du fastfryser den præcise version af fortolkeren, udvidelserne og operativsystemets biblioteker sammen med koden. Et Docker-image giver alle miljøer — bærbar, CI og produktion — den samme php -v og det samme sæt ext-*.

I denne lektion bygger vi et produktionsklart image: PHP-FPM, kun de udvidelser du har brug for, tilpassede konfigurationer, en bruger uden root-rettigheder og et sundhedstjek.

De officielle PHP-images fås i flere varianter. Til en produktionswebapp bag nginx/traefik skal du foretrække php:8.3-fpm-alpine (lille) eller php:8.3-fpm (Debian, glibc — færre overraskelser med native biblioteker).

• cli — arbejdere, køer og cron
• fpm — FastCGI-procesadministrator, bruges sammen med nginx
• apache — medfølgende Apache, praktisk, men tungere

Fastlås delversionen. Brug aldrig :latest i produktionen.

Kør aldrig apt install php-xxx i disse images — brug de medfølgende hjælpeværktøjer docker-php-ext-install, docker-php-ext-configure og pecl. Scriptet install-php-extensions (mlocati) er den de facto-genvej, der henter de rigtige headerfiler til udvikling for dig.

Kopiér Composer-binærfilen fra det officielle image i stedet for at hente et installationsprogram med curl. Kør composer install med --no-dev og --optimize-autoloader til produktion, og kopiér først kun composer.json/composer.lock, så afhængighedslaget kan cachelagres uafhængigt af ændringer i kildekoden.

Grundimaget indeholder skabelonerne php.ini-production og php.ini-development. Aktivér produktionsversionen, og læg derefter dine egne tilsidesættelser i conf.d — den mappe flettes ind til sidst, så dens værdier vinder.

Vigtige produktionsværdier: opcache.enable=1, opcache.validate_timestamps=0 (uforanderlig kode i imaget) og en fornuftig memory_limit.

Dette er den største enkeltstående gevinst i produktionen. Med validate_timestamps=0 tjekker PHP aldrig filerne ved hver forespørgsel — men det betyder, at du SKAL genopbygge imaget for at implementere ændringer (hvilket netop er det, vi ønsker med uforanderlige containere).

Imaget definerer allerede www-data. At køre FPM som root øger angrebsfladen unødvendigt. Indstil ejerskabet for skrivbare stier (cache og logfiler), og skift bruger med USER før CMD.

Binder FPM's masterproces stadig til privilegerede porte? Nej — FPM lytter på 9000 (en ikkeprivilegeret port), så det er ligetil at køre uden root.

Orkestreringsværktøjer har brug for et signal om, at FPM rent faktisk er aktiv, ikke kun at processen eksisterer. cgi-fcgi kan pinge FPM's /status- eller /ping-endepunkt. Aktivér først pm.status_path og ping.path i FPM-poolen.

Her er en sammenhængende Dockerfil til produktion i ét trin. I næste lektion opdeler du den i flere trin for at fjerne buildværktøjer. Bemærk rækkefølgen: afhængigheder → konfiguration → kildekode → autoload → skift af bruger.

Efter buildet kan du lave et hurtigt plausibilitetstjek af, hvad der faktisk er kommet med i imaget: PHP-versionen, indlæste udvidelser og at validering af OPcache er slået fra. Et hurtigt CLI-script bekræfter den kørselskontrakt, som din app afhænger af.

En .dockerignore holder din buildkontekst lille og forhindrer hemmeligheder og unødvendige leverandørfiler i at lække ind i imaget og ødelægge cachen. Udeluk vendor, versionsstyringsfiler, miljøfiler og lokale værktøjer.

Du har bygget et PHP-FPM-image til produktion: et fastlåst 8.3-fpm-alpine-basisimage, installeret kun nødvendige udvidelser via installationsscriptet, kopieret Composer og cachede afhængigheder i deres eget lag, aktiveret produktions-php.ini med en OPcache-tilsidesættelse, skiftet til www-data og tilføjet et FPM-sundhedstjek.

Vigtige vaner: lås versioner, cache afhængighedslaget, kør uden root-bruger, deaktivér validering af tidsstempler, og hold buildkonteksten slank med .dockerignore.