一般的に、アプリケーションを実行するためのコンテナイメージを作成する手法として、Dockerfileを作成し、Dockerというサービスを利用し、コンテナイメージをビルドする方法をとることが多いと思います。しかし、コンテナイメージをビルドするツール・方法が多く提案されています。そこで、本記事はコンテナイメージビルドツールの一つである、S2I (Source to Image) について紹介します。
Source To Imageとは?
S2I(Source to Image)とは、コンテナイメージをビルドするプロセスを、アプリケーションの開発側と環境構築側に分けて、段階的に実行するコンテナイメージビルダーである。
S2Iでのビルドは、S2I buidによって実行される。S2I buidを実行すると、開発側が作成したアプリケーションソースコード (例えば、pythonやGoのスクリプト)をinputにし、環境構築側が作成した実行環境のコンテナイメージ であるs2i builder imageを取得し、アプリケーションに関する新規のコンテナイメージを生成する。要するに、S2IはアプリケーションソースコードからDockerイメージをビルドする仕組みである。
S2Iを利用するメリットの一つは、アプリケーション開発側の負担が減り、開発側がアプリケーション開発に専念できることである。なぜならば、アプリケーション開発と環境構築のプロセスが分けられており、開発側が環境構築を行うためのファイルを作成する必要がなくなるからである。
S2Iに関する基本用語について
ここで、S2Iに関する用語、S2I builder image、S2I scriptについて説明する。
S2I builder image
ビルド処理を実行するS2Iスクリプトとベースイメージ (Ubuntu、CentOS7, Debianなどのイメージのこと)を組み合わせ生成されるイメージである。アプリケーションのビルドと、実行環境をアセンブルするDockerイメージである。
ここで出てきたS2I scriptで様々な処理を行っている。次はS2I scriptの中身について確認する。
s2i script
S2I scriptはbuilder imageの実行コンテナ内で実行されるスクリプト群で、run,assemble,save-artifactsといったスクリプトがある。主にアプリケーションのビルドを行うスクリプト「assemble」と、アプリケーションをデプロイしたミドルウェアを起動するスクリプト「run」の2つは、builderイメージの実行時に必須のスクリプトである。
S2I scritは以下の主に以下の2つで構成されている。
assemble script (必須)
- ソースコードからアプリケーションのアーティファクト（成果物）をビルドし、それらをイメージ内の適切なディレクトリに配置する。
- 例えば、GitやGitHubなどのソースリポジトリからcloneしたソースの処理を行う。
- assembleスクリプトのワークフローの具体例については、具体的なソースコードで確認していく。以下に、実際にPythonのコンテナイメージを作成するためのスクリプト例
assemble.shを示す：
#!/bin/bash -e
if [[ "$1" == "-h" ]]; then
exec /usr/libexec/s2i/usage
fi
# アプリケーション、例えば、sample.py, requirements.txtをアプリの実行を行うディレクトリへコピーし配置している
echo "---> Installing application source..."
cp -Rf /tmp/src/. ./
# requirements.txtを用いて、pip installでライブラリのインストールを行っている
echo "---> Building application from source..."
pip install --upgrade pip
if [ -f requirements.txt ]; then
pip install -r requirements.txt
fi
Pythonはスクリプト言語のため、今回アーティファクトのビルドを行うプロセスはないことに注意。
run script (required)
- アプリケーションを実行するためのスクリプト
- 実際にpythonスクリプト
sample.pyを実行するrun スクリプト例run.sh
run
#!/bin/bash -e
python sample.py
他にもオプションとして以下のようなスクリプトを追加することも可能である：
- usage script (optional)
- ユーザーにイメージの利用方法を通知するためのスクリプト
- save-artifacts (optional)
- S2Iの機能の一つである
incremental build(増分ビルド)を実行する際に必要となる。ここでは、説明しない。
- S2Iの機能の一つである
DockerfileのみによるビルドとS2Iビルドの比較
ここでは、DockerfileのみによるコンテナイメージのビルドとS2Iによるビルド、それぞれのビルドプロセスの比較を簡単に行う。結論から言うと、この2つのプロセスの違いは以下である：
| Dockerfileのみのビルド | S2Iビルド |
|---|---|
| ビルドプロセス中で開発側、環境構築側の分担がない | 開発側、環境構築側の分担がある |
| Dockerfileのみ | Dockerfile + S2I script |
| コンテナイメージのビルドは1回のみ | コンテナイメージのビルドは2段階行う |
次では、それぞれのビルドワークフローを図で解説していく。
Dockerfileのみを用いたビルド
Dockerfileのみのビルドでは、ビルドプロセスに開発側、環境構築側の分担がなく、コンテナイメージの作成が以下図のように行われる。
S2Iビルドのワークフロー
まず、S2Iビルドのワークフローについて解説する。今回の説明では、GitHub、DockerHubの外部レジストリを利用することを仮定しているが、S2Iのワークフローを内部レジストリのみを使用したローカル環境内で実行することも可能である。
1. S2I builder imageの生成
環境構築側がDockerfile、S2I scriptを作成し、Dockerを使い、Dockerビルドを行い、S2I builder imageを生成する。その後、コンテナイメージレジストリ(例えば、GitHub, DockerHub)へ保存する。
2. アプリケーションソースコードの開発
アプリケーションの開発側がアプリケーション用のソースコードを作成し、 ソースコードリポジトリ (例えば、Git,GitHub)へ保存する。
3. S2Iビルドの実行
ソースコードリポジトリから開発者が作成したアプリケーションソースコードとS2I builder imageを、それぞれ取得し、S2I buildを実行する。すると新規のコンテナイメージが作成されるので、これをコンテナイメージレジストリへ保存する。
より細かい比較については、ローカル環境による具体的なビルドにより、次回確認していきたいと思います。以下に参考にした文献やS2Iについて書かれた記事をあげておきます。
参考文献
- OpenShift徹底活用ガイド
- Source-To-Image (S2I)公式ドキュメント
- [OpenShift]自作のS2Iスクリプトを使ってローカルにあるPerlスクリプトをS2Iビルドしてデプロイする
- Minishiftで遊んでみよう！手軽にkubernetesを体験するの巻
- MACOSにS2IコマンドをインストールしてS2Iビルドする
- OpenShift v3 と source-to-image (s2i)
- S2I work flow
- 第5章 S2I イメージのテスト
- S2Iに再入門
- OpenShift Origin構築手順メモ
- OpenShift OriginによるDockerイメージ管理（1）〜イメージストリームを理解する
- OpenShift OriginによるDockerイメージ管理（2）〜Dockerfileによるイメージビルドを自動化
- OpenShift OriginによるDockerイメージ管理（3）〜Dockerfileからイメージを作成する際のお作法
- OpenShift OriginによるDockerイメージ管理（4）〜S2Iによるイメージビルド