PHP darbināšana konteineros

Īsi: lai PHP darbinātu konteineros, izvēlieties piemērotu oficiālā attēla variantu (fpm, apache vai cli), aktivizējiet produkcijas php.ini, instalējiet tikai nepieciešamos paplašinājumus un iestatiet atmiņas un procesu robežas, kas savstarpēji saskan. Konteineri ir nemainīgi: PHP drošības atjauninājums, piemēram, saistībā ar PHP2Shell, iedarbojas tikai tad, kad attēls ir pārbūvēts un katrs konteiners pārstartēts. Šī pārbūve tāpēc kā stingrs process jāiekļauj katrā konteineru darbībā.

Kāpēc PHP konteineros?

Konteineri iepako PHP, paplašinājumus un konfigurāciju attēlā, kas katrā serverī darbojas vienādi. Uzņēmumiem tas nozīmē: mazāk pārsteigumu starp testu un produkciju, ātrāka atjaunošana un skaidri versiju stāvokļi. Drošībai tas tomēr nozīmē arī jaunu pienākumu: konteinerā neviens atjauninājumus neievieš automātiski.

Šī lapa aplūko ikdienas darbību. Kā esošos konteinerus konkrēti ielāpot pret PHP2Shell, rakstīts sadaļā PHP ielāpošana Docker konteineros.

Pareizā attēla varianta izvēle

Jauniem projektiem parasti ieteicams fpm variants ar atsevišķu tīmekļa servera konteineru. Mod_php gadījumā PHP komanda saistībā ar PHP2Shell saskata augstāko risku; kas lieto apache attēlu, darbina tieši šo darbības režīmu.

Produkcijas attēla būvēšana

Viegls piemērs lietojumprogrammai ar MySQL piekļuvi:

FROM php:8.4-fpm-alpine

# Aktivizēt produkcijas konfigurāciju (saskaņā ar attēla dokumentāciju stingri ieteicams)
RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"

# Tikai nepieciešamie paplašinājumi
RUN docker-php-ext-install -j"$(nproc)" pdo_mysql

# Paša iestatījumi
COPY zz-sicherheit.ini "$PHP_INI_DIR/conf.d/"

# Kods pieder root; FPM darbprocesi darbojas kā www-data un var to tikai lasīt
COPY . /var/www/html

Attēla palīgskripti uzņemas paplašinājumu būvēšanu: docker-php-ext-configure opcijām, docker-php-ext-install būvēšanai, docker-php-ext-enable aktivizēšanai, piemēram, pēc pecl install. Ja ar docker-php-source tiek izpakots pirmkods, tas saskaņā ar dokumentāciju jāizdzēš tajā pašā slānī. Fails zz-sicherheit.ini varētu izskatīties šādi:

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

Divi papildu principi attēlus dara noturīgākus. Pirmkārt, piegādātais attēls satur tikai to, kas vajadzīgs izpildes laikā; kompilatori, pakotņu kešatmiņas un testa faili pieder atsevišķam būvēšanas posmam. Otrkārt, lietotājs, ar kuru darbojas PHP, drīkst rakstīt tikai tur, kur nepieciešams, piemēram, augšupielāžu vai kešatmiņas direktorijos uz pievienotajiem volume. Daudzas komandas konteineru papildus darbina ar tikai lasāmu failu sistēmu. Ievadītam PHP failam tad ir ievērojami grūtāk palikt pastāvīgi, un katra pārstartēšana atjauno attēla tīro stāvokli. Tas neaizstāj izmeklēšanu pēc incidenta, bet manāmi samazina uzbrukuma virsmu.

Procesi, atmiņa un žurnāli konteinerā

Trīs regulējamas lietas nosaka, vai PHP konteiners darbojas stabili.

1. Darbprocesu skaits: pm.max_children FPM pūlā nosaka, cik pieprasījumu tiek apstrādāti vienlaikus. Katrs darbprocess var aizņemt līdz memory_limit.
2. Konteinera atmiņas robeža: tā ierobežo visus procesus kopā. Kā aptuvens noteikums: darbprocesu skaitam, reizinātam ar atmiņu katram darbprocesam, plus rezerve jāietilpst limitā, citādi sistēma pārtrauc procesus.
3. Žurnāli: konteineri raksta žurnālus uz standarta izvadi. PHP-FPM catch_workers_output = yes darbprocesu izvadi novirza uz galveno žurnālu; bez šī iestatījuma tā saskaņā ar rokasgrāmatu pazūd tukšumā.

Noder arī request_terminate_timeout, kas atsevišķus pieprasījumus pārtrauc pēc laika sprīža, ja max_execution_time neiedarbojas. Kā darbināt konteinerus klasterī, apraksta PHP ielāpošana Kubernetes.

Konteineri un drošība: ko parādīja PHP2Shell

PHP2Shell gadījumā konteineriem ir dubulta loma. No vienas puses, tie palīdz: php.net kā pagaidu pasākumu attiecībā uz CVE-2026-109618 iesaka memory_limit=-1 apvienot ar atmiņas robežu caur konteineru vai cgroup, ideālā gadījumā tā, lai tiktu pārtraukts tikai skartais darbprocess. RLIMIT_AS un RLIMIT_DATA šim nolūkam saskaņā ar php.net nav piemēroti. Šis pasākums nav pilnīga aizsardzība un neaizstāj atjauninājumu.

No otras puses, konteineri ir slazds, ja attēli netiek pārbūvēti. Attēls ar PHP 8.4.26 paliek ievainojams, lai cik reižu konteiners tiktu pārstartēts. Tikai pārbūve uz 8.4.27 vai jaunāku un visu darbojošos konteineru nomaiņa aizver ievainojamību. Stāvokli var pārbaudīt tieši darbojošā konteinerā:

docker exec <container> php -v
docker exec <container> php-fpm -v
docker exec <container> php -r 'var_dump(ini_get("memory_hard_limit_percent"));'

Ja pēdējā komanda atgriež bool(false), PHP nepazīst direktīvu, kas ieviesta ar labotajām versijām; saskaņā ar rokasgrāmatu versija tad ir skarta. Ilgtermiņā palīdz tikai automātiska pārbūve, kā aprakstīts sadaļā CI/CD: PHP attēlu automātiska pārbūve.

Kā PHP SOS palīdz konkrēti?

Servera nostiprināšanā PHP tīmekļa serveriem mēs rūpējamies arī par konteineriem:

• Pārbaudīt attēlus: katra attēla bāzes attēls, PHP versija, paplašinājumi un konfigurācija.
• Nostiprināt konfigurāciju: produkcijas ini, viegls paplašinājumu saraksts, piemērotas darbprocesu un atmiņas robežas.
• Ieviest pārbūvi: norise, kas attēlus pārbūvē un izvieto pie jauniem PHP izlaidumiem.
• Kontrolēt izpildes vidi: mēs pierādām, ka katrā darbojošā konteinerā darbojas labotā versija.

Biežāk uzdotie jautājumi

Avoti

• Docker Official Image: PHP
• PHP rokasgrāmata: FPM konfigurācija
• php.net: drošības paziņojums no 21.10.2026