DockerfileのWORKDIRのポイントは何ですか？

私はDockerを学んでいます。私は何度もそれDockerfileが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” ] 

省略WORKDIRしてプロジェクトのルートにCopy置くことはできませんDockerfileか？このアプローチを使用することの欠点は何ですか？

ドキュメントによると：

WORKDIR命令は、Dockerfileでそれに続くすべてのRUN、CMD、ENTRYPOINT、COPY、およびADD命令の作業ディレクトリを設定します。WORKDIRが存在しない場合は、後続のDockerfile命令で使用されていなくても作成されます。

また、Dockerのベストプラクティスでは、それを使用することをお勧めします。

... RUN cd…&& do-somethingのような、読み取り、トラブルシューティング、および保守が難しい指示を増殖させるのではなく、WORKDIRを使用する必要があります。

それを維持することをお勧めします。

Dockerfileを次のようなものにリファクタリングできると思います。

FROM node:latest
WORKDIR /usr/src/app
COPY package.json .
RUN npm install
COPY . ./
EXPOSE 3000
CMD [ “npm”, “start” ] 

あなたはする必要はありません

RUN mkdir -p /usr/src/app

これは、指定したときに自動的に作成されます WORKDIR

FROM node:latest
WORKDIR /usr/src/app
COPY package.json .
RUN npm install
COPY . ./
EXPOSE 3000
CMD [ “npm”, “start” ] 

コンテナー内のWORKDIRように考えることができますcd（コマンドのように、Dockerfileの後半にあるコマンドに影響しますRUN）。WORKDIR上記の例で削除した場合、コンテナ内RUN npm installの/usr/src/appディレクトリにいないため、機能しません。

これがDockerfileの配置場所にどのように関係するかはわかりません（ホストマシン上のDockerfileの場所はコンテナー内のpwdとは関係がないため）。プロジェクト内のどこにでもDockerfileを配置できます。ただし、の最初の引数COPYは相対パスであるため、Dockerfileを移動する場合は、それらのCOPYコマンドを更新する必要がある場合があります。

WORKDIRを適用する前。ここでWORKDIRは間違った場所にあり、賢く使用されていません。

FROM microsoft/aspnetcore:2
COPY --from=build-env /publish /publish
WORKDIR /publish
ENTRYPOINT ["dotnet", "/publish/api.dll"]

上記のコードを修正してWORKDIRを正しい場所に配置し、次のステートメントを削除して最適化しました /Publish

FROM microsoft/aspnetcore:2
WORKDIR /publish
COPY --from=build-env /publish .
ENTRYPOINT ["dotnet", "/api.dll"]

のターゲットディレクトリ名としてvarsを使用することに注意してください。これをWORKDIR行うと、「何も正規化できません」という致命的なエラーが発生するようです。IMO、WORKDIR同じように動作することも指摘する価値mkdir -p <path>があります。つまり、パスのすべての要素がまだ存在しない場合は作成されます。

更新：多段階ビルドの実行中に変数関連の問題（上記）に遭遇しました-変数の使用は問題ないように見えます-（変数）が「スコープ内」にあるWORKDIR場合、たとえば、2番目の参照は失敗します...

FROM <some image>
ENV varname varval
WORKDIR $varname

FROM <some other image>
WORKDIR $varname

一方、これは成功します...

FROM <some image>
ENV varname varval
WORKDIR $varname

FROM <some other image>
ENV varname varval
WORKDIR $varname

.oO（多分それはドキュメントにあります＆私はそれを逃しました）

WORKDIR継続的な統合フローに影響を与える可能性があるため、設定する場所には注意してください。たとえば、に設定すると、セットアップ時にリモートCircleCIが実行している/home/circleci/projectようなエラーが発生.sshします。