Разработка и развертывание статических сайтов можно управлять с широким спектром методов. Если Docker Уже является частью вашего инструмента, вы можете отбросить свой контент в качестве контейнера на любую платформу в мире, будь то Kubernetes , OpenShift Или ноутбук вашего друга.
В этом уроке мы построим многоэтапную сборку Docker, используя популярный статический генератор сайтов, Гэтсби Анкет Методология, приведенная ниже, может использоваться практически для любого вида веб -сайта, который должен создавать свои активы и служить простыми файлами HTML, JS и CSS.
Мы будем использовать альпийские варианты наших унаследованных изображений Docker. Это снижает наш последний размер изображения менее чем на 50 МБ в зависимости от количества статического содержания. Поговорим об эффективности!
Прежде чем идти дальше, проверить и клонировать мой Репозиторий веб -сайта который я буду использовать в качестве примера для этого поста. Знание построения и управления изображениями Docker также необходимо следовать.
Этап 1: Построение сайта Gatsby с узлом
Создание сайта Gatsby относительно просто, устанавливая зависимости и выпустив Gatsby Build командование Я использую пряжу в качестве менеджера зависимостей по выбору, и я настроил вышеупомянутый сценарий сборки для запуска с Строительница пряжи Анкет
Используя многоэтапную сборку, нам не нужно беспокоиться о том, что осталось во время процесса сборки, поскольку будет сохранено только сгенерированный контент. Это делает наши изображения более стройными и безопасными. Ниже вы можете найти первый этап нашей сборки. Давайте пройдемся по линии по линии.
FROM node:11-alpine AS build RUN apk add --no-cache --virtual .gyp python make g++ WORKDIR /app ENV NODE_ENV=production COPY package.json yarn.lock ./ RUN yarn --frozen-lockfile --non-interactive COPY . . RUN yarn build
Мы начинаем, используя официальное изображение Alpine Linux для node.js версии 11 Tagged Узел: 11-Альпина Анкет Для справки, мы называем это сборка Анкет
Затем мы устанавливаем необходимые пакеты операционной системы с собственным диспетчера пакетов Alpine, apk Анкет Поскольку наш процесс сборки опирается на Узел-гип Во время компиляции нам нужно иметь их под рукой, если вы удивляетесь, почему мы устанавливаем Python в контейнер узла.
Затем мы установили текущий рабочий каталог в /приложение где наше приложение будет жить до конца этого этапа. Это может быть то, что мы хотим Но я сделал для себя соглашением, чтобы всегда использовать самую простую возможную структуру папок внутри контейнера. Вообще /приложение или /данные оба хорошие варианты.
Затем мы говорим Узел работать в специальном Производство Режим путем экспорта переменной среды Node_env = производство Анкет Мы хотим, чтобы Гэтсби как можно больше оптимизировал активы, чтобы обеспечить максимальную производительность площадки, и этого не произойдет в режиме разработки. Это также хорошая идея, чтобы использовать это всякий раз, когда вы создаете приложение узла для производства.
Затем мы копируем файлы зависимости package.json и пряжа в наш контейнер и установите то, что им требуется. Это использует преимущества кэширования слоя Docker, поэтому нам не нужно строить зависимости каждый раз, когда мы редактируем сообщение в блоге. Это отличная помощь, поскольку установка пакетов узлов может занять до 2 минут из -за количества плагинов Gatsby, используемых в нашей сборке.
Наконец, остальные файлы скопированы, и мы говорим Гэтсби построить сайт из этих ресурсов. По умолчанию Гэтсби выводит их в папку с именем public На корне проекта, который мы будем использовать на следующем этапе.
Если вы хотите, вы можете остановиться здесь и запустить контейнер. Должна быть папка, полная скомпилированного контента, готового.
Этап 2: обслуживание сайта
Ниже приведен второй этап нашей сборки. Опять же, давайте пройдем это сверху вниз.
FROM nginx:alpine COPY nginx /etc/nginx/ COPY --from=build --chown=nginx:nginx /app/public /usr/share/nginx/html RUN touch /var/run/nginx.pid && chown nginx:nginx /var/run/nginx.pid USER nginx EXPOSE 8080 HEALTHCHECK CMD ["wget", "-q", "localhost:8080"]
Мы хотим обслуживать встроенный сайт с nginx Веб -сервер, и, к счастью, мы также можем использовать его альпийский вариант. На этот раз нам не нужно назначать имя на этот этап, так как это будет последним.
Я изменил конфигурацию NGINX по умолчанию, удалив пользователь nginx; линия. Вы можете скопировать его из Здесь Анкет В отличие от того, кто может догадаться, эта линия не нужна, когда мы запускаем наш контейнер в качестве пользователя, не являющегося корнями для целей безопасности. В пределах Фактическая конфигурация сайта Я назначил TCP-порт 8080 для этого сайта, так как пользователи, не являющиеся корнями, не могут привязываться к портам до 1024. На вашем хост -машине вы можете привязать к любому открытому контейнерному порту, чтобы это не имело значения.
Далее мы будем свидетелями красоты многоступенчатых сборок. Здесь мы обучаем Docker’s Копия Команда для копирования файлов с предыдущего этапа и мгновенно изменить их право собственности на нашего пользовательского пользователя без каких -либо дополнительных сценариев. Разве это не круто? Обязательно установите достаточно новую версию Docker для работы.
Существует небольшая предостережение запуска контейнера в качестве пользователя без корня: нам нужно убедиться, что у этого пользователя есть разрешения на использование /var/run/nginx.pid который обрабатывает работающий процесс Nginx. В противном случае контейнер не сможет начать. К счастью, это всего лишь однострочный обходной путь и не введет слишком много накладных расходов в нашу сборку.
После этого мы говорим изображению Docker запустить все команды остальных как nginx Пользователь, который включен в официальное изображение. Вы можете, конечно, создать здесь другого пользователя и установить право собственности на файлы для него Но я выбрал более легкий путь. Папка /usr/share/nginx/html является стандартным каталогом для сайтов Nginx, определенного в нашей конфигурации и достаточно прост, чтобы запомнить.
Наконец, мы выставляем порт 8080 для хост -машин, чтобы привязать и определять пользовательскую команду проверки здоровья. Проверки на здоровье абсолютно необязательны для изображений Docker, но они становятся довольно удобными в среде, где у вас есть десятки контейнерных служб. Здесь мы сообщаем проверку здоровья, чтобы запустить команду Shell wget -q Localhost: 8080 периодически, чтобы получить нашу домашнюю страницу. Если эта команда не удастся, наш контейнер умирает или в зависимости от политик перезапуска, она будет перезапущена. Поскольку процесс сервера NGINX работает в качестве основного процесса (PID 1), любой сбой в нем также сведет наш контейнер. HealthCheck здесь обеспечит то же самое, если на нашем сайте заблокируется по той или иной причине.
Обратите внимание, что нам не нужно выпускать Docker CMD команда запустить Nginx, так как он будет унаследован от базового изображения.
Сочиняя его вместе
Теперь мы могли бы построить изображение Docker и запустить его из нашего терминала, используя стандартный CLI Docker. Тем не менее, я нахожу более приятной работать с Docker Compose даже с такими проектами с одним сервисом, как этот. Давайте заполним наш Docker-compose.yml Файл как так:
version: '3'
services:
web:
build: '.'
image: 'nikoheikkila/nikoheikkila.fi'
container_name: 'web-nginx'
restart: 'unless-stopped'
ports:
- '8080:8080'
Здесь нет ничего особенного. Мы объявляем услугу под названием Интернет который строит Dockerfile В нашем проекте root и отмечает его с помощью пользовательского имени. Политика перезапуска Если не остановилось Буду продолжать перезагрузить наш контейнер, если мы явно остановим его. Как последнее правило, мы связываем порт 8080 нашей хост -машины с тем же портом, обнаженным в контейнере.
Теперь давайте запустим Docker-Compose Up-Build -d . После того, как изображение было успешно построено, и контейнер работает (проверьте с Docker-Compose PS ) Мы должны быть в состоянии посетить http://localhost: 8080 с нашим браузером, и здесь лежит наш сайт.
Докер стоит Это
Это так, и все же это не так; Это зависит от вас. Если вы серьезно развернете это для производства, вам нужно будет установить объем SSL -сертификатов в контейнер, поскольку даже статические сайты не должны бродить по пустыне Интернета, не зашифрованной. Сегодня это не большая проблема с Let’s Encrypt and Cloudflare, которые облегчают процесс обеспечения вашего сайта. Установка собственных сертификатов в контейнер находится вне сферы действия этого урока, но в Интернете есть много хороших ресурсов.
С Docker вы полностью контролируете свою управляющую среду и можете развернуть ее где угодно с небольшим количеством работы. С другой стороны, я использую Zeit Теперь Для развертывания, потому что это можно настроить с помощью один файл JSON И вы сразу получите бесплатный сертификат SSL и непрерывные развертывания с их интеграцией GitHub или Gitlab. Компромисс — это то, что вы ничего не знаете о бегущей среде, кроме того, что она работает.
В качестве третьего варианта, вы можете настроить свой собственный частный сервер с Nginx или Apache, и просто отбросить там контент, если у вас есть более старые способы работы со стеками Linux. С низкоуровневыми капли из цифрового океана это было бы очень доступным решением.
Это абсолютно хорошо не использовать Docker для всего под солнцем. На самом деле, сегодня Серверный и FAAS заменили многие варианты использования Docker. Непрерывные, неизменные и мертвые простые развертывания в облаке удивительно просты в выполнении даже без Docker, а статически визуализированные сайты являются для них идеальным вариантом использования.
Оригинал: «https://dev.to/nikoheikkila/serving-gatsby-site-with-docker-multi-stage-build-57ep»