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/継続的インテグレーション)の仕組みを作ることも可能です。
この続きは以下をご覧ください
http://www.school.ctc-g.co.jp/columns/nakai/nakai85.html
ソーシャルもやってます!