Pozadinski sustav koji savršeno radi na prijenosnom računalu developera i dalje može zakazati u produkciji iz uobičajenih razloga: nedostaje mu PHP ekstenzija, konfiguracijska vrijednost je drugačija, sistemska biblioteka nije kompatibilna ili je redoslijed pokretanja nejasan. Docker ne uklanja operativne probleme, ali čini okruženje aplikacije eksplicitnim, ponovljivim i lakšim za razumijevanje.

Za backend timove ta je predvidljivost prava vrijednost. Slika kontejnera može definirati PHP runtime, potrebne ekstenzije, kod aplikacije, konfiguraciju procesa i pretpostavke za izvođenje u jednom verzioniranom artefaktu. Kada se isti artefakt premješta iz lokalnog razvoja u testiranje i produkciju, implementacija se manje svodi na ponovno sastavljanje okruženja, a više na promoviranje poznate verzije.

Promatrajte kontejner kao ugovor o implementaciji

Dockerfile nije samo skripta za pakiranje. On je ugovor između aplikacije i platforme na kojoj se izvodi. Trebao bi jasno odgovoriti na praktična pitanja: Koja je verzija PHP-a potrebna? Koje ekstenzije moraju postojati? Gdje se aplikacija izvodi? Koji proces prihvaća promet? Koje datoteke trebaju pristup za pisanje?

Ta je jasnoća osobito korisna za PHP aplikacije, gdje razlike u ekstenzijama kao što su pdo_mysql, intl, zip ili opcache mogu uspješnu izgradnju pretvoriti u incident u produkciji. Ako je ekstenzija potrebna, definirajte je u slici umjesto da pretpostavite da je slučajno instalirana na poslužitelju.

Kompaktna početna točka za PHP-FPM aplikaciju mogla bi izgledati ovako:

FROM php:8.3-fpm-alpine

WORKDIR /var/www/app

RUN docker-php-ext-install pdo_mysql opcache

COPY --from=composer:2 /usr/bin/composer /usr/bin/composer

COPY composer.json composer.lock ./
RUN composer install --no-dev --prefer-dist --no-interaction --optimize-autoloader

COPY . .

RUN chown -R www-data:www-data /var/www/app

CMD ["php-fpm"]

Ovo je namjerno nepotpuno kao cjeloviti produkcijski skup. PHP-FPM obično se nalazi iza web poslužitelja ili obrnutog proxyja, a ispravna postavka ovisi o aplikaciji i platformi. Važan obrazac jest da se ovisnosti instaliraju prije kopiranja izvornog koda aplikacije. Docker tada može ponovno upotrijebiti sloj s ovisnostima kada se promijeni samo kod aplikacije, što ubrzava iterativne izgradnje.

Izgradite jednom, konfigurirajte tijekom izvođenja

Jedna česta pogreška jest ugrađivanje postavki specifičnih za okruženje u sliku. Produkcijske vjerodajnice za bazu podataka, API ključevi, nazivi hostova i zastavice za otklanjanje pogrešaka ne pripadaju Dockerfileu ni sloju slike koji se predaje u repozitorij. Izgradite prenosivu sliku, a zatim pružite konfiguraciju specifičnu za okruženje kada se kontejner izvodi.

Za tipičan backend konfiguracija tijekom izvođenja uključuje:

• Pojedinosti povezivanja s bazom podataka i vjerodajnice
• Okruženje aplikacije i postavke za otklanjanje pogrešaka
• Krajnje točke za predmemoriju, red, poštu i pohranu objekata
• Tajne koje pruža platforma za implementaciju ili namjenski sustav za upravljanje tajnama
• Ograničenja resursa, odredišta zapisnika i postavke procesa

Ovo razdvajanje ima korisnu operativnu posljedicu: potpuno ista slika aplikacije može se testirati u stagingu i implementirati u produkciju. Mijenja se samo njezina odobrena konfiguracija tijekom izvođenja. Također smanjuje rizik od tretiranja registra slika kao spremišta tajni.

Koristite Compose za modeliranje lokalnih ovisnosti

Većina backenda nije samo jedan proces. Ovise o bazi podataka, predmemoriji, redu, usluzi pretraživanja ili lokalnom hvataču pošte. Docker Compose vrijedan je u razvoju jer opisuje te odnose u obliku koji svaki suradnik može pokrenuti.

services:
  app:
    build: .
    volumes:
      - .:/var/www/app
    environment:
      APP_ENV: development
      DB_HOST: db
    depends_on:
      - db

  db:
    image: mysql:8
    environment:
      MYSQL_DATABASE: app
      MYSQL_USER: app
      MYSQL_PASSWORD: change-me
      MYSQL_ROOT_PASSWORD: change-root-password
    volumes:
      - mysql-data:/var/lib/mysql

volumes:
  mysql-data:

Naziv usluge db postaje naziv hosta baze podataka unutar Compose mreže. Time se uklanja krhka navika tvrdo kodiranih lokalnih IP adresa. Imenovani volumen čuva podatke baze podataka pri ponovnom stvaranju kontejnera, dok montiranje izvornog koda aplikacije podržava učinkovit razvojni ciklus.

