Вы могли бы начать с чтения документации Kubernetes и понимания того, что просто, а что нет. Вы больше всего заинтересованы в развертываниях и услугах, и, возможно, Ingress. Настройка MongoDB со связанным постоянным состоянием будет более сложной, и вы можете посмотреть на готовое решение, такое как диаграмма стабильного / mongodb Helm или официальный оператор MongoDB .
Обратите внимание, что важной частью настройки Kubernetes является то, что почти всегда будет несколько узлов, и вы не получите большого контроля над тем, на каком узле будет размещен Pod. В частности, это означает, что Docker Compose volumes:, который вы показываете, не будет хорошо работать в среде Kubernetes - в дополнение к обычной работе по развертыванию Kubernetes, вам также необходимо будет реплицировать исходный код приложения на каждый узел. Это вдвое больше работы для одного и того же развертывания. Обычно вы хотите, чтобы весь код приложения содержался в образе Docker, а типичный Docker-файл на основе узла выглядит примерно так:
FROM node:10
WORKDIR /app
COPY package.json yarn.lock ./
RUN yarn install
COPY ./ ./
RUN yarn build
EXPOSE 3000
CMD yarn start
Просто в файле docker-compose.yml, который вы показываете:
volumes: существенно отличает ваши контейнеры от того, что вы могли бы использовать в производстве; удалите их.
Не беспокойтесь о настройке внутренних портов контейнера. В обычном Docker, Docker Compose и Kubernetes вы можете переназначить внутренний контейнерный порт в произвольно доступный внешний порт во время развертывания. Вы можете выбрать фиксированные номера здесь, и это нормально.
Некоторые детали, которые вы показываете, такие как порты контейнера expose: и значение по умолчанию command: для запуска, являются правильными частями образа (каждый раз, когда вы запускаете образ, они будут идентичны), поэтому переместите их в Dockerfile.
links: в настоящее время излишни, и вы можете просто удалить их. В Docker Compose вы всегда можете найти имя другой службы по имени ее служебного блока.
Названия других связанных служб будут отличаться в разных средах. Например, MongoDB может быть на localhost, когда вы на самом деле разрабатываете свое приложение вне Docker, mongo в конфигурации, которую вы показываете, mongo.myapp.svc.cluster.local в Kubernetes, или вы можете запустить его полностью вне Docker. Обычно вы хотите, чтобы они были настраиваемыми, обычно с переменными среды.
Это дает вам docker-compose.yml файл немного больше похожий на:
version: '3'
services:
backend:
build: ./backend
environment:
- MONGO_URL: 'mongo://mongo'
ports:
- 3000:3000
frontend:
build: './frontend'
environment:
- BACKEND_URL: 'http://backend'
ports:
- 8000:8000
mongo:
image: mongo
ports:
- "27017:27017"
Как @frankd намекнул в своих ответах, также очень распространено использование такого инструмента, как Webpack, для предварительной компиляции приложения React в набор статических файлов. В зависимости от того, как вы на самом деле это развертываете, может иметь смысл запустить этот этап компиляции заблаговременно и отправить эти скомпилированные файлы Javascript и CSS в какой-либо другой сервис статического хостинга и полностью удалить его из Docker / Kubernetes.