Docker для локальной веб-разработки - часть 6

Всем привет! Эта статья продолжает серию переводов замечательных статей об использовании Docker для локальной веб-разработки.

В этой серии⚓︎

• Введение: почему это должно вас волновать?
• Часть 1: базовый стек LEMP
• Часть 2: посадите свои образы на диету
• Часть 3: трёхуровневая архитектура с фреймворками
• Часть 4: сглаживание ситуации с помощью Bash
• Часть 5: HTTPS для всего
• Часть 6: открываем локальный контейнер для доступа в Интернет ⬅️ вы здесь
• Часть 7: использование многоэтапной сборки для внедрения воркера
• Часть 8: запланированные задачи
• Заключение: куда идти дальше

Введение⚓︎

Хотя использование Docker для локальной разработки позволяет нам максимально близко воспроизвести продакшен-среду в автономном режиме, в некоторых случаях воздействие внешнего мира неизбежно.

Типичные случаи использования включают тестирование веб-хука стороннего сервиса (например, подтверждение транзакции от платежного шлюза) или демонстрацию продвижения проекта клиенту. Конечно, для этого можно использовать среду постановки (staging environment), но вы можете быть не в состоянии предложить её, а в некоторых случаях это похоже на раздавливание мухи кувалдой.

Не будет ли более практичным, если вы сделаете свою локальную среду общедоступной?

К счастью, эта проблема не нова, и несколько сервисов предлагают её решение. Эта статья посвящена одному из них, который со временем стал эталонным: Ngrok.

Предполагаемой отправной точкой этого руководства является место, где мы остановились в конце предыдущей части, соответствующее ветке part-5 репозитория.

Если вы предпочитаете, вы также можете напрямую проверить ветку part-6, которая является конечным результатом сегодняшней статьи.

Ngrok⚓︎

Ngrok — это онлайн-сервис, который позволяет разработчикам создавать защищенные туннели для передачи трафика с публичного URL на локальный адрес. Он предлагает платные тарифные планы, но также имеет щедрую бесплатную версию, которая даже не требует учётной записи для HTTP-туннелей. Однако, поскольку наша установка работает на HTTPS, нам придется зарегистрироваться, чтобы получить маркер аутентификации. Не волнуйтесь, это займет всего несколько секунд и не потребует данных кредитной карты.

Если вы не хотите открывать учётную запись, в конце этого руководства можно найти примечание, объясняющее, как использовать бесплатный план без подписки.

Установка и настройка⚓︎

Официального образа Docker для Ngrok не существует, но сообщество активизировалось и сделало несколько таких образов доступными.

Сегодня мы будем использовать образ Вернера Беру, для которого необходимо создать сервис в файле docker-compose.yml:

# Ngrok Service
ngrok:
  image: wernight/ngrok:latest
  ports:
    - 4040:4040
  environment:
    NGROK_PROTOCOL: http
    NGROK_PORT: nginx:443
    NGROK_AUTH: ${NGROK_AUTH}
  depends_on:
    - nginx

Ngrok поставляется с интерфейсом, обслуживаемым на порту 4040 контейнера, который мы сопоставили с портом localhost, и поскольку Nginx снова будет нашей точкой входа для трафика, мы убедились, что его контейнер запущен раньше контейнера Ngrok с помощью depends_on.

Таким образом, у нас осталась куча переменных окружения:

• NGROK_PROTOCOL может быть либо http, либо tcp — в нашем случае нам нужен первый;
• NGROK_PORT немного вводит в заблуждение, поскольку на самом деле это не только порт, но и хост, которым в нашем случае является nginx:443 (если хост не указан, подразумевается localhost);
• NGROK_AUTH — это токен аутентификации, который я упоминал ранее, его значение является другой переменной окружения, которую мы установим через минуту.

Это всё, что нам нужно на сегодня, но вы, возможно, захотите взглянуть на другие переменные окружения, перечисленные в документации к образу.

Теперь нам нужно установить токен аутентификации, который вы найдете в своем дашборде. Если вы помните, в первой части этой серии мы создали файл .env в корне проекта, наряду с docker-compose.yml. До сих пор мы использовали его только для указания имени проекта (чтобы избежать столкновения имен контейнеров с другими проектами), но именно в нем мы будем задавать токен.

Откройте файл и измените его содержимое на следующее, заменив заглушку <YOUR TOKEN> своим токеном:

COMPOSE_PROJECT_NAME=demo
NGROK_AUTH=<YOUR TOKEN>

По правилам хорошего тона нам также следует обновить .env.example, чтобы будущим пользователям было понятно, что ожидается значение:

COMPOSE_PROJECT_NAME=demo
NGROK_AUTH=

Это дает вам возможность либо установить токен в .env.example для всеобщего использования, либо попросить каждого разработчика создать свою учётную запись Ngrok и заполнить локальный .env файл соответствующим образом.

Конечно, вы можете задать токен в docker-compose.yml напрямую, но я хотел показать вам другой способ использования .env файла проекта.

Последнее, что нам нужно сделать, это обновить конфигурацию сервера Nginx в .docker/nginx/conf.d/backend.conf:

server {
    listen      443 ssl http2;
    listen      [::]:443 ssl http2;
    server_name backend.demo.test *.ngrok.io;
    root        /var/www/backend/public;
    ...

Сохраните его и перезапустите проект, чтобы создать контейнер Ngrok и перезагрузить конфигурацию Nginx:

$ demo restart

Откройте localhost:4040 в своем браузере.

Доступны два URL-адреса — выберите HTTPS-адрес и откройте его в новой вкладке, добавив в конце /api/hello-there.

Наш API теперь доступен публично! Теперь вернитесь на другую вкладку — вы должны увидеть что-то вроде этого:

Теперь вы можете использовать этот URL в сторонних сервисах или распространять его сколько угодно, пока запущен контейнер Ngrok. Соответствующий трафик появится в интерфейсе, где вы сможете его просмотреть и воспроизвести запросы по своему усмотрению. Удобно!

Есть только один небольшой недостаток: срок действия URL истекает через 8 часов, и он будет меняться каждый раз при перезапуске контейнера Ngrok. Меня это всегда устраивало, поскольку туннели мне обычно нужны только для быстрых тестов, но вы всегда можете рассмотреть платные тарифные планы, если это для вас проблема — они включают в себя, помимо прочего, пользовательские и постоянные поддомены.

Заключение⚓︎

Вот и всё, что нужно, чтобы сделать локальный контейнер доступным для Интернета.

Эта статья ещё раз демонстрирует, как легко можно использовать технологию Docker за считанные минуты, не имея никаких предварительных знаний. Нет необходимости беспокоиться об ошибках при установке или загромождении локальной установки — пока есть образ Docker для этой технологии (а большинство популярных технологий имеют такие образы), не нужно многого, чтобы быстро и безопасно использовать её.

Это также хороший пример того, когда можно положиться на сообщество, если издатель программного обеспечения или основная команда ещё не предоставили образ (это не значит, что доверять сообществу — плохая идея, просто если есть официальный образ, то лучше использовать его).

В следующей статье мы поговорим о другой ключевой концепции Docker: многоэтапной сборке. Мы будем использовать её для создания воркера для нашего API, чтобы слушать и получать сообщения из очереди.

Оригинальная статья: Docker for local web development, part 6: expose a local container to the Internet (English)

Комментарии