開発用と本番用のDockerfileの二重管理を解消

開発部門にとってうれしい機能「マルチステージビルド」とは？

　こんにちは。日本ヒューレットパッカード（HPE）のオープンソース・Linuxテクノロジーエバンジェリストの古賀政純です。前回の記事では、「Docker」がもたらす開発基盤導入の変革と、HPEの開発部門におけるDocker導入の効果について紹介しました。今回は、開発部門にとってうれしいDockerの画期的な仕組みについて解説します。

Docker環境におけるアプリケーション開発

　一般に、Docker環境に限らず、開発環境では、アプリケーションの開発を行う際に、コンパイラ、開発用のヘッダファイル、ライブラリ類などの「開発ツール」をインストールしなければなりません。開発者はそれらのツールを駆使し、ソフトウェアの設計図であるソースコードから実行ファイルなどを生成します。

　ソースコードからアプリケーションの実行ファイルなどを生成する作業は、一般に「ビルド」と呼ばれます。開発環境は、アプリケーションの実行ファイルの他に、さまざまな開発ツールもインストールされた状態になっています。開発ツールやビルド作業時の作業ログが入っている状態なので、そのままでは本番環境に出すことはありません。そのため、本番環境には、開発ツールや作業ログなどを取り除いて、アプリケーションの実行ファイルのみが稼働する実行環境を作らなければなりません。

　開発者は、ビルド済みのアプリケーションの実行ファイルを開発環境から本番環境にコピーし、かつ開発ツールがない状態で正常に動作するように実行環境を整える必要があります。

図1．一般的なアプリケーション開発環境と本番環境への配備

　Docker環境におけるアプリケーション開発においても、開発ツールの導入や実行ファイルのコピーなどの作業が行われていますが、アプリケーションをビルドするための開発用のDockerイメージと本番用のDockerイメージが必要であり、それらのDockerイメージを生成するために、開発用のDockerfileと本番用のDockerfileを持つケースが少なくありません。

　以前の記事で、Dockerイメージを生成する手順を自動化、省力化する仕組みとして、Dockerfileを紹介しました。Dockerfileがあれば、Dockerイメージの入手やコンテナへのアプリケーションのインストールといった面倒な作業を自動で行うことは、今までの記事でも取り上げた通りです。アプリケーションのビルド手順やインストール手順が書かれたDockerfileをDockerエンジンに読み込ませることにより、アプリケーション入りのDockerイメージを自動で生成してくれます。

　しかし、Dockerを採用する多くの開発部門では、本番用のDockerfileと開発用のDockerfileを二重管理しなければならない問題に直面しています。開発用のDockerイメージにアプリケーションの実行ファイル以外に、本番環境には不要な開発ツールなどが多数含まれているため、本番環境向けには、これらの開発ツールなどを含まない形で、アプリケーションの実行ファイルのみを含むDockerイメージを作らなければなりません。

　また、開発用のDockerイメージから起動したコンテナ内のアプリケーションの実行ファイルを開発者が手動でコピーし、本番用のDockerイメージに埋め込む煩雑な作業に悩まされています。