docker-composeでのrunとupの違いについて

Question

昨日からdockerの勉強を始めました

docker-compose runではコンテナを作成してサービスに引数付けて実行ですが、今回runを行った際に
イメージから作成されているのですが。runの動きとしてイメージの作成も行っている認識で大丈夫でしょうか？
upではイメージの作成からコンテナの作成
runではイメージの作成からコンテナを作成してサービスに対して命令を与える事が出来る

こちらの認識であってますでしょうか？

何卒宜しくお願い致します。

Answer 1

まず、 docker-compose up と docker-compose run は、どちらもコマンド実行時に Docker イメージが存在していなければ、Docker イメージを作ります。

これは Docker Compose でのはたらきというより、Docker Engine 側（docker run　など ）とも共通する動作です。

ですので「イメージの作成も行っている認識で大丈夫でしょうか？」については「その通りです」という答えです。

次に、 docker-compose up と docker-compose run の違いです。

通常は、 docker-compose up を使い、docker-compose.yaml ファイルで定義した通り、常に同じような環境で実行したい場合に使います。ほぼデフォルトで使うコマンドです（ただし、　docker container run とは少し意味合いが違い、あくまで Docker Compose はサービス単位で操作します）。

そして docker-compose run は、その対象サービスで1度だけコマンドを実行する目的に使います。よくあるのは、環境の初期化コマンドの実行だったり、データベースの初期設定用コマンドを実行するようなものです。

参考：

• docker-compose up
• docker-compose run

Comments

[kazshi]

親切なご回答ありがとうございます、docker-compose run初期化の際にサービスに対して命令を与えて（例えばDBのテストデータを入れるなど）を行いイメージからコンテナを作成してくれるのですね、
例えばrunの際に、実行したコマンドで作成されたデータはイメージに入り、再度コンテナ作成される認識であってますでしょうか？また、buildをした場合はコンテナをイメージする流れであってますでしょうか？
お忙しいところ恐縮ですが、教えていただけると嬉しいです
何卒宜しくお願い致します。

[zembutsu]

少し Docker 独特の考えが必要となります。たとえばコンテナ実行後の変更というのは、元のイメージを変更するのではありません。あくまでも作成したコンテナに対する変更であり、元々のイメージはそのまま残り続ける仕組みです。
これを踏まえまして、「run」は作成済みのイメージを元にした、コンテナ用のファイルシステム上への記録です。そのため、元々（docker-compose buildなどで）構築したイメージそのものには変更してくれません。もし、常に同じような変更を加えた Docker イメージを使うのであれば、 Dockerfile などでコマンドを入れ込むほうが適切と考えられます。
（例外として、 docker commit コマンドを使い、コンテナ用のイメージレイヤを Docker イメージに変更する方法もあります。ですが一般的ではなく、かなり特殊な事情を求められる場合でしょう。通常は Dockerifle の中などイメージの自動構築時に処理されるほうが、後々の使い勝手があがります）
そして、 docker-compose buildは、コンテナをイメージに変換するような考え方に違いのですが、正確には、Docker イメージを自動構築するためのコマンドです。docker-compose runで実行した（コンテナ用ファイルシステムへの変更）内容は、あくまで、対象となるコンテナだけに摘要されるものでして、元々の Docker イメージには手を加えません。

[kazshi]

早速のご回答ありがとうございます、runの命令はコンテナ作成時のみに適用されるのと、runでイメージを作成したい場合にはymlや、ドッカーファイルに入れればイメージ化ができるんですね。
そうすると、コンテナに対してデータ（DBでインサートなど）してもcommitなどを使用しなければイメージ化が出来ず、イメージ化したい場合にはビルド時にドッカーファイルなどにDBデータを追加するスクリプトを埋め込んだり、マウントフォルダにhtmlなど本番環境で使うデータなどを入れてからビルドを行行えば、それらを含めてイメージ化でき、AWSなどのコンテナサービスなどにデプロイの流れで考えがあってますでしょうか？何度も申し訳ございません。

[zembutsu]

最終的に別の場所で動かすための、元になる Docker イメージ、という意味であればお考えの通りです。
別の環境に動かす場合は、状況による、となりますが、毎回変更が発生しない作業であれば Docker イメージのなかに入れておく方が楽でしょう。

[kazshi]

お忙しいところありがとうございました、不明点が解消されました！