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

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

Сметајте го контејнерот за договор за распоредување

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

Таа јасност е особено корисна за PHP апликации, каде разликите во екстензии како pdo_mysql, intl, zip или opcache можат да претворат успешна изградба во инцидент во продукција. Ако е потребна екстензија, дефинирајте ја во сликата наместо да претпоставувате дека случајно е инсталирана на сервер.

Компактен почетен пример за PHP-FPM апликација може да изгледа вака:

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"]

Ова намерно е нецелосно како целосен продукциски стек. PHP-FPM обично се наоѓа зад веб-сервер или обратен прокси, а правилната поставеност зависи од апликацијата и платформата. Важниот образец е дека зависностите се инсталираат пред да се копира изворниот код на апликацијата. Docker тогаш може повторно да го искористи слојот со зависности кога се менува само кодот на апликацијата, што ги забрзува итеративните изградби.

Изградете еднаш, конфигурирајте при извршување

Една честа грешка е вградувањето поставки специфични за околината во сликата. Продукциските акредитиви за базата на податоци, API клучевите, имињата на домаќини и знаменцата за дебагирање не припаѓаат во Dockerfile или во зачуван слој на сликата. Изградете пренослива слика, а потоа обезбедете конфигурација специфична за околината кога контејнерот се извршува.

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

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

Ова раздвојување има корисна оперативна последица: потполно истата слика на апликацијата може да се тестира во staging и да се распореди во продукција. Се менува само нејзината одобрена конфигурација при извршување. Исто така, се намалува ризикот регистарот на слики да се третира како складиште за тајни.

Користете Compose за моделирање на локалните зависности

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

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:

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

Не мешајте го depends_on со подготвеноста на апликацијата. Тој го контролира редоследот на стартување на услугите, но базата на податоци сè уште може да се иницијализира кога апликацијата ќе стартува. Апликациите за продукциска употреба треба да се справуваат со привремени неуспеси на поврзувањето преку разумни повторни обиди, временски ограничувања и јасно известување за грешки. Миграциите на базата на податоци исто така треба да бидат експлицитен чекор при распоредување, а не случаен несакан ефект од стартувањето на секој веб-процес.

Направете ги продукциските слики помали и понамерни

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

Повеќестепените изградби се особено ефикасни кога се вклучени фронтенд средства или компајлирани зависности. Изградете ги средствата во една фаза, а потоа копирајте го само генерираниот излез во сликата за извршување. Слично, инсталирајте PHP зависности со --no-dev кога развојните пакети не се потребни во продукција.

Постои и придобивка во одржувањето: помалите слики се преземаат побрзо и содржат помалку подвижни делови. Целта не е минимализам сам по себе. Таа е да се вклучи сè што ѝ е потребно на апликацијата и ништо што создава непотребна продукциска одговорност.

Дајте им на контејнерите една јасна одговорност

Корисна почетна поставеност е една главна намена по контејнер: веб-апликација, процес за работник, распоредувач, база на податоци или кеш. Ова не значи дека секој систем мора да биде поделен на десетици услуги. Значи дека сопственоста на процесите треба да биде очигледна. Работник за редица може да се скалира независно од HTTP сообраќајот, а работник што откажува може да се рестартира без да влијае на веб-процесот.

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

Скалирањето започнува со дисциплина за состојбата

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

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

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

Оперативните детали сè уште се важни

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

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

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