私は多くのdockerfilesがすべてのように、RUN文で手順を構築含まれ見てきました：私の質問があるdockerfileのRUNスクリプトとbashスクリプトの違いは何ですか？
RUN echo "Hello" &&
cd /tmp &&
mv a.txt b.txt &&
...
and so on...
：私は、構文を強調与え、単一のbashスクリプトでこれらの命令を置き換える上の利点/欠点は、何ループ機能など？ のような何か：
COPY ./script.sh /tmp
RUN bash /tmp/script.sh
、その後
#!/bin/bash
echo "hello" ;
cd /tmp ;
mv a.txt b.txt ;
...
ありがとう！
主な違いは、画像にbashスクリプトCOPYを入れると、実行中のコンテナで検査できるようになりますが、RUNコマンドはもう少し不透明です。そのようなファイルにあなたのコマンドを置くことは、おそらく他の理由からより管理しやすいでしょう：あなたのVCSの履歴の変更はもう少し明確になり、より複雑なスクリプトの場合は、スクリプトを使ってRUNコマンドでDockerfileに埋め込まれているのではなく、別のファイルです。
COPYとRUN余分な画像層（対自体でわずかRUN）をもたらすであろうがそうでなければ結果は、（両方の場合において、もしコマンドの同じセットを実行している）と同じです。
shellスクリプトを実行すると、より詳細な制御が可能になると思います。
たとえば、if-elseステートメントを実行して、コマンドが失敗したかどうかを確認し、コマンドが処理されるコードパスを指定できます。 RUNはより単純ですが、戻りコードが0ではない場合は、すぐにビルドに失敗します。
明らかに、あなたには比較的単純なものがあり、大きな違いはありません。私がここで見ることができる唯一の影響は、コードの可読性の側面です。誰かが何が起きているのかを知るためには、shell scriptを読んで、すべてを1つのファイルにまとめることと比較する必要があります。
私はそれが正しい仕事のための正しいツールを使用することになると思います。単純なコマンドで、複雑なロジック処理を必要としない場合は、RUNを実行します。
実行後にスクリプトファイルを削除することは良い方法かもしれませんが、そうではありませんか？ – vbsessa
私はその質問について強い意見を持っていません。私は通常、スクリプトをそのまま残していますが、おそらくそれはあなたのソースで既に利用可能であると言えます...だから何でもいいと思います:) – larsks
最後の違いは、 'docker history'はシェルスクリプトの中で実行されるコマンドを表示しませんあなたがスクリプトを実行したことだけです。 – BMitch