OpenShiftの機能紹介 ―― Dockerイメージの自動ビルド

CTC教育サービスはコラム「OpenShiftの機能紹介 ―― Dockerイメージの自動ビルド 」を公開しました。

＃＃＃

はじめに
　前回に引き続き、OpenShiftが提供する環境の全体像を踏まえて、「ImageStream」「BuildConfig」「DeployConfig」など、OpenShiftに固有の機能を紹介していきます。今回は、ビルド設定（BuildConfig）を用いて、Dockerイメージの作成を自動化する仕組みを説明します。

Dockerイメージのレイヤー構造
　はじめに、Dockerイメージ作成の基礎として、Dockerfileによるイメージ作成処理の流れを復習しておきましょう。Dockerfileでは、まずはじめに、「FROM」命令で出発点となるDockerイメージを指定します。指定のイメージからコンテナを起動した上で、「RUN」命令で指定されたコマンドを実行するなどして、変更を加えたものが新しいDockerイメージになります。できあがったDockerイメージは、また別のDockerfileから、新たな出発点として指定することができます。つまり、Dockerイメージは、順番に変更を重ねていく、レイヤー型の構造になっています。

　この構造は、OpenShiftの環境でも同じです。前回の図1に示した「OpenShiftの全体像」では、OpenShiftで扱うイメージの種類として、次の3つがあることを指摘しました。これらはちょうど、この順番でレイヤー構造を作ります。

•ベースイメージ：OSレベルのファイルのみが入ったイメージ
•開発テンプレートイメージ：開発に必要なフレームワークなどが入ったイメージ
•アプリケーションイメージ：実行可能なアプリケーションが入ったイメージ
DockerfileとSTIの使い分け
　OpenShiftの環境で新しいDockerイメージを作る際は、Dockerfileのほかに、STI（Source to Image）という仕組みを使うこともできます。厳密な決まりはありませんが、ベースイメージから開発テンプレートイメージを作る際はDockerfileを使用して、開発テンプレートイメージからアプリケーションイメージを作る際はSTIを使用することが多いようです。

　STIでは、コンテナの中でアプリケーションをビルドするスクリプトを用意しておきます。出発点となるイメージからコンテナを起動してアプリケーションのソースコードをダウンロードした後に、このスクリプトを実行することで新しいDockerイメージを作成します。Dockerfileからスクリプトを実行しても同じことができますが、アプリケーションイメージを作る際は、アプリケーションのビルド処理をスクリプトで実行することが多いため、最初からスクリプトの利用が前提となるSTIの方が設定が簡単になります。STIでは、ビルド処理のスクリプトに加えて、ユニットテスト用のスクリプトも利用できるので、簡易的なCI（Continuous Integration／継続的インテグレーション）の仕組みを作ることも可能です。

この続きは以下をご覧ください
(リンク »)