Проблемите со перформансите на базата на податоци често на почетокот изгледаат како проблеми во апликацијата. За бавна крајна точка се обвинуваат PHP, ORM или зафатена API интеграција. Но многу од најфрустрирачките проблеми започнуваат подлабоко: база на податоци конфигурирана различно на секоја машина, стартувана со нејасни стандардни поставки или со состојба што никој не може сигурно да ја репродуцира.

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

Предвидливоста е функционалност за перформанси

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

Ова е особено важно за backend тимови што работат со PHP апликации. Програмер што истражува бавна Laravel, Symfony или приспособена PHP крајна точка не треба да се прашува дали неговата локална верзија на MySQL или PostgreSQL се разликува од онаа што се користи на друго место. Мали разлики во планирањето на прашања, колациите, екстензиите, поставките за меморија или стандардната автентикација може да го променат однесувањето на начини што трошат часови.

Корисната цел не е „ставете сè во контејнери“. Целта е важните оперативни претпоставки да станат видливи и повторливи.

Започнете со мала, експлицитна услуга за база на податоци

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

services:
  database:
    image: postgres:16
    environment:
      POSTGRES_DB: app
      POSTGRES_USER: app
      POSTGRES_PASSWORD: local-development-password
    ports:
      - "5432:5432"
    volumes:
      - postgres_data:/var/lib/postgresql/data
      - ./docker/postgres/init:/docker-entrypoint-initdb.d:ro
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app -d app"]
      interval: 5s
      timeout: 3s
      retries: 10

volumes:
  postgres_data:

Сликата на контејнерот ја фиксира главната верзија на базата на податоци. Волуменот ја прави трајноста намерен избор. Директориумот за иницијализација обезбедува јасно место за почетен SQL или скрипти за поставување. Проверката на здравјето прави разлика меѓу „процесот е стартуван“ и „базата на податоци е подготвена да прифати конекции“.

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

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

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

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

Одделете ги трајните податоци од привремената состојба

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

• Користете трајни волумени за вообичаени локални развојни податоци.
• Користете посебна база на податоци или привремен волумен за интеграциски тестови.
• Чувајте ги миграциите како канонска дефиниција на шемата.
• Користете почетни податоци што е безбедно да се извршуваат повеќепати или јасно документирајте кога тоа не е случај.

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

Одржувајте ја конекцијата на апликацијата исправна

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

PHP апликација што работи во контејнер може да користи конфигурација во ваква форма:

DB_CONNECTION=pgsql
DB_HOST=database
DB_PORT=5432
DB_DATABASE=app
DB_USERNAME=app
DB_PASSWORD=local-development-password

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

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

Користете контејнери за вежбање на патеките на неуспех

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

Тука backend отпорноста станува конкретна. Дали API враќа контролирана грешка кога конекцијата со базата на податоци е недостапна? Дали worker безбедно прави повторен обид или ја дуплира работата? Дали границите на трансакциите се точни кога барањето се повторува? Docker не може да одговори на овие прашања, но им дава на инженерите практична околина во која можат доследно да ги поставуваат.

Бидете внимателни со деструктивни команди. Отстранувањето контејнер не е нужно исто како отстранување на неговиот волумен. Пред да ресетирате локална околина, потврдете дали командата ќе отстрани трајни податоци и дали тие податоци се потребни. Скриптите за погодност треба јасно да го наведат ова, наместо да кријат неповратно однесување зад пријателско име.

Продукцијата бара иста дисциплина, не и иста форма

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

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

Изградете околина за база на податоци на која можете да ѝ верувате

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

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