Докеризация React Начало работы

Один из недостатков, который влияет на команды при разработке программного обеспечения, — это совместное использование общей среды, которая позволяет всем в команде строить с учетом фреймворков и зависимостей.

Одним из решений этой проблемы может быть использование контейнеров.

Контейнеры иногда определяются как облегченные виртуальные машины.

Запуск контейнера аналогичен запуску виртуальной машины с той лишь заметной разницей, что для взаимодействия с ней (логирование, запуск команд, запуск приложений) обычно используется интерфейс командной строки Docker.

Как и в случае с виртуальными машинами, у контейнеров есть образы, которые можно создавать и запускать.

Контейнеры абстрагируют операционные системы, а не оборудование.

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

В этом посте я буду делать докеризацию приложения React.

Докер

Первым шагом будет загрузка и установка Docker Desktop.

Docker спроектирован как клиент-серверное решение. На стороне клиента предоставляется интерфейс командной строки, который позволяет взаимодействовать с демоном, работающим на вашем компьютере.

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

В этой статье я буду использовать контейнеры Windows.

Докеризованное приложение состоит из исходного кода и Dockerfile. Dockerfile позволяет взаимодействовать с Docker и инструктировать, как создавать и запускать контейнер и образ внутри него.

В Dockerfile в его простейшей форме обычно можно было бы:

• Выберите образ для контейнера из реестра или из общедоступных на Docker Hub. Например, в этом посте будет использовано следующее изображение:

• Настройте среду в соответствии с тем, что приложение должно делать (например, открывать порты).
• Запустите исполняемые файлы внутри контейнера. На этом шаге можно указать команду запуска двигателя при запуске.

Для справки это будет типичный Dockerfile:

FROM mcr.microsoft.com/dotnet/core/runtime:3.1-nanoserver-1909
WORKDIR /app
ENTRYPOINT ["dotnet", "website.dll"]

ОТ

Инструкция FROM инициализирует новый этап сборки и устанавливает Базовый образ для последующих инструкций. Таким образом, действительный Dockerfile должен начинаться с инструкции FROM. Изображение может быть любым допустимым изображением — особенно легко начать с вытягивания изображения из Общедоступных репозиториев.

РАБОЧИЙ КАТАЛОГ

Инструкция WORKDIR задает рабочий каталог для любых инструкций RUN, CMD, ENTRYPOINT, COPY и ADD, которые следуют за ней в Dockerfile.

ВХОД

ENTRYPOINT позволяет настроить контейнер, который будет работать как исполняемый файл.

Вкратце, ENTRYPOINT [“dotnet”, “website.dll”] аналогично запуску контейнера с использованием настроенного образа, входу в него и вводу «dotnet website.dll».

Докеризация интерфейса React

Чтобы создать тривиальное веб-приложение с использованием React, я следовал этому хорошему руководству по началу работы, состоящему из нескольких частей:

Также я взял рабочий код с официального стартапа:

Я немного упростил предлагаемую конфигурацию веб-пакета:

Короче говоря, я удалил предложенную выходную папку и сохранил папку dist, которая используется по умолчанию.

Кроме того, начиная с веб-пакета 4, больше нет необходимости устанавливать точку входа так далеко, как в /src/index.js.

Я также изменил index.js, чтобы использовать JSX, расширение синтаксиса для JavaScript.

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

Эти шаги можно автоматизировать с помощью «Dockerfile», который я использовал:

FROM node:latest
WORKDIR /usr/src/app
COPY package.json ./
RUN npm install
COPY . .
EXPOSE 80
ENTRYPOINT npx webpack-dev-server --host 0.0.0.0 --port 80

Мне пришлось явно попросить webpack-dev-server прослушивать IP 0.0.0.0, так как в противном случае я получал ошибку EMPTY_RESPONSE. Контейнер автоматически перенаправляет поступающие извне вызовы на IP-адрес 0.0.0.0, в то время как webpack-dev-server настроен на привязку к локальному хосту 127.0.0.1.

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

docker build . -t frontend

Только что построенный образ теперь будет виден работающим:

docker images
REPOSITORY     TAG       IMAGE ID            CREATED        SIZE
frontend       latest    52159d9a7188        5 days ago     1.05GB
node           latest    07e774543bdf        2 weeks ago    939MB

Два образа доступны локально, один содержит установку Node.js, другой создан на основе этого с нашим исходным кодом в папке «/usr/src/app».

Настало время запустить контейнер, это сделает следующая команда:

docker run -p 49160:80 -d frontend

Бег:

docker ps

Покажет информацию о запущенном контейнере.

Начало работы с React также будет доступно для просмотра.

Работа по протоколу HTTPS

Запуск HTTPS при разработке потребует, чтобы SSL-сертификат был доверенным и монтировался в томе внутри контейнера.

Файл Dockerfile нужно будет изменить, так как «webpack-dev-server» нужно будет настроить для использования только что созданного сертификата.

FROM node:latest
WORKDIR /usr/src/app
COPY package.json ./
RUN npm install
COPY . .
EXPOSE 80
ENTRYPOINT npx webpack-dev-server --host 0.0.0.0 --https --port 443 --pfx=/etc/ssl/certs/backend.pfx --pfx-passphrase=**yourpassword**

Изменения, которые я сделал, где:

• Порт теперь 443
• Мы ссылаемся на сертификат с именем «backend.pfx».
• Передаем пароль для доступа к нему

После изменения Dockerfile нам нужно будет пересобрать образ:

docker build . -t frontend

Одним из способов создания самозаверяющего сертификата и доверия к нему может быть использование OpenSSL. Однако сегодня я буду использовать инструмент «dotnet dev-certs».

Шаги по созданию самозаверяющего сертификата и доверию ему подробно описаны здесь:

После экспорта файла .pfx в папку «$Env:USERPROFILE\.aspnet\https» его можно смонтировать как том, передав следующий параметр команде «docker run»:

• -v $Env:USERPROFILE\.aspnet\https:/etc/ssl/certs/ интерфейс:последний

Последняя команда будет:

docker run --rm -it -p 443:443 -v $Env:USERPROFILE\.aspnet\https:/etc/ssl/certs/ frontend:latest

Компиляция JSX вручную

Если вам интересно посмотреть, что делает Вавилон под деревом, посмотрите этот отличный ответ:

Я установил Babel CLI:

npm install babel-cli --save-dev

Затем я преобразовал файл JSX вручную:

npx babel --plugins transform-react-jsx .\src\index.js

Это был результат:

Сводка

Переключение на контейнеры в процессе разработки позволяет приложению работать изолированно от выбранной ОС.

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