Dockerfile е корисно ветување: со истите влезни податоци, изградете ја истата слика на апликацијата. Но сликата на апликацијата не е систем што работи. Таа не опишува кои услуги мора да се стартуваат заедно, каде се чува состојбата, како конфигурацијата влегува во процесот или што треба да се случи кога една зависност не е достапна.

Токму во таа празнина многу тимови за бекенд собираат кревки скрипти за поставување, недокументирани команди и околини што работат само затоа што некој ја памети точната низа. Декларативната инфраструктура е практичната алтернатива: опишете го посакуваниот систем во конфигурација со верзии, а потоа дозволете алатките да се усогласат со тој опис.

Размислувајте во системи, а не во контејнери

За PHP услуга, Dockerfile обично треба да се фокусира на една грижа: создавање извршлива слика на PHP апликација. Може да инсталира екстензии, да копира код на апликацијата и да дефинира процес. Слојот за композиција треба да ги опише односите околу тој процес: база на податоци, редица или кеш, обратен прокси, трајни волумени, мрежи и поставки специфични за околината.

Оваа разлика е важна затоа што ги одржува одговорностите разбирливи. Кога поврзувањето со база на податоци не успее, прашањето станува „што вели декларираниот систем?“ наместо „која команда за поставување заборавивме да ја извршиме?“

Мала Compose конфигурација може експлицитно да ги прикаже тие односи:

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:

Важната вредност не е во тоа што оваа датотека е кратка. Таа е во тоа што нов развивач може да ја прегледа и да одговори на конкретни прашања: кое име на домаќин треба да го користи PHP, која порта е изложена кон домаќинот и кои податоци преживуваат замена на контејнер?

Декларирајте го договорот, потоа дизајнирајте за реалноста

Декларативната конфигурација често погрешно се разбира како гаранција дека зависностите секогаш се подготвени. Не е така. Проверката на здравјето може да помогне во координирањето на стартувањето, но мрежите откажуваат, базите на податоци се рестартираат, акредитивите се ротираат и услугата може да стане недостапна откако апликацијата ќе стартува.

Вашата апликација сè уште има потреба од оперативно однесување. PHP кодот што отвора поврзување со база на податоци треба да користи ограничени временски ограничувања. Потрошувачите на редици треба намерно да донесуваат одлуки за повторни обиди. HTTP клиентите треба повторно да се обидуваат само со операции што безбедно може да се повторат и треба да избегнуваат бавната надолна услуга да ја претворат во засилен наплив на сообраќај.

Тука инфраструктурните декларации и дизајнот на апликацијата меѓусебно се засилуваат. Конфигурацијата наведува дека апликацијата зависи од PostgreSQL. Кодот прифаќа дека PostgreSQL е далечинска зависност со начини на откажување. Ниту еден слој не го заменува другиот.

Направете ја состојбата видлива

Состојбата е првото место каде што контејнеризираните системи стануваат погрешно претставени. Датотечниот систем на контејнерот е детал на имплементацијата, а не стратегија за база на податоци. Ако податоците на PostgreSQL, поставените датотеки, генерираните извештаи или трајните податоци од редицата се важни по замена, нивното складирање мора експлицитно да се дизајнира.

• Користете именувани волумени за податоци во локален развој што треба да останат по повторно создавање на контејнерот.
• Користете управувано или намерно управувано трајно складирање во продукција.
• Чувајте ги резервните копии, задржувањето, процедурите за обновување и контролите на пристап одделно од сликата на апликацијата.
• Не третирајте bind mount што се користи за практично локално уредување како образец за продукциско распоредување.

Истиот принцип важи и за промени во шемата. Миграцијата е премин на состојба, а не само несакан ефект при стартување. Автоматското извршување миграции може да биде соодветно во строго контролирана околина со една инстанца, но истовремените инстанци на апликацијата може да влезат во трка. Продукциското распоредување треба експлицитно да ги дефинира сопственоста и редоследот на миграциите.

Конфигурацијата е интерфејс

Променливите на околината се популарни затоа што ги одвојуваат вредностите при распоредување од содржината на сликата. Тие се корисни, но сепак се интерфејс и заслужуваат исто внимание како HTTP API. Дајте им на променливите стабилни имиња, документирајте го нивното значење, валидирајте ги задолжителните вредности при стартување и избегнувајте тивко враќање на небезбедни стандардни вредности.

PHP апликацијата може рано да откаже со јасна порака кога недостига задолжителна поставка, наместо да го открие проблемот дури кога ќе пристигне нејзиното прво барање. На пример, иницијализацијата на конфигурацијата може да бара URL на база на податоци и да одбие празна вредност пред да создаде поврзување.

$databaseUrl = getenv('DATABASE_URL');

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

Не ставајте долгорочни продукциски тајни директно во Compose датотека што е зачувана во репозиториумот. Декларацијата треба да ја открива формата на конфигурацијата без да ги изложува акредитивите. Акредитивите за локален развој може да бидат прифатливи кога се јасно ограничени и привремени; испораката на продукциски тајни има потреба од контроли соодветни за околината за распоредување.

Одржувајте го развојот практичен без да го направите фиктивен

Развојната околина треба да отстрани непотребно триење, но не треба да ги скрива важните граници на системот. Ако продукцијата користи посебна услуга за база на податоци, локалниот развој обично треба да го прави истото. Ако апликацијата зависи од Redis за кеш или редица, замена без дејство може да биде корисна за фокусиран unit тест, но не треба да биде единствениот начин на кој тимот ја користи апликацијата.

Compose профили или одделни датотеки за надминување може да помогнат да се разликуваат опционалните локални алатки од основните зависности. Целта не е на лаптоп да се репродуцира секој продукциски детал. Таа е суштинската топологија, конфигурацијата и претпоставките за откажување да се тестираат пред распоредувањето.

Compose е модел, не нужно и крајната цел

Docker Compose е особено ефикасен за локален развој, интеграциско тестирање и мали распоредувања. Поголемите околини може да користат друг распоредувач или управувана платформа. Тоа не го поништува моделот. Преносливата поука е како код да се опишат посакуваните услуги, поврзувањето, конфигурацијата, очекувањата за здравје и трајните ресурси.

Избегнувајте механички да копирате конфигурација меѓу околини. Локалната објавена порта постои за пристап на развивачот; внатрешната продукциска база на податоци често воопшто не треба да објавува порта. Локалниот волумен ги прави податоците лесни за преглед; продукциското складирање има потреба од својства за трајност и обновување. Заедничките концепти треба да останат доследни, додека имплементацијата специфична за околината останува експлицитна.

Трајниот резултат

Dockerfile-ите ги прават изградбите на апликации повторливи. Декларативната инфраструктура го прави околниот систем разбирлив. Заедно, тие ја намалуваат количината на оперативно знаење што живее само во пораки за разговор и индивидуална меморија.

Најдобриот тест е едноставен: може ли друг инженер да го клонира репозиториумот, да ја прочита конфигурацијата, да го стартува основниот систем и да ги разбере неговите граници без водена обиколка? Кога одговорот е да, сте направиле повеќе од контејнеризирање на апликација. Сте составиле систем што е полесен за менување, управување и доверба.