Dockerfile je korisno obećanje: uz iste ulazne podatke, izgradit će istu sliku aplikacije. No slika aplikacije nije sustav koji se izvršava. Ne opisuje koje se usluge moraju pokrenuti zajedno, gdje se nalazi stanje, kako konfiguracija ulazi u proces ni što bi se trebalo dogoditi kada jedna ovisnost nije dostupna.

U tom prostoru mnogi backend timovi nakupljaju krhke skripte za postavljanje, nedokumentirane naredbe i okruženja koja rade samo zato što se netko sjeća ispravnog slijeda. Deklarativna infrastruktura praktična je alternativa: opišite željeni sustav u verzioniranoj konfiguraciji, a zatim prepustite alatima da se usklade s tim opisom.

Razmišljajte o sustavima, a ne o spremnicima

Za PHP uslugu Dockerfile bi se obično trebao usredotočiti na jednu brigu: izradu pokretljive slike PHP aplikacije. Može instalirati proširenja, kopirati kôd aplikacije i definirati proces. Sloj kompozicije trebao bi opisati odnose oko tog procesa: bazu podataka, red čekanja ili predmemoriju, obrnuti proxy, trajne volumene, mreže i postavke specifične za okruženje.

Ta je razlika važna jer odgovornosti ostaju razumljive. Kada povezivanje s bazom podataka ne uspije, pitanje postaje „što kaže deklarirani sustav?” umjesto „koju smo naredbu za postavljanje zaboravili pokrenuti?”

Mala Compose konfiguracija može učiniti te odnose eksplicitnima:

services:
  app:
    build: .
    environment:
      APP_ENV: development
      DATABASE_URL: postgresql://app:secret@db:5432/app
    depends_on:
      db:
        condition: service_healthy
    ports:
      - "8080:8080"

  db:
    image: postgres:16
    environment:
      POSTGRES_DB: app
      POSTGRES_USER: app
      POSTGRES_PASSWORD: secret
    volumes:
      - postgres-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app -d app"]
      interval: 5s
      timeout: 3s
      retries: 10

volumes:
  postgres-data:

Važna vrijednost nije u tome što je ova datoteka kratka. Važno je to što novi programer može pregledati datoteku i odgovoriti na konkretna pitanja: koji naziv hosta PHP treba koristiti, koji je port izložen hostu i koji podaci preživljavaju zamjenu spremnika?

Deklarirajte ugovor, a zatim dizajnirajte za stvarnost

Deklarativna konfiguracija često se pogrešno shvaća kao jamstvo da su ovisnosti uvijek spremne. Nije. Provjera zdravlja može pomoći u koordinaciji pokretanja, ali mreže otkazuju, baze podataka se ponovno pokreću, vjerodajnice se rotiraju, a usluga može postati nedostupna nakon što je aplikacija već pokrenuta.

Vaša aplikacija i dalje treba operativno ponašanje. PHP kôd koji otvara vezu s bazom podataka trebao bi koristiti ograničena vremenska ograničenja. Potrošači reda čekanja trebali bi promišljeno donositi odluke o ponovnim pokušajima. HTTP klijenti trebali bi ponovno pokušavati samo operacije koje je sigurno ponoviti te izbjegavati pretvaranje spore nizvodne usluge u pojačani nalet prometa.

Tu se infrastrukturne deklaracije i dizajn aplikacije međusobno nadopunjuju. Konfiguracija navodi da aplikacija ovisi o PostgreSQL-u. Kôd prihvaća da je PostgreSQL udaljena ovisnost s mogućim načinima otkaza. Nijedan sloj ne zamjenjuje drugi.

Učinite stanje vidljivim

Stanje je prvo mjesto na kojem kontejnerizirani sustavi postaju obmanjujući. Datotečni sustav spremnika detalj je implementacije, a ne strategija za bazu podataka. Ako su podaci PostgreSQL-a, prenesene datoteke, generirana izvješća ili trajni podaci reda čekanja važni nakon zamjene, njihova pohrana mora biti izričito dizajnirana.

• Koristite imenovane volumene za podatke lokalnog razvojnog okruženja koji bi trebali ostati nakon ponovnog stvaranja spremnika.
• U produkciji koristite upravljanu ili namjerno operativno održavanu trajnu pohranu.
• Čuvajte sigurnosne kopije, zadržavanje, postupke obnove i kontrole pristupa odvojeno od slike aplikacije.
• Nemojte bind mount korišten za praktično lokalno uređivanje smatrati obrascem produkcijske implementacije.

