Īsi: PHP Docker attēla atjaunināšana pret PHP2Shell ir obligāta, un tā nenotiek pati no sevis. Jāpārbūvē vai jāievelk attēls ar labotu PHP versiju, jāizveido no tā katrs konteiners no jauna un jāpārbauda, ka darbojošajā konteinerā darbojas 8.5.12, 8.4.27, 8.3.36 vai 8.2.35. Ar vienkāršu konteinera pārstartēšanu nepietiek.
Kāpēc konteineri nav automātiski droši
Docker attēls ir iesaldēts mirkļa attēls. PHP tajā paliek tādā stāvoklī, kāds tas bija būvēšanas brīdī, pat ja resursdatorā sen ir instalēti atjauninājumi. Pakotņu atjauninājums resursdatora sistēmā PHP konteinerā nemaina.
Klāt nāk tipiskas lamatas: attēli, kas uzbūvēti pirms mēnešiem un kopš tā laika nav aiztikti, bāzes attēli ar fiksētu tagu, piemēram, php:8.3.35-fpm, lokālas kešatmiņas, kas būvēšanas laikā atkārtoti izmanto veco bāzes attēlu, un konteineri, kas gan pārstartēti, bet nekad nav izveidoti no jauna. Skarti ir visi konteineros ierastie darbības režīmi: PHP-FPM, Apache ar mod_php un FrankenPHP.
Klāt nāk arī atbildības jautājums. Daudzos uzņēmumos aģentūra vai izstrādātājs attēlu ir uzbūvējis vienu reizi, bet to darbina iekšējā IT nodaļa vai hostinga sniedzējs. Tad neviens nejūtas atbildīgs par PHP stāvokli attēlā. Tāpēc vispirms noskaidrojiet, kas attēlu būvē, kur atrodas Dockerfile un kam ir tiesības izvietot jaunus attēlus.
PHP versijas pārbaude konteinerā
Pārbaudiet darbojošos konteineru, ne tikai Dockerfile. Komandas ir tikai lasošas.
docker ps --format "table {{.Names}}\t{{.Image}}\t{{.CreatedAt}}"
docker exec <container> php -v
docker exec <container> php -i | grep -E "^PHP Version|Server API"
docker image inspect <image> --format "{{.Created}}"
Ja attēls izmanto distributīva pakotnes, nevis oficiālos PHP būvējumus, pārbaudiet pakotnes stāvokli konteinerā. Pakotņu nosaukumi atšķiras pa bāzes distributīviem:
docker exec <container> sh -c "apt policy php8.3-fpm 2>/dev/null || apk info -v 2>/dev/null | grep php"
Distributīvu pakotņu gadījumā var būt ieviests backport, kaut gan versijas numurs paliek vecs. Tad noteicošs ir pakotnes changelog. Oficiālie PHP attēli turpretī PHP parasti satur pašu kompilētu; tur noteicošā vērtība ir versijas numurs no php -v. Kā atpazīt backport labojumus, apraksta PHP versijas un ielāpa stāvokļa pareiza pārbaude.
PHP Docker attēla atjaunināšana: pārbūvēt un izvietot
Savs attēls uz PHP attēla bāzes: bāzes attēlu ievelkt no jauna un būvēt bez kešatmiņas.
docker build --pull --no-cache -t meine-app:2026-10-25 .
docker run --rm meine-app:2026-10-25 php -v # pārbaudīt versiju pirms izvietošanas
Ar Docker Compose: attēlus ievilkt vai būvēt un konteinerus izveidot no jauna.
docker compose pull
docker compose build --pull --no-cache
docker compose up -d --force-recreate
Pēc tam vēlreiz pārbaudiet ar docker exec <container> php -v, vai darbojas jaunā versija. Ja konteinerā Dockerfile ir fiksēts versijas tags, piemēram, FROM php:8.3.35-fpm, tags jāpaaugstina. Tags uz atzaru, piemēram, php:8.3-fpm, saņem jaunus ielāpu stāvokļus, bet tikai tad, ja velkat no jauna.
Turiet gatavībā iepriekšējo attēlu, līdz jaunā versija ir pārbaudīta. Kļūdas gadījumā tā varat pārslēgties atpakaļ, ilgi neatstājot lietojumprogrammu bezsaistē. Vecais attēls gan atkal satur ievainojamo PHP; atgriešanās ceļš tāpēc ir attaisnojams tikai īslaicīgi un ar pagaidu pasākumiem.
Kas izmanto Kubernetes, jauno attēlu izvieto ar Deployment. Detaļas ir lapā PHP ielāpošana Kubernetes. FrankenPHP attēliem spēkā ir tā pati kārtība; norādes par darbības režīmu atradīsiet sadaļā FrankenPHP nodrošināšana.
Neaizmirstiet blakus konteinerus: cron un rindu darbprocesi, administratora rīki vai staging vides bieži izmanto to pašu PHP attēlu, bet darbojas savos konteineros. Katrs no tiem jāizveido no jauna.
Pagaidu pasākumi konteinerā
Ja atjauninājums vēl nav iespējams, php.net pagaidu pasākumi attiecas arī uz konteineru. Tie nav pilnīga aizsardzība. Atmiņas ierobežojums šeit jāliek pie konteinera, jo php.net to iesaka ar konteineru vai cgroup, nevis ar RLIMIT_AS vai RLIMIT_DATA:
; piem., kā fails attēlā: /usr/local/etc/php/conf.d/zz-uebergang.ini
memory_limit = -1
post_max_size = 8M
upload_max_filesize = 6M
session.upload_progress.enabled = 0
docker run --memory=1g ... # vai Compose: deploy.resources.limits.memory
Vērtību pielāgojiet savai lietojumprogrammai. Raugieties, lai lietojumprogramma memory_limit nevarētu pārrakstīt pati; PHP-FPM gadījumā šim nolūkam vērtības iestata pūlā ar php_admin_value. Jaunā konfigurācija stājas spēkā tikai tad, kad konteiners ir izveidots no jauna vai pārstartēts; fonu par pārstartēšanu skatiet lapā PHP-FPM un visu darbprocesu pārstartēšana.
Lai nākamreiz būtu ātrāk
- Attēlus būvēt regulāri un automātiski, ne tikai pie koda izmaiņām.
- Izmantot bāzes attēlus ar atzara tagu un uzbūvēto stāvokli versionēt ar datumu vai digest.
- Pirms izvietošanas attēlus ļaut pārbaudīt uz zināmām ievainojamībām un konteinerus darbināt bez root tiesībām.
- Uzturēt inventāru, kuri konteineri izmanto kuru attēlu.
Kā PHP SOS palīdz konkrēti?
- Apkopot esošo stāvokli: Mēs pārbaudām visus darbojošos konteinerus, to attēlus un PHP versijas, arī blakus konteinerus un staging.
- Pārbūvēt un izvietot: Ar PHP ielāpu pakalpojumu mēs attēlus būvējam ar labotu versiju un konteinerus kontrolēti izveidojam no jauna.
- Nodrošināt pāreju, kur atjauninājums ir atkarīgs no lietojumprogrammas: php.net vērtības, atmiņas ierobežojums pie konteinera.
- Uzraudzīt pastāvīgi: Ar drošības monitoringu mēs paturam redzeslokā attēlu stāvokli un konteineru neparasto uzvedību.
Biežāk uzdotie jautājumi
Vai pēc atjauninājuma pietiek ar docker restart?
Nē. docker restart konteineru pārstartē ar to pašu, veco attēlu. Jaunais attēls jāuzbūvē vai jāievelk un konteiners no tā jāizveido no jauna, piemēram, ar docker compose up -d --force-recreate.
Vai oficiālais PHP attēls jau satur labotu versiju?
To vislabāk pārbaudīt tieši: ievelciet attēlu no jauna un tajā palaidiet php -v. Jāgaida 8.5.12, 8.4.27, 8.3.36 vai 8.2.35. Ja attēls rāda vecāku numuru, tas vēl nav atjaunināts vai nāk no kešatmiņas.
Vai PHP konteinerā ir mazāk apdraudēts nekā resursdatorā?
Pati ievainojamība konteinerā darbojas tāpat. Labi uzbūvēts konteiners var ierobežot ielaušanās sekas, piemēram, ar lietotāju bez root tiesībām un tikai lasāmu failu sistēmu. Ielāpu tas neaizstāj.