# PHP ielāpošana Docker konteineros

> PHP Docker attēla atjaunināšana pret PHP2Shell: pārbaudiet versiju konteinerā, pārbūvējiet attēlu, izveidojiet konteinerus no jauna un pareizi iestatiet pārejas vērtības.

Avots: https://phpsos.de/lv/php2shell/docker-container-patchen/  
Aktuāls uz: 25.10.2026  
Pakalpojuma sniedzējs: PHP SOS, PHP ārkārtas palīdzība un serveru drošība. Tūlītēja palīdzība pa WhatsApp: https://wa.me/491736494914?text=Sveiki%2C%20PHP%20SOS%2C%20mums%20nepiecie%C5%A1ama%20pal%C4%ABdz%C4%ABba%20ar%20m%C5%ABsu%20PHP%20serveri.%20Uz%C5%86%C4%93mums%3A%20%E2%80%A6%20Vietne%3A%20%E2%80%A6

**Ī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.

```bash
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:

```bash
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](https://phpsos.de/lv/php2shell/php-version-pruefen/).

## 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.

```bash
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.

```bash
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](https://phpsos.de/lv/server/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](https://phpsos.de/lv/server/frankenphp/).

> **Svarīgi:**
> 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`:

```ini
; 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
```

```bash
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](https://phpsos.de/lv/php2shell/php-fpm-neustart/).

## 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](https://phpsos.de/lv/leistungen/php-patch-service/) 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](https://phpsos.de/lv/leistungen/security-monitoring/) 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.

## Avoti

- [php.net: drošības paziņojumi](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)