Публикация Docker-приложения

В упражнении по созданию Dockerfile вы создали образ и запустили приложение с помощью docker run. Если вы выполнили необязательное упражнение с Compose, можно использовать Compose вместо этого. Здесь нужно настроить так же работающее приложение для отклика через имя домена (DNS) и доступный прокси. Вы можете использовать собственное приложение или тестовое из упражнения по Dockerfile.

Сначала проведите прямой тест, затем проверьте работу по HTTP через прокси. Базовый путь считается завершенным, когда запрос к имени возвращает ожидаемый ответ приложения и вы можете объяснить каждый этап процесса. Использование HTTPS и установка собственного прокси являются дополнительными опциями со своими требованиями.

Когда приложение Flask работает на сервере в определенном порту, reverse-proxy может принимать запросы от имени приложения и перенаправлять их в правильный контейнер. Тогда пользователь сможет использовать доменное имя вместо IP-адреса и номера порта. Вам потребуется DNS-имя, прокси, который у вас есть возможность конфигурировать, а также сертификат, если сервис должен использовать HTTPS.

DNS отвечает адресом, но не передает сам контент сайта. На схеме показано, что прокси завершает соединение с использованием HTTPS и продолжает передачу данных по HTTP внутри ограниченной внутренней сети. Браузер получает ответ через прокси.

Перед началом работы

Вам потребуется рабочий контейнер из упражнения с Dockerfile (или из упражнения с Compose), а также следующие данные из тестовой среды:

• APP-VM-IP: адрес виртуальной машины, на которой запущено приложение; здесь используется порт 5000.
• PROXY-IP: адрес, по которому клиент должен обращаться к прокси, с использованием HTTP на порту 80.
• APP-НАЗВАНИЕ: имя в системе доменных имен (DNS), указывающее на прокси. Приложение и прокси могут находиться на разных виртуальных машинах.

У вас должны быть права для создания объекта Proxy Host в Nginx Proxy Manager, а также разрешение на соединение от прокси к приложению. Плейсхолдеры выше необходимо заменить вашими значениями. Если доступ к DNS или прокси отсутствует, выполните локальное тестирование и объясните диаграмму. Это не будет считаться завершенным тестом публикации.

1. Проверьте приложение локально

Работайте в каталоге проекта на ВМ приложения. Команды ниже используют имя контейнера 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.

Запустите тесты на ВМ приложения из сетевой среды прокси или с тестового клиента, имеющего аналогичные разрешенные права доступа. Фактическое соединение прокси также контролируется именем, указанным в следующем разделе. После изменения привязки тестируйте адрес ВМ, а не 127.0.0.1. Не открывайте порт для всего интернета. [Сегментация уровня 1 — VLAN и сегментация сети | Сегментация] обеспечивает поддержку правила доступа.

От домена к контейнеру

При открытии пользователем имени вида https://app.example.test происходит несколько вещей. Это примерное имя; замените его на фактическое имя, настроенное в вашей тестовой среде:

sequenceDiagram
    participant B as Браузер
    participant D as DNS
    participant P as Nginx Proxy Manager
    participant F as Flask-контейнер

    B->>D: Найти IP-адрес домена
    D-->>B: IP-адрес прокси
    B->>P: Запрос к домену
    P->>P: Найти правильный Proxy Host
    P->>F: Перенаправить на внутренний порт 5000
    F-->>P: Вернуть HTML-страницу
    P-->>B: Вернуть ответ

Поэтому разумно тестировать по одному слою за раз, а не отлаживать одновременно DNS, прокси и Flask.

Nginx Proxy Manager

Nginx Proxy Manager — это веб-интерфейс для Nginx. Здесь вы используете доступную установку и создаёте один хост прокси (Proxy Host). Вам не нужно устанавливать новый прокси для каждого приложения.

Создайте Proxy Host:

1. Введите APP-NAME, имя, которое фактически настроено для службы.
2. Выберите http как схему подключения от Nginx Proxy Manager до контейнера.
3. Введите APP-VM-IP в качестве имени перенаправляемого узла (forward hostname). 127.0.0.1 внутри прокси-контейнера означает сам прокси-контейнер.
4. Введите опубликованный порт контейнера, например, 5000.
5. Сохраните настройки и откройте http://APP-NAME/status с клиента.

Имя должно резолвиться на PROXY-IP. Вы можете проверить разрешение имени командой nslookup APP-NAME на клиенте. HTTP-тест должен дать тот же статусный ответ, что и прямой тест. Отображение стандартной страницы прокси не подтверждает, что запрос достиг приложения.

Повторное голосование: HTTPS

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

Прокси должен иметь возможность доступа к порту сервера. Если контейнер запускается на другой виртуальной машине, сеть и брандмауэр должны разрешать трафик между виртуальными машинами. Вам не нужно напрямую открывать порт Flask для всего интернета, если Nginx Proxy Manager является точкой входа; ограничьте доступ с помощью брандмауэра согласно настройкам школы.

Повторное голосование: Собственный прокси

Устанавливайте отдельный прокси только в том случае, если он вам действительно необходим и у вас есть собственная тестовая среда. Используйте руководство по установке 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-NAVN, затем перейдите по адресу http://APP-NAVN/status. Если HTTPS настроен, протестируйте его отдельно.

Если шаг 1 завершается ошибкой, проверьте приложение, статус контейнера, адрес и привязку порта. Если шаг 1 работает, но шаг 2 завершается ошибкой, проверьте соединение и правила доступа со стороны прокси-сервера. Если шаг 2 работает, но шаг 3 завершается ошибкой, проверьте DNS, параметр Proxy Host и выбранный протокол. Ошибка HTTP 404 означает, что сервер HTTP ответил, но маршрут мог быть неверным; ошибка 502 от прокси-сервера указывает на проблему с соединением или ответом приложения. Запишите результаты теста для уточнения области проблемы перед внесением изменений.

Следующий шаг

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

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

Источники: Docker: привязка портов, Nginx Proxy Manager и Flask: маршруты и ответы.