#docker #kubernetes #webpack-dev-server #minikube #node-sass
#docker #kubernetes #webpack-dev-server #minikube #узел-sass
Вопрос:
Я переношу приложение node / react / webpack на k8s и пытаюсь настроить среду разработки, которая использует функцию горячей перезагрузки webpack. При запуске этого с общим томом на minikube
:
ERROR in ./~/css-loader!./~/sass-loader/lib/loader.js?{"data":"$primary: #f9427f;$secondary: #171735;$navbar-back-rotation: 0;$navbar-link-rotation: 0;$login-background: url('/images/login-background.jpg');$secondary-background: url('/images/secondary-bg.jpg');"}!./src/sass/style.sass
Module build failed: Error: Node Sass does not yet support your current environment: Linux 64-bit with Unsupported runtime (67)
For more information on which environments are supported please see:
Запуск кода в контейнере сам по себе (в основном) работает — он запускается без ошибок и обслуживает страницу через docker run -it --rm --name=frontend --publish=3000:3000 <container hash>
#Dockerfile
FROM node:latest
RUN mkdir /code
ADD . /code/
WORKDIR /code/
RUN yarn cache clean amp;amp; yarn install --non-interactive amp;amp; npm rebuild node-sass
CMD npm run dev-docker
где dev-docker
in package.json
— это NODE_ENV=development npm run -- webpack --progress --hot --watch
Далее, закомментирование volumeMounts
ключа устраняет ошибку.
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
namespace: dev
name: web
labels:
app: web
spec:
replicas: 1
selector:
matchLabels:
app: frontend-container
template:
metadata:
labels:
app: frontend-container
spec:
volumes:
- name: frontend-repo
hostPath:
path: /Users/me/Projects/code/frontend
containers:
- name: web-container
image: localhost:5000/react:dev
ports:
- name: http
containerPort: 3000
protocol: TCP
volumeMounts:
- name: frontend-repo
mountPath: /code
env:
... # redacted for simplicity, assume works
Основываясь на том, что я нашел в другом месте, я считаю, что привязка к операционной системе, используемая ОС, создает node-sass
помехи между хостом и контейнером при введении общего тома. То есть процесс сборки образа создает привязки, которые будут работать для контейнера, но они перезаписываются при подключении общего тома.
Правильно ли это понимание? Как мне наилучшим образом структурировать вещи, чтобы разработчик мог работать со своим локальным репозиторием и видеть, что эти изменения автоматически отражаются в экземпляре кластера, без перестройки образов?
Ответ №1:
Моя гипотеза подтвердилась — модули узла создавались для контейнера, но перезаписывались volumeMount
. Подход, который лучше всего работал на этом этапе, заключался в том, чтобы создавать требования в качестве точки входа в контейнер, чтобы он выполнялся при запуске контейнера, а не только во время сборки.
# Dockerfile
CMD RUN yarn cache clean amp;amp; yarn install --non-interactive --force amp;amp; npm run dev-docker