Hopp til innhold

Docker — Публікація додатку

Relevante sider
Andre relevante sider
Skip to content

Це машинний переклад тексту, який може містити помилки!

Публікація Docker-застосунку

У вправі з Dockerfile ви створили образ і запустили застосунок за допомогою docker run. Якщо ви виконали необов’язкову вправу Compose, ви можете використовувати Compose натомість. Тут вам потрібно налаштувати той самий застосунок так, щоб він відповідав через ім’я домену (DNS-name) та доступний проксі-сервер. Ви можете скористатися власним застосунком або тестовим застосунком із вправи з Dockerfile.

Спочатку виконайте прямий тест, а потім — HTTP через проксі-сервер. Базовий шлях вважається завершеним, коли ім’я домену повертає очікуючу відповідь від застосунку, а ви можете пояснити кожну ланцюжок цього процесу. HTTPS та встановлення окремого проксі-сервера є додатковими опціями зі своїми передумовами.

Коли Flask-застосунок працює на сервері з певним портом, reverse proxy може приймати запити від імені застосунку та пересилати їх у правильний контейнер. Тоді користувач може використовувати доменне ім’я замість IP-адреси та номера порту. Вам потрібне DNS-ім’я та проксі-сервер, який ви маєте можливість налаштувати, а також сертифікат, якщо служба повинна використовувати HTTPS.

Браузер спочатку використовує DNS для пошуку IP-адреси. Потім вебтрафік надходить на reverse proxy, а далі — у контейнер Flask.

DNS відповідає адресою, але не передає саму вебсторінку. На діаграмі проксі-сервер завершує HTTPS-з’єднання та використовує HTTP далі в окремій внутрішній мережі. Браузер отримує відповідь через проксі-сервер.

Перед початком

Вам потрібен робочий контейнер із вправи з Dockerfile (або вправи з Compose), а також такі дані від тестового середовища:

  • APP-VM-IP: адреса віртуальної машини, на якій запущено додаток; тут використовується порт 5000.
  • PROXY-IP: адреса, за якою клієнт має отримати доступ до проксі, через HTTP на порту 80.
  • APP-НАЗВА: ім’я у системі DNS, яке вказує на проксі. Додаток і проксі можуть розташовуватися на різних віртуальних машинах.

У вас повинен бути доступ для створення Proxy Host у Nginx Proxy Manager та дозволи на зв’язок між проксі та додатком. Заплатівки вище необхідно замінити вашими значеннями. Якщо немає доступного DNS або доступу до проксі, виконайте локальне тестування та поясніть схему. Це не є завершеною перевіркою публікації.

1. Перевірте застосунок локально

Працюйте в каталозі проєкту на VM із застосунком. Наведені нижче команди використовують ім’я контейнера min-app з вправи для Dockerfile. З прив’язкою порту з неї цей тест має відобразити головну сторінку:

docker ps
curl --fail --show-error http://127.0.0.1:5000/

Ви можете використовувати /status як стабільну точку контролю. Якщо цього маршруту ще немає, додайте його після інших повних функцій обробки маршрутів і перед if __name__ == "__main__": у файлі app.py:

@app.route("/status")
def status():
    return {"status": "ok"}

Збудуйте, запустіть і протестуйте знову:

docker build -t min-app .
docker rm -f min-app
docker run -d --name min-app -p 127.0.0.1:5000:5000 min-app
curl --fail --show-error http://127.0.0.1:5000/status

Якщо ви використовуєте Compose, замініть три перші команди на docker compose up -d --build.

Очікуйте відповідь HTTP 200 та JSON з "status": "ok". Якщо у додатку вже є маршрут /status, використовуйте його задокументовану відповідь замість створення нового маршруту з тією самою назвою. Це перевіряє саме цей маршрут, а не всі функції додатка.

2. Зробіть додаток доступним для проксі-сервера

Далі в інструкції використовується мережева адреса ВМ додатка. Якщо порт прив’язаний лише до 127.0.0.1, перезапустіть контейнер, вказавши фактичну адресу ВМ у зв’язці порту. Обмежте мережевий доступ необхідними джерелами; сама по собі прив’язка адреси не обмежує клієнтів, які можуть підключатися.

docker rm -f min-app
docker run -d --name min-app -p APP-VM-IP:5000:5000 min-app
curl --fail --show-error http://APP-VM-IP:5000/status

Якщо ви використовуєте Compose, замість рядка порту під app у файлі compose.yaml вставте "APP-VM-IP:5000:5000" та запустіть команду docker compose up -d.

Проведіть тестування на віртуальній машині додатку (app-VM) та з середовища мережі проксі або з тестового клієнта зі схожими дозволеними правами доступу. Фактивне з’єднання проксі також контролюється назвою в наступному розділі. Після зміни прив’язки перевіряйте адресу VM, а не 127.0.0.1. Не відкривайте порт для всього інтернету. [Сегментація рівня 1 — VLAN і сегментація мереж | Сегментація] забезпечує підтримку правила доступу.

Від домену до контейнера

Коли користувач відкриває назву на кшталт https://app.example.test, відбувається кілька дій. Це приклад-назва; замініть її на фактичну назву, налаштувану у вашому тестовому середовищі:

sequenceDiagram
    participant B as Браузер
    participant D as DNS
    participant P as Menedжер проксі Nginx
    participant F as Контейнер Flask

    B->>D: Знайти IP-адрес домену
    D-->>B: IP-адрес проксі
    B->>P: Запит до домену
    P->>P: Знайти правильний хост проксі
    P->>F: Переказати на внутрішній порт 5000
    F-->>P: Повернути HTML-сторінку
    P-->>B: Повернути відповідь

Тому розумно тестувати по одному шару за раз, а не діагностувати проблеми з DNS, проксі та Flask одночасно.

Новачок у концепціях DNS і зворотного проксі-сервера?

[[Протоколи рівня 2 — Служби мережі та ролі серверів|🌐 Служби мережі та ролі серверів]] пояснює сервери DNS і зворотний проксі загалом, із тими самими шаблонами, що й тут, перш ніж ви налаштуєте це конкретно через Nginx Proxy Manager.

Nginx Proxy Manager

Nginx Proxy Manager є вебінтерфейсом для Nginx. Тут ви використовуєте наявну встановлену систему та створюєте один Proxy Host. Вам не потрібно встановлювати новий проксі для кожного застосунку.

Створіть Proxy Host:

  1. Введіть APP-NAVN, ім’я, яке фактично налаштовано для служби.
  2. Оберіть http як схему з’єднання від Nginx Proxy Manager до контейнера.
  3. Введіть APP-VM-IP як хостний іменник пересилання (forward hostname). 127.0.0.1 всередині проксіконтейнера означає сам проксіконтейнер.
  4. Введіть опублікований порт контейнера, наприклад 5000.
  5. Збережіть зміни та відкрийте http://APP-NAVN/status із клієнта.

Ім’я має визначатися до PROXY-IP. Ви можете перевірити визначення за допомогою nslookup APP-NAVN на клієнті. HTTP-тест повинен давати той samий відповідь стану, що й прямий тест. Відображення стандартної сторінки проксі не свідчить про те, що запитування досягло застосунку.

Повторний вибір: HTTPS

Коли HTTP працює і у вас є дійсний сертифікат для доменного імені, відкрийте вкладку SSL, оберіть сертифікат і протестуйте https://APP-NAME/status. Внутрішнє тестове ім’я, наприклад app.example.test, не може отримати публічний сертифікат від Let’s Encrypt; тоді вам потрібен сертифікат від внутрішнього органу видачі, якому клієнт довіряє. Тільки запити DNS не налаштовують HTTPS. Базовий маршрут HTTP — це локальне вправлення; при обробці даних входу або інших захищених даних необхідний HTTPS.

Проксі має мати доступ до порту сервера. Якщо контейнер запущений на іншому віртуальному машинному середовищі (VM), мережа та брандмаур повинні дозволяти трафік між VM. Вам не потрібно безпосередньо відкривати порт Flask для всього інтернету, якщо Nginx Proxy Manager є точкою входу; обмежте доступ за допомогою брандмаура відповідно до конфігурації навчального закладу.

Не впевнені в правилах брандволів між віртуальними машинами?

У розділі [[Сегментація рівня 1 — VLAN та сегментація мережі|🧱 Сегментація]] є окремий розділ про правила брандволів між мережами.

Повторний вибір: Власна проксі-сервер

Встановлюйте власну проксі лише тоді, коли вам це дійсно потрібно і у вас є окреме тестовий середовище. Використовуйте посібник з встановлення Nginx Proxy Manager. Після цього поверніться до створення хоста проксі вище. Це окремий налаштування, а не обов’язкова умова для використання наявного проксі.

Відладка

Новачок у систематичному усуненні несправностей?

🔍 Метод усунення несправностей надає вам повний метод (сім кроків, метод поділу навпіл, очікувані та фактичні значення), що лежить в основі пошарового тестування нижче.

docker ps
docker logs -f min-app
ss -tulpn

Якщо ви використовуєте Compose, перші дві команди називаються docker compose ps та docker compose logs -f. Виконуйте ці команди по одній за раз на віртуальній машині додатка (app-VM). Завершіть роботу logs -f натисканням Ctrl+C. Команда ps показує стан контейнерів, журнал виводить повідомлення додатка, а ss може допомогти з перевіркою портів прослуховування. Використовуйте результат конкретної HTTP-перевірки для контролю доступу.

Виконуйте перевірки у такому порядку:

  1. На віртуальній машині додатка після зміни прив’язки: curl --fail --show-error http://APP-VM-IP:5000/status.
  2. З мережевого середовища проксі: той самий адресний простір, порт і маршрут. Довільний клієнт може мати інші правила доступу.
  3. З клієнта через ім’я хоста: nslookup APP-НАВН, потім http://APP-НАВН/status. Якщо HTTPS налаштовано, виконайте його перевірку окремо.

Якщо пункт 1 не вдається, досліджуйте додаток, стан контейнера, адресу та прив’язку порту. Якщо пункт 1 працює, а пункт 2 не вдається, перевіряйте з’єднання та правила доступу від проксі. Якщо пункт 2 працює, а пункт 3 не вдається, досліджуйте DNS, параметр Proxy Host та вибрану протокол. Код помилки HTTP 404 означає, що HTTP-сервер відповів, але маршрут може бути неправильним; код 502 від проксі вказує на проблему зі з’єднанням або відповіддю додатка. Зробіть записи щодо того, що саме обмежує діагностику перед внесенням будь-яких змін.

Наступний крок

Покажіть статусну відповідь за назвою та поясніть різницю між пошуком у DNS і пересиланням на проксі-сервері. Також вкажіть клієнт, проксі та додаток на діаграмі або власному ескізі. Ви можете пояснити усно або письмово. Вкажіть тестову адресу, очікувану/фактичну відповідь та те, чи ви використовували HTTP чи HTTPS. У разі відхилень скористайтеся порядком тестів зверху, перш ніж продовжувати.

Коли базова маршрутизація працюватиме, ви зможете далі використовувати цю конфігацію у проекті. Docker — Публікація контейнера за допомогою workflow є подальшим навчанням щодо автоматизації побудови та публікації образу.

Джерела: Docker: прив’язка портів, Nginx Proxy Manager та Flask: маршрути та відповіді.