Англійська для Docker Compose

Docker Compose часто є першим інструментом для багатоконтейнерних розробників, і його словник — «сервіс» проти «контейнер», «том» проти «зв’язати монтування» — збиває людей з пантелику, тому що терміни звучать взаємозамінними, але не є. Правильне їх використання важливе під час зневадження, коли ви не знаєте, чому контейнер не може дістатися до іншого, або чому дані зникли після перезапуску. Цей підручник містить основні терміни.

Ключовий словник

** Служба ** — визначення у docker-compose.yml, яке описує, як запустити контейнер (штамп, порти, середовище, томи), відмінне від самого запущеного контейнера.

• “Служба db визначає штамп Postgres і його змінні середовища, але справжній запущений контейнер створюється, коли ми запускаємо docker compose up.” *

** Volume ** — постійний механізм зберігання, яким керує Docker, використовується для збереження даних (наприклад, файлів бази даних) під час перезапусків і перебудов контейнера. “Ми втратили всі локальні дані, тому що ми забули змонтувати том — файлова система контейнера скидається кожного разу, коли її створюють знову.”

** В’ язання монтування ** — спосіб відображення певного каталогу вузла у контейнері, зазвичай використовується у розробці для синхронізації змін у початковому коді без перебудови штампу. “Монтування приєднання на ./src означає, що зміни, які ми робимо локально, будуть відображені всередині контейнера негайно, без перебудови.”

** Мережа ** — внутрішня мережа, якою керує Compose, що надає змогу службам зв’ язуватися одна з одною за допомогою назви служби, не знаючи адрес IP контейнерів. “Служба API може дістатися бази даних лише за допомогою db як назви вузла, оскільки Compose автоматично встановлює їх у тій же мережі.”

** depends_on ** — директива, яка керує порядком запуску служб, хоча типово вона очікує лише на запуск контейнера, а не на готовність програми, що знаходиться всередині нього. ” depends_on спочатку запустив контейнер бази даних, але API все одно зазнав аварії, оскільки Postgres ще не приймав з’ єднання — нам також потрібна була перевірка стану.”

Healthcheck — команда Docker запускає періодично всередині контейнера, щоб визначити, чи він дійсно готовий, який depends_on може чекати, коли поєднується з condition: service_healthy.

• “Якщо ми додали перевірку стану до служби бази даних, служба API правильно чекала, поки Postgres не буде готовим приймати з’ єднання.” *

Звичайні фрази

• «Чи є ці дані в іменованому томі, або вони зникнуть наступного разу, коли ми перебудуємо?»
• “Ці дві служби в одній мережі? Це пояснило б, чому назва вузла не розв’язується»
• «depends_on сам по собі не гарантує, що база даних дійсно готова — чи нам потрібен контроль стану?»
• Чи це bind mount для місцевого розвитку, чи це має бути обсяг у виробництві?»
• «Яка служба насправді не працює — сам контейнер, або щось всередині нього?»

Приклади висловлювань

Зневадження помилки запуску: “Контейнер програми запускається нормально, але він аварійно завершує роботу при першому запиту на базу даних — depends_on чекав лише запуску контейнера Postgres, а не завершення ініціалізації самого Postgres, тому нам потрібна залежність, заснована на healthcheck.”

Пояснюючи інцидент втрати даних в пост-мортному: “Ми використовували монтування з прив’ язкою, яке вказувало на тимчасовий каталог замість тома з назвою, тому, коли контейнер було відтворено під час розгортання, всі вивантажені файли було вилучено.”

Введення нового розробника: “Кожна служба у файлі compose відображається в одному контейнері, вони всі з’ єднані в одній внутрішній мережі, і ви можете дістатися до будь- якої з них за назвою служби — тому інтерфейс просто викликає http://api:3000, а не твердо закодований IP.”

Професійні поради