Nemojte brkati depends_on sa spremnošću aplikacije. On upravlja redoslijedom pokretanja usluga, ali baza podataka možda se još inicijalizira kada se aplikacija pokrene. Aplikacije spremne za produkciju trebale bi rješavati prolazne neuspjehe povezivanja razumnim ponovnim pokušajima, vremenskim ograničenjima i jasnim izvještavanjem o pogreškama. Migracije baze podataka također bi trebale biti izričit korak implementacije, a ne slučajna nuspojava pokretanja svakog web procesa.

Učinite produkcijske slike manjima i promišljenijima

Praktičnost razvoja i pouzdanost produkcije različiti su ciljevi. Montiranja izvornog koda, razvojne ovisnosti, uslužni programi ljuske i detaljni alati za otklanjanje pogrešaka mogu biti korisni lokalno, ali su rijetko poželjni u produkcijskoj slici. Promišljena produkcijska izgradnja ograničava ono što se isporučuje, smanjuje površinu napada i olakšava provjeru ponašanja.

Višefazne izgradnje osobito su učinkovite kada su uključena frontend sredstva ili kompilirane ovisnosti. Izgradite sredstva u jednoj fazi, a zatim u runtime sliku kopirajte samo generirani izlaz. Slično tome, instalirajte PHP ovisnosti s --no-dev kada razvojni paketi nisu potrebni u produkciji.

Postoji i prednost u održavanju: manje slike brže se preuzimaju i sadrže manje pokretnih dijelova. Cilj nije minimalizam sam po sebi. Cilj je uključiti sve što aplikacija treba i ništa što stvara nepotrebnu odgovornost u produkciji.

Dajte kontejnerima jednu jasnu odgovornost

Korisna je zadana postavka jedna primarna briga po kontejneru: web aplikacija, radni proces, raspoređivač, baza podataka ili predmemorija. To ne znači da svaki sustav mora biti podijeljen na desetke usluga. Znači da vlasništvo nad procesima treba biti očito. Radnik reda može se skalirati neovisno o HTTP prometu, a neuspjeli radnik može se ponovno pokrenuti bez utjecaja na web proces.

Za PHP aplikacije to često vodi do zasebnih implementacija koje koriste istu sliku, ali različite naredbe. Jedna pokreće PHP-FPM za web zahtjeve; druga pokreće radnika reda; zakazani zadatak pokreće se putem raspoređivača platforme. Slika ostaje dosljedna, dok uloge procesa ostaju eksplicitne.

Skaliranje počinje disciplinom stanja

Docker olakšava pokretanje više kopija backenda, ali replikacija radi uredno samo kada se stanjem aplikacije upravlja promišljeno. Nemojte se oslanjati na datoteke zapisane unutar kontejnera za prijenose korisnika, trajne sesije ili poslovne podatke. Kontejneri se mogu zamijeniti u bilo kojem trenutku.

Trajne podatke pohranjujte u sustave namijenjene tome: bazu podataka za zapise, pohranu objekata za prijenose i zajedničku predmemoriju ili mehanizam temeljen na bazi podataka za sesije kada je potrebno horizontalno skaliranje. Zapisnike držite na standardnom izlazu ili standardnom izlazu za pogreške kako bi ih hosting okruženje moglo dosljedno prikupljati.

Kada je aplikacija bez stanja na razini kontejnera, skaliranje postaje odluka o kapacitetu, a ne redizajn. Dodajte web replike za volumen zahtjeva, dodajte radnike za dubinu reda i zasebno prilagodite kapacitet baze podataka. To je razdvajanje jedan od najsnažnijih arhitektonskih argumenata za kontejnerizaciju.

Operativni detalji i dalje su važni

Docker nije zamjena za provjere zdravlja, vidljivost sustava, sigurnosne kopije, disciplinu migracija ni sigurnosna ažuriranja. Tretirajte sliku kao jedan dio sustava isporuke. Označite izdanja nepromjenjivim identifikatorom, zabilježite koja je slika implementirana i izbjegavajte implementirati promjenjivu oznaku poput latest kao jedinu referencu na izdanje.

Testirajte izgrađenu sliku, a ne samo stablo izvornog koda. Pokrenite automatizirane testove aplikacije gdje je prikladno, provjerite pokreće li se s konfiguracijom nalik produkcijskoj i osigurajte da kontejner može primiti signal za postupno zaustavljanje. Te provjere otkrivaju razliku između “kod je ispravan” i “artefakt spreman za implementaciju je ispravan”.

Trajna korist Dockera jest pouzdanje kroz eksplicitnost. Pretvara skrivene pretpostavke poslužitelja u verzioniranu konfiguraciju, potiče čiste granice između procesa i čini skaliranje kontroliranijim postupkom. Dobro kontejneriziran backend nije samo lakše implementirati. Lakše ga je razumjeti, poboljšati i imati povjerenja u njega kada je sljedeće izdanje najvažnije.