読者です 読者をやめる 読者になる 読者になる

GeekFactory

int128.hatenablog.com

Dockerfileでソフトウェアの実行環境や実行方法を明示する

docker continuous delivery

現在、ソースコードと一緒にビルドスクリプトを置くことで、ソフトウェアのビルド方法を明示することが慣習になっています。 今後、リポジトリソースコードと一緒にDockerfileを置くことで、ソフトウェアの実行環境や実行方法を明示することが一般的になるかもしれないと考えています。

ゆるふわな内容ですが、本稿ではDockerfileが何の役に立つか考えたいと思います。

背景

リポジトリにあるソフトウェアは、何らかの環境で実行されて初めて価値を生み出します。 そのため、実行環境や実行方法を明示しておくことが望ましいと思います。 環境構築や実行の手順はソフトウェアに付随するドキュメントに書くことが一般的ですが、しばしば以下のような問題が発生します。

  • 手順が複雑で時間がかかる
  • 明文化されていない手順があったりする
  • 環境の状態によって問題が起きる

そのため、環境構築や実行を以下のように改善する必要があります。

  • 短時間で完了すること
  • 誰でも簡単にできること
  • 誰がどの環境でやっても同じ結果が得られること

解決案

Dockerfileでソフトウェアの実行に必要な環境やソフトウェアの実行方法を明示します。 具体的には、以下を宣言します。

  • 環境構築の手順(RUN)
  • ソフトウェアの実行方法(CMD)
  • 実行時に公開するポート(EXPOSE)
  • 永続化が必要なデータ(VOLUME)

Dockerfileの仕様にはありませんが、以下もドキュメントやコメントで補足しておくことが望ましいと思います。

  • 実行時に依存する外部サービス(DB, MQ, REST API等)
  • 実行時に設定可能な環境変数
  • ログの取り扱い方法(標準出力、永続化領域のファイル)

これにより、Dockerの実行環境さえあれば、誰でも簡単にソフトウェアを実行できるようになります。 たとえDockerが使えない環境であっても、Dockerfileを参考にして環境を構築することも可能です。

ビルド環境も同様

コンパイルが必要な言語では、ビルド環境についても同じ考え方を適用できます。 Dockerfileでソフトウェアのビルドに必要な環境やビルド方法を明示することで、以下の問題を解消できます。

  • ビルド環境の差異による問題を防ぐ(コンパイラ、依存ライブラリ等)
  • ビルド環境の維持管理を省力化する

ビルド環境と実行環境は一般に構成が異なるので、別のDockerfileで管理した方がよいと思います。 このあたりはソフトウェアの種類(Webアプリ、ツール、ライブラリ)によって異なるので、別の記事で書きたいと思います。

まとめ

Dockerfileでソフトウェアの実行環境や実行方法を明示することで、誰でも簡単にソフトウェアを実行できるようになります。 また、ビルド環境についても同様の考え方を適用できます。

このような考え方はTwelve Factor Appに書かれており、HerokuのようなPaaSやTravis CIのようなCI as a Serviceですでに実現されています。 しかしながら、Dockerfileで記述形式を標準化することで、ソフトウェアのPortabilityが向上するのではないかと考えています。