• Використовуйте « служба », якщо мова йде про налаштування Compose, і « контейнер », якщо мова йде про поточний запущений процес — ця відмінність має значення під час зневадження порядку запуску або масштабування.
• Розрізняти названий том від зв’ язку монтування явно в документації — зв’ язок монтування прив’ язує дані до певного шляху вузла, тоді як том керується Docker і безпечніший для виробничих даних.
• Проясніть, що ** depends_on ** без перевірки стану гарантує лише порядок запуску, а не готовність — це одна з найпоширеніших причин періодичних невдач запуску.
• Використовуйте « мережа », коли пояснюєте проблеми з’ єднання — служба, яка не може зв’ язатися з іншою, майже завжди слідує за тим, що вона знаходиться в іншій мережі або використовує неправильну назву вузла.

Практичні вправи

1. Поясніть у двох реченнях різницю між томом з назвою і томом з прив’ язкою.
2. Написати звіт про помилку у одному реченні, у якому буде описано службу, яку було запущено до того, як її залежність була готова.
3. Опишемо вашими словами, як дві служби у одному і тому ж файлі Compose можуть зв’ язатися між собою за допомогою назви.

Розширення вашого розуміння: нюанси в технічній комунікації

Будьмо чесними - вивчення технічного словника - це тільки половина битви. Справжнє оволодіння ним включає розуміння як цей словник використовується в реальному світі спілкування. Як не рідною англійською мовою, ви, ймовірно, зіткнетеся з ситуаціями, де просто знати визначення недостатньо. Незначні нюанси фрази, тону і контексту можуть внести величезну різницю у те, як ваші ідеї приймаються і розуміються колегами. Розгляньте наступне: досконало точний технічний опис, який надається неясною або надто формальною мовою, може бути таким же заплутаним, як і неточність.

Однією з ключових областей є зворотній зв’язок - особливо в рамках перегляду коду. Отримати коментар на кшталт «Це потребує більшої ясності» не є за своєю суттю негативним; це часто запит на спеціальні поліпшення. Людина, для якої англійська мова є рідною, може одразу ж припустити, що рецензент хоче, щоб ви переформулювали весь розділ. Однак, кращий підхід передбачає розуміння основної проблеми. Можливо, рецензент вказав на те, що зв’ язок між вашою службою web і службою database не відразу з’ являється у файлі Compose. Ви можете відповісти на це повідомлення, наприклад, так: « Дякую за позначення цього повідомлення! Я додав коментар до файлу docker-compose.yml, в якому чітко зазначено, що служба web залежить від служби db, забезпечуючи її початок раніше і використовуючи дані з’єднання з базою даних. “Це показує, що ви зрозуміли зворотній зв’язок і вчинили відповідно - демонстрація активного спілкування є ключем. Аналогічно, у розмовах Slack, де обговорюються PR, уникнення надмірно технічного жаргону при поясненні ваших змін комусь, хто не знайомий з проектом, може запобігти непорозумінням. Замість того, щоб сказати «Я налаштував мережевий місток для міжконтейнерного спілкування», спробуйте «Я налаштував спосіб для того, щоб контейнери спілкувалися один з одним в мережі Docker»

Інший поширений сценарій включає в себе пріоритетування послуг у вашому docker-compose.yml. Просто сказати, що ви впорядкували їх за алфавітом, недостатньо — це не передає * чому * ви зробили цей вибір. Ефективнішим поясненням буде: « Я замовив служби, щоб забезпечити запуск бази даних перед веб- програмою, оскільки веб- програма потребує запущеного екземпляра бази даних для початкового налаштування і отримання даних ». Це показує розуміння залежностей і потенційних проблем.

version: '3.9'
services:
  db:
    image: postgres:15-alpine
    environment:
      POSTGRES_USER: myuser
      POSTGRES_PASSWORD: mypassword
    ports:
      - "5432:5432"
    volumes:
      - db_data:/var/lib/postgresql/data
  web:
    image: myapp/webapp
    depends_on:
      - db
    ports:
      - "8080:8080"
    environment:
      DATABASE_URL: postgresql://myuser:mypassword@db:5432/mydb

volumes:
  db_data:

Нарешті, пам’ятайте, що активне слухання є найважливішим. Не зосереджуйтеся лише на формулюванні своєї відповіді; справді слухайте те, що говорять інші, і задайте прояснюючі питання, якщо щось не ясно. Питання « Чи можете ви розглянути конкретні наслідки для продуктивності цієї конфігурації мережі? » показує справжній інтерес до розуміння більш широкого контексту і демонструє повагу до досвіду ваших колег.