CI/CD: PHP attēlu automātiska pārbūve

Īsi sakot: Docker attēls satur PHP tā būvēšanas brīža stāvoklī un noveco arī bez koda izmaiņām. Kas attēlus pārbūvē automātiski, pēc laika grafika un pie drošības paziņojumiem, konveijerā pārbauda PHP versiju un izvieto pēc digest, ielāpus, piemēram, pret PHP2Shell, nogādā produkcijā plānoti. Zaļš būvējums vien tomēr nav pierādījums; skaitās versija darbojošajā konteinerā.

Kāpēc attēli noveco bez koda izmaiņām

Daudzās komandās būvēšanas konveijers startē tikai tad, kad kāds maina kodu. Lietojumprogrammai tas ir loģiski. Drošībai tā ir problēma, jo PHP attēlā nāk no bāzes attēla pēdējā būvējuma dienā.

PHP2Shell to padarīja redzamu. Labotās versijas 8.5.12, 8.4.27, 8.3.36 un 8.2.35 parādījās 2026. gada 21. oktobrī. Projekts, pie kura šajās dienās neviens nestrādāja, nesaņēma jaunu būvējumu un turpināja darboties ar veco PHP, kaut gan bāzes attēls sen bija atjaunināts. Manuālo ceļu no šīs situācijas apraksta PHP ielāpošana Docker konteineros. Šis raksts rāda, kā to automatizēt.

Docker attēlu automātiska pārbūve: trīs aktivizētāji

Noturīgs process apvieno vairākus aktivizētājus, lai neviens nebūtu jānes vienam.

GitHub Actions laika grafiku nodrošina notikums schedule. Saskaņā ar GitHub dokumentāciju tas izmanto cron sintaksi ar pieciem laukiem, darbojas UTC un tikai noklusējuma atzarā. Ieplānotie palaišanas gadījumi augstas slodzes laikā var startēt ar kavēšanos, un publiskos repozitorijos GitHub tos izslēdz pēc 60 dienām bez aktivitātes. Tieši pēdējais skar mierīgus projektus, tātad tieši tos, kuriem automātiskā pārbūve vajadzīga visvairāk.

Otrajam aktivizētājam Dependabot saskaņā ar GitHub dokumentāciju atbalsta ekosistēmu docker un jaunus bāzes attēlu stāvokļus piedāvā kā pull request. Jāzina divi ierobežojumi. Pirmkārt, kādam pull request jāpārbauda un jāapvieno, citādi tas paliek nepaņemts. Otrkārt, atzara tagam, piemēram, php:8.3-fpm, Dockerfile nekas nemainās, kad bāzes attēls tiek pārbūvēts. Rīkam, kas piedāvā teksta izmaiņas, tad nav ko piedāvāt. Tieši tāpēc papildus vajadzīga pārbūve pēc laika grafika.

Trešais aktivizētājs izklausās banāli, taču praksē bieži sastop jautājumu, kas to aktivizē. Nosakiet, kas seko PHP drošības paziņojumiem un kam ir tiesības palaist konveijeru, arī nedēļas nogalē. PHP2Shell gadījumā starp priekšpaziņojumu un ielāpu bija tikai viena diena.

Konveijers, kas pārtver novecojušu PHP

Šis GitHub Actions piemērs būvē attēlu ik nedēļu un pēc pogas nospiešanas, pārbauda PHP versiju un pārtrauc darbu, ja tā ir zemāka par labotu stāvokli. Reģistru, nosaukumus un minimālo versiju pielāgojiet.

name: php-image-rebuild
on:
  schedule:
    - cron: "0 3 * * 1"      # pirmdienās 03:00 UTC
  workflow_dispatch: {}      # manuāla palaišana pie drošības paziņojumiem

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Image ohne Cache und mit frischem Basis-Image bauen
        run: docker build --pull --no-cache -t app:${{ github.run_id }} .
      - name: PHP-Version prüfen (Mindeststand des Zweigs 8.3)
        run: |
          docker run --rm app:${{ github.run_id }} php -v
          docker run --rm app:${{ github.run_id }} \
            php -r 'exit(version_compare(PHP_VERSION, "8.3.36", ">=") ? 0 : 1);'

Versijas pārbaude darbojas oficiālajiem PHP attēliem, kuru versijas numurs norāda faktisko stāvokli. Ja jūsu attēls izmanto distributīva PHP pakotnes, numurs pēc backport bieži paliek tāds pats. Tad numura vietā pārbaudiet pakotnes changelog uz CVE numuriem, kā aprakstīts rakstā CVE numuru apliecināšana pakotnes changelog.

Pēc pārbaudes praksē seko vēl trīs soļi: attēla skenēšana uz zināmām ievainojamībām, nosūtīšana uz reģistru ar datumu un digest un digest nodošana izvietošanai. Kuri tagi un varianti der par pamatu, izskaidro Oficiālie PHP Docker attēli.

No būvējuma līdz darbojošamies konteineram

Biežākā domāšanas kļūda: konveijers ir zaļš, tātad viss ir ielāpots. Faktiski jaunais attēls atrodas tikai reģistrā. Ielāps kļūst spēkā tikai tad, kad katrs konteiners ir izveidots no jaunā attēla.

1. Izvietot pēc digest: izvietojums atsaucas uz jaunā attēla digest, nevis uz pārvietojamu tagu.
2. Vispirms staging, tad produkcija: automātiski testi kopijā pārtver pārrāvumus, ko izraisa jauni bāzes attēli.
3. Pārbaudīt darbībā: pēc izvietošanas izpildīt php -v darbojošajā konteinerā un salīdzināt digest ar būvējumu.
4. Ierobežot atkāpšanās ceļu: vecais attēls īsai atkāpšanās iespējai paliek pieejams, bet satur ievainojamo PHP.

Kubernetes ir savi noteikumi, piemēram, par pull politiku; tie ir aprakstīti sadaļā PHP ielāpošana Kubernetes.

Tipiski robi ķēdē

• Būvēšanas kešatmiņa uz runner: bez --pull un --no-cache tiek atkārtoti izmantots vecais bāzes attēls.
• Reģistra spogulis: iekšēja starpatmiņa joprojām piegādā bāzes attēla veco stāvokli.
• Daudzpakāpju būvējumi: skaitās pēdējās pakāpes PHP versija, bet pārbauda bieži tikai pirmo.
• Blakus attēli: queue worker, cron konteineriem un iekšējiem rīkiem ir savi konveijeri vai nav neviena.
• Fiksēti digest: reiz ierakstīts bāzes attēla digest netiek atjaunināts nekad, ja to neuzrauga neviens rīks.

Kas reaģē, ja pārbūve neizdodas?

Automātiska pārbūve ir tik laba, cik laba ir reakcija uz tās neveiksmi. Ja versijas pārbaude iedarbojas vai būvējums tiek pārtraukts mainīta bāzes attēla dēļ, kādam tas jāpamana. Daudzās komandās šādi paziņojumi nonāk pastkastē, ko neviens nelasa, vai kanālā, kurā sarkani būvējumi jau sen ir ikdiena.

Labi darbojas skaidrs noteikums: neizdevusies drošības pārbūve ir biļete ar atbildīgo un termiņu, nevis viena piezīme starp daudzām. Turklāt katram izvietotajam attēlam fiksējiet datumu, digest un pārbaudīto PHP versiju. Šis saraksts nākamā paziņojuma brīdī minūtēs atbild, kuras lietojumprogrammas ir skartas, un pārbaudītājiem vai apdrošinātājiem kalpo kā pierādījums. Kā no tā rodas pastāvīgs process, apraksta Ielāpu pārvaldība kā process, nevis ugunsdzēsēju darbs.

Kā PHP SOS palīdz konkrēti?

• Pārbaudīt konveijerus: Mēs apskatām jūsu būvēšanas un izvietošanas ķēdes un parādām, kur ielāps var iestrēgt.
• Automatizēt pārbūvi: Mēs iestatām laika grafika būvējumus, versijas pārbaudi un izvietošanu pēc digest.
• Apzināt visus attēlus: Mēs katram darbojošamies konteineram piesaistām tā konveijeru, arī blakus un vecos attēlus.
• Uzturēt ilgstoši: Drošības uzturēšanas līguma ietvaros mēs sekojam drošības paziņojumiem un uzsākam pārbūves.

Biežāk uzdotie jautājumi

Avoti

• GitHub Docs: notikumi, kas aktivizē darbplūsmas (schedule)
• GitHub Docs: Dependabot atbalstītās ekosistēmas
• Docker Hub: oficiālais PHP attēls
• PHP: atbalstītās versijas