Isto načelo vrijedi za promjene sheme. Migracija je prijelaz stanja, a ne samo nuspojava pokretanja. Automatsko pokretanje migracija može biti primjereno u strogo kontroliranom okruženju s jednom instancom, ali istodobne instance aplikacije mogu se natjecati. Produkcijska implementacija trebala bi jasno odrediti vlasništvo i redoslijed migracija.

Konfiguracija je sučelje

Varijable okruženja popularne su zato što odvajaju vrijednosti u vrijeme implementacije od sadržaja slike. Korisne su, ali i dalje su sučelje te zaslužuju jednaku pažnju kao HTTP API. Dajte varijablama stabilna imena, dokumentirajte njihovo značenje, provjerite obavezne vrijednosti pri pokretanju i izbjegavajte tihi povratak na nesigurne zadane vrijednosti.

PHP aplikacija može rano otkazati s jasnom porukom kada nedostaje obavezna postavka, umjesto da problem otkrije tek kada stigne prvi zahtjev. Na primjer, pokretanje konfiguracije može zahtijevati URL baze podataka i odbiti praznu vrijednost prije stvaranja veze.

$databaseUrl = getenv('DATABASE_URL');

if ($databaseUrl === false || $databaseUrl === '') {
    throw new RuntimeException('DATABASE_URL must be configured.');
}

Nemojte dugotrajne produkcijske tajne stavljati izravno u predanu Compose datoteku. Deklaracija bi trebala otkriti oblik konfiguracije bez izlaganja vjerodajnica. Vjerodajnice za lokalni razvoj mogu biti prihvatljive kada su jasno ograničene i jednokratne; isporuka produkcijskih tajni zahtijeva kontrole primjerene okruženju implementacije.

Neka razvoj bude praktičan, a ne fiktivan

Razvojno okruženje trebalo bi ukloniti nepotrebno trenje, ali ne bi trebalo skrivati važne granice sustava. Ako produkcija koristi zasebnu uslugu baze podataka, lokalni razvoj obično bi trebao činiti isto. Ako aplikacija ovisi o Redisu za predmemoriju ili red čekanja, zamjena bez učinka može biti korisna za fokusirani jedinični test, ali ne bi trebala biti jedini način na koji tim testira aplikaciju.

Compose profili ili zasebne datoteke za nadjačavanje mogu pomoći razlikovati neobavezne lokalne alate od ključnih ovisnosti. Cilj nije reproducirati svaki produkcijski detalj na prijenosnom računalu. Cilj je učiniti ključnu topologiju, konfiguraciju i pretpostavke o otkazima provjerljivima prije implementacije.

Compose je model, a ne nužno odredište

Docker Compose posebno je učinkovit za lokalni razvoj, integracijsko testiranje i male implementacije. Veća okruženja mogu koristiti drugi raspoređivač ili upravljanu platformu. To ne poništava model. Prenosiva lekcija jest opisati željene usluge, povezivost, konfiguraciju, očekivanja zdravlja i trajne resurse kao kôd.

Izbjegavajte mehaničko kopiranje konfiguracije između okruženja. Lokalni objavljeni port postoji radi pristupa programera; interna produkcijska baza podataka često uopće ne bi trebala objaviti port. Lokalni volumen olakšava pregled podataka; produkcijska pohrana treba svojstva trajnosti i oporavka. Zajednički koncepti trebali bi ostati dosljedni, dok implementacija specifična za okruženje ostaje eksplicitna.

Trajni ishod

Dockerfileovi čine izgradnju aplikacija ponovljivom. Deklarativna infrastruktura čini okolni sustav razumljivim. Zajedno smanjuju količinu operativnog znanja koje postoji samo u porukama razgovora i individualnom pamćenju.

Najbolji test je jednostavan: može li drugi inženjer klonirati repozitorij, pročitati konfiguraciju, pokrenuti osnovni sustav i razumjeti njegove granice bez vođenog obilaska? Kada je odgovor potvrdan, učinili ste više od kontejneriziranja aplikacije. Sastavili ste sustav koji je lakše mijenjati, upravljati njime i kojem je lakše vjerovati.