一般的に、アプリケーションを実行するためのコンテナイメージを作成する手法として、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を示す：

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

run.sh

#!/bin/bash -e
python sample.py

他にもオプションとして以下のようなスクリプトを追加することも可能である：

usage script (optional)
- ユーザーにイメージの利用方法を通知するためのスクリプト
save-artifacts (optional)
- S2Iの機能の一つであるincremental build (増分ビルド)を実行する際に必要となる。ここでは、説明しない。

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について書かれた記事をあげておきます。

参考文献