【Docker】イメージにソースコードを含める？

Question

タイトルの通りですが、Dockerイメージにはソースコードを含めるのが良いのでしょうか？
それとも、Dockerイメージにはソースコードを含めず実行時にホストのソースコードをマウントするのが良いでしょうか？

Dockerは開発環境でしか利用したことがなく、実際に本番運用されている方はどのようにされているのか知りたいです。

Answer 1

ホストのストレージを圧迫しなくて済む、イメージ展開、バックアップがしやすくなる等の理由で、基本的にはイメージサイズは小さい方が望ましいとされています。

rubyあるいはpythonのような、ソース=実行コードになっている場合は別ですが、例えばコンパイルした成果物のみ必要(npm packしたもの等)で、後は無くてもいいような場合は、multi stage build機能を使えば、イメージの見通しをよくすることができます。docker 17.05以降が必要ですが。
https://docs.docker.com/engine/userguide/eng-image/multistage-build/#use-multi-stage-builds

追記: セキュリティ的にも、余計なツール(コンパイラー等)が無い方が、万が一侵入された場合でもできることが少ないので、絶対ではないですが被害の拡大を防ぐことができる場合があります。

Comments

[退会済みユーザー]

そういう観点もあるのですね。
継続的インテグレーション、ポータビリティ、再現性という観点ではいかがでしょうか？
このあたりはトレードオフかとは思いますが、そのpros, consを踏まえた結果、みなさんがどちらで実運用されているのかが気になります。
残念ながら対象アプリがPHPなのでmulti stage buildは恩恵を受けられなさそうです。

[skitoy4321]

これは私の考えになるのですが、コンテナ技術というのは状態を持つ部分とそうではない部分を切り離し、そうではない部分のサイクルを早くするためにあると思っています。

その考えに立つと、ボリューム等で外部リソースを使うのは状態を持つということになるので、再現性や可搬性を重視するならばなるべく避けた方が良いと考えています。

ただ、ユニットテストでもサービス起動でもいいのですが、チェックアウト等のセットアップに時間がかかる場合もあり、結果として"重い"システムになって良くないという場合は外部リソースを使用するのもありかなと思います。

[退会済みユーザー]

ありがとうございました！

Answer 2

結論は状況次第で、運用方法など色々関わってきます。

状況を無視すれば、Dockerを使って本番環境を運用するのであれば、Dockerイメージにソースコードを同梱したほうがシンプルに済みます。

ただ、その「ソースコード」が公開して良くない場合に、そのファイルをDockerイメージに同梱した場合、Dockerイメージを公開されている場所 (docker hubとか)に置いてはいけないことになります。非公開のリポジトリを使えるかどうか、使えなければ同梱できない、使えるならそのリポジトリを使う前提で本番環境のデプロイ手順を構築する、といったように考えていくと良さそうです。

Comments

[退会済みユーザー]

運用の観点からご意見参考にさせていただきます！
ありがとうございました！