Вот и вы - вы проводили дни и ночи, пытаясь создать свой потрясающий веб-сайт, который решит проблемы будущего. Но теперь вам нужно выяснить, как его развернуть. Хотя вы можете использовать такие сервисы, как Heroku, для развертывания приложений, в этом примере мы увидим базовый способ докеризации вашего приложения и использования nginx.

Упаковка приложения

При локальной работе на наших машинах нам всегда нужен сервер разработки, который может выполнять горячую перезагрузку и обслуживать перенесенный код. Это верно независимо от того, переносятся ли файлы React JSX в JS или файлы Angular TypeScript, которые компилируются в JS.

Но при развертывании на сервере нам не нужна транспиляция, поскольку она больше не требует никаких изменений, и весь окончательный код готов к отправке. В этом случае нам просто нужно сгенерировать наши готовые к распространению статические файлы и что-то, которое может обслуживать эти статические файлы. В нашем случае something - это nginx. Вы можете узнать больше о nginx здесь.

Тогда можно задаться вопросом, а где же здесь Docker? Что мы подразумеваем под докеризацией нашего приложения? Короче говоря, мы используем Docker, чтобы избежать установки и переустановки nginx (или любых других зависимостей системного уровня) на каждом сервере, на котором мы развертываем наше приложение. Узнайте больше о Docker здесь.

В этой статье мы будем использовать это демонстрационное приложение, которое выполняет простой HTTP-запрос и записывает ответ в консоль. Сначала давайте продолжим и создадим файлы распространения для проекта. Поскольку это проект Angular, мы будем использовать команды CLI для сборки проекта.

npm run build

В зависимости от типа проекта вы увидите папку _1 _ / _ 2_, которая в нашем случае будет иметь следующую структуру:

Создание Dockerfile

Теперь, когда приложение упаковано, мы создадим простой Dockerfile, который скопирует содержимое папки dist в папку html nginx, который был загружен как часть нашего образа.

В приведенном выше файле Dockerfile мы просто указываем, что наш базовый образ - это nginx, который доступен здесь, а затем мы заменяем html-страницу nginx по умолчанию нашим контентом. Есть и другие вещи, которые мы можем добавить сюда, чтобы nginx мог передавать наши запросы нашему пользовательскому бэкэнду, который мы обсудим в последнем разделе.

Построить изображение

Чтобы создать образ, то есть упакованный код поверх nginx, мы можем сделать это с помощью следующей команды:

docker build --rm -f Dockerfile -t httpclient:latest .

Мы явно указываем Dockerfile, который мы хотим, чтобы он использовал (он все равно выберет файл с этим именем по умолчанию, вы можете переименовать его, если хотите), а затем мы указываем имя изображения httpclient:latest, а последний . указывает, что мы хочу построить все в этом проекте.

Как только мы запустим команду, мы увидим ответ, как показано ниже:

Чтобы убедиться, что изображение создано, мы можем проверить, запустив команду docker images, и увидим результат, как показано ниже:

Запустить изображение

Теперь, когда у нас есть готовое изображение, мы собираемся запустить его с помощью простой команды

docker run --rm -d -p 9999:80 httpclient:latest

Мы запускаем только что созданный образ докера и указываем сопоставление портов с помощью параметра -p. Мы знаем, что nginx предоставляет порт номер 80, мы хотим сопоставить его с портом 9999 на нашей машине. Поэтому, когда наш браузер пытается получить доступ к порту 9999, запрос будет перенаправлен на порт 80, который работает в нашем изображении.

Чтобы протестировать приложение, откройте http://localhost:9999 в своем браузере, и вы увидите, что приложение работает должным образом.

API серверной части прокси

В примере приложения мы указываем на сторонний сервер для получения данных, которые разрешают запросы с перекрестным происхождением. Но это не рекомендуется для производственных бэкэнд-приложений, и если вы используете свой пользовательский интерфейс и бэкэнд отдельно, вы также захотите проксировать запросы. Чтобы настроить прокси, nginx предоставляет файл конфигурации, который может содержать необходимую нам конфигурацию и пересылать запросы, как определено. Простой пример этого файла будет выглядеть следующим образом:

Мы просто перенаправляем запросы, начинающиеся с /api/, на внутренний сервер, а все остальное, например запросы страницы пользовательского интерфейса, обратно на страницу индекса, поскольку маршрутизация обрабатывается самими SPA.

Чтобы указать nginx выбрать нашу конфигурацию nginx вместо конфигурации по умолчанию, мы просто изменяем наш Dockerfile, чтобы вместо этого выбрать наш файл конфигурации.

В следующий раз, когда мы создадим образ, конфигурация nginx будет скопирована в образ. Все остальное, например способ создания и запуска образов, остается таким же, как описано выше.

Заключение

Теперь, когда приложение работает должным образом, следующим шагом будет использование некоторой облачной службы, такой как AWS, Azure или Google Cloud, для сохранения вашего изображения в репозитории изображений, запуска сервера и запуска вашего изображения на нем.

Полный пример кода доступен здесь.

Если вам понравился этот блог, не забудьте дать ему несколько хлопков или подписаться на меня в LinkedIn