Estoy aprendiendo Docker. Muchas veces he visto que Dockerfile tiene el comando WORKDIR :
FROM node:latest RUN mkdir -p /usr/src/app WORKDIR /usr/src/app COPY package.json /usr/src/app/ RUN npm install COPY . /usr/src/app EXPOSE 3000 CMD [ “npm”, “start” ] ¿No puedo simplemente omitir WORKDIR y Copy y simplemente tener mi Dockerfile en la raíz de mi proyecto? ¿Cuáles son las desventajas de usar este enfoque?
Según la documentación :
La instrucción WORKDIR establece el directorio de trabajo para cualquier instrucción RUN, CMD, ENTRYPOINT, COPY y ADD que le sigue en el Dockerfile. Si WORKDIR no existe, se creará incluso si no se usa en ninguna instrucción posterior de Dockerfile.
Además, en las mejores prácticas de Docker te recomienda usarlo:
... debe usar WORKDIR en lugar de proliferar instrucciones como RUN cd ... && do-something, que son difíciles de leer, solucionar problemas y mantener.
Yo sugeriría mantenerlo.
Creo que puedes refactorizar tu Dockerfile a algo como:
FROM node:latest WORKDIR /usr/src/app COPY package.json . RUN npm install COPY . ./ EXPOSE 3000 CMD [ "npm", "start" ]no tienes que hacerlo
RUN mkdir -p /usr/src/app
Esto se creará automáticamente cuando especifique su WORKDIR
FROM node:latest WORKDIR /usr/src/app COPY package.json . RUN npm install COPY . ./ EXPOSE 3000 CMD [ “npm”, “start” ]Puede pensar en WORKDIR como un cd dentro del contenedor (afecta a los comandos que vienen más adelante en RUN , como el comando EJECUTAR). Si eliminó WORKDIR en su ejemplo anterior, RUN npm install no funcionaría porque no estaría en el directorio /usr/src/app dentro de su contenedor.
No veo cómo se relaciona esto con el lugar donde coloca su Dockerfile (ya que la ubicación de su Dockerfile en la máquina host no tiene nada que ver con el pwd dentro del contenedor). Puede colocar el Dockerfile donde desee en su proyecto. Sin embargo, el primer argumento para COPY es una ruta relativa, por lo que si mueve su Dockerfile, es posible que deba actualizar esos comandos COPY .