Je crée une application React en utilisant docker build avec le Dockerfile suivant:

# build env
FROM node:13.12.0-alpine as build
WORKDIR /app
ENV PATH /app/node_modules/.bin:$PATH
COPY package.json ./
COPY package-lock.json ./
RUN npm ci
RUN npm install react-scripts -g
RUN npm install --save @fortawesome/fontawesome-free
RUN apk add nano
RUN apk add vim
COPY . ./
RUN npm run build

# production env
FROM nginx:stable-alpine
COPY --from=build /app/build /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

Je crois que le Dockerfile n'est pas d'une importance extrême ici cependant. Dans mon code source, il y a un fichier de configuration principal, que je souhaite laisser en dehors du docker image pour pouvoir déployer facilement mon application React. Cela provoque une erreur de compilation lors de la commande Dockerfile RUN npm run build, car le compilateur ne trouve pas un fichier référencé par un autre fichier. Pour les versions de développement, ce n'était pas un problème, puisque npm start n'est pas si sensible.

J'ajouterais le fichier de configuration en tant que docker volume dans l'application finale, de sorte que le code puisse le trouver sans problème. Je me demande simplement comment aborder une situation comme celle-ci, puisqu'elle n'est pas venue plus tôt sur mon chemin?

N'hésitez pas non plus à commenter ou à optimiser mon Dockerfile, car je ne suis pas sûr, par exemple si Nginx est la voie à suivre dans ces versions de production pour les applications frontales de site Web.

0
Aarni Joensuu 3 sept. 2020 à 15:55

2 réponses

Meilleure réponse

Si votre application require est actuellement le fichier de configuration, cela s'apparente à "coder en dur" les valeurs qu'il contient au moment de la construction, comme vous l'avez remarqué. Si vous avez besoin de pouvoir permuter dynamiquement dans un autre fichier de configuration au moment de l'exécution, vous devrez utiliser par ex. fetch() pour le charger, pas pour le regrouper (comme require le fait).

Si la configuration des choses au moment de la construction est correcte, alors je suggérerais également de regarder Variables d'environnement personnalisées de l'ARC; vous pouvez ensuite injecter les valeurs appropriées en tant que variables d'environnement au moment de la construction.

Au-delà, si vous recherchez une critique pour votre Dockerfile, d'un Aarni à un autre:

  • Votre package.json est cassé si vous devez faire autre chose que npm ci ou yarn pendant une compilation pour installer des éléments. react-scripts doit être une dépendance de développement et Font Awesome doit être une dépendance régulière.
  • Vous n'avez pas besoin de nano et vim dans le conteneur temporaire, et même si vous en aviez besoin, il serait préférable de les apk add en une seule étape.
  • Vous ne devriez pas avoir besoin de modifier le PATH dans le conteneur de construction.
  • Utiliser Nginx est absolument parfait.
# build env
FROM node:13.12.0-alpine as build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . ./
RUN npm run build

# production env
FROM nginx:stable-alpine
COPY --from=build /app/build /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]
1
AKX 3 sept. 2020 à 13:05

Voici un exemple de mon fichier docker de réaction. Peut-être pouvez-vous l'utiliser si vous souhaitez optimiser.

PS: je l'exécute depuis kubernetes.

# #############################   Stage 0, Build the app   #####################
# pull official base image
FROM node:13.12.0-alpine as build-stage
# set working directory
WORKDIR /app
# add `/app/node_modules/.bin` to $PATH
ENV PATH /app/node_modules/.bin:$PATH
# install app dependencies
COPY package*.json ./
#RUN npm install
RUN npm install

# add app
COPY . ./

#build for production
RUN npm run-script build

# #### Stage 1, push the compressed  built app into nginx ####
FROM nginx:1.17

COPY --from=build-stage /app/build/ /usr/share/nginx/html
  
0
Seeker 3 sept. 2020 à 13:09