17.3. チュートリアル: OpenShift の概念
17.3.1. Source-to-Image (S2I)
Source-to-Image (S2I) は、ソースコードから再現可能なコンテナーイメージをビルドするためのツールキットとワークフローです。S2I は、コンテナーイメージにソースコードを挿入し、コンテナーにソースコードを準備させることで、すぐに実行できるイメージを生成します。自己アセンブルするビルダーイメージを作成することにより、コンテナーイメージを使用してランタイム環境のバージョン管理を行うのとまったく同じように、ビルド環境のバージョン管理と制御を行うことができます。
17.3.1.1. 仕組み
Ruby などの動的言語の場合、ビルド時環境とランタイム環境は通常同じです。Ruby、Bundler、Rake、Apache、GCC、および Ruby アプリケーションのセットアップと実行に必要なその他すべてのパッケージがすでにインストールされていると仮定した場合、ビルダーイメージは次の手順を実行します。
- ビルダーイメージが、既知のディレクトリーにアプリケーションソースが注入されたコンテナーを起動します。
- コンテナープロセスが、そのソースコードを適切な実行可能なセットアップに変換します。たとえば、Bundler を使用して依存関係をインストールし、Apache による Ruby 設定ファイルの検索先として事前設定されているディレクトリーにソースコードを移動します。
- 次に、新しいコンテナーをコミットし、イメージのエントリーポイントを、Apache を起動して Ruby アプリケーションをホストするスクリプトとして設定します。
C、C++、Go、Java などのコンパイル言語の場合、コンパイルに必要な依存関係がランタイムアーティファクトのサイズを上回る可能性があります。ランタイムイメージのサイズを抑えるために、S2I は複数ステップのビルドプロセスを可能にします。このプロセスでは、実行可能ファイルなどのバイナリーアーティファクトが 1 つ目のビルダーイメージに作成および抽出されて、実行可能プログラムを正しい場所に配置する 2 つ目のランタイムイメージに挿入されます。
たとえば、Tomcat と Maven の再現可能なビルドパイプラインを作成するには、次の手順を実行します。
- WAR ファイルを注入する予定の、OpenJDK と Tomcat を含むビルダーイメージを作成します。
- 1 つ目の Maven イメージとその他の標準依存関係の上にレイヤーとして追加し、Maven プロジェクトを注入する予定の 2 つ目のイメージを作成します。
- Java アプリケーションソースと Maven イメージを使用して S2I を起動し、目的のアプリケーション WAR を作成します。
- 前のステップの WAR ファイルと初期 Tomcat イメージを使用して S2I をもう一度起動し、ランタイムイメージを作成します。
ビルドロジックをイメージ内に配置し、イメージを複数のステップに統合することで、ビルドツールを実稼働環境にデプロイする必要なく、ランタイム環境をビルド環境に近づけることができます。
17.3.1.2. S2I の利点
- 再現性
- ビルド環境をコンテナーイメージ内にカプセル化し、注入されたソースコードのシンプルなインターフェイスを呼び出し元に対して定義することで、ビルド環境を厳密にバージョン管理できます。ビルドの再現性は、コンテナー化されたインフラストラクチャーでセキュリティー更新と継続的インテグレーションを実現するうえで重要な要件です。ビルダーイメージは、再現性と実行時のスワップ機能を確保するのに役立ちます。
- 柔軟性
- Linux 上で実行できる既存のビルドシステムは、すべてコンテナー内で実行できます。個々のビルダーは、より大きなパイプラインの一部とすることもできます。アプリケーションのソースコードを処理するスクリプトをビルダーイメージに注入できるため、作成者は既存のイメージを調整してソース処理を可能にすることができます。
- 速度
- S2I では、単一の Dockerfile に複数のレイヤーを構築するのではなく、アプリケーションを単一のイメージレイヤーで表現することを作成者に推奨しています。これにより、作成とデプロイの時間が削減され、最終的なイメージの出力をより適切に制御できるようになります。
- セキュリティー
- Dockerfile は、コンテナーの多くの一般的な動作制御機能を使用せずに実行されます。通常、Dockerfile は root として実行され、コンテナーネットワークにアクセスできます。S2I では、ビルドが単一のコンテナーで起動されるため、ビルダーイメージに与える権限と特権を制御できます。管理者は、S2I を使用すると、OpenShift などのプラットフォームと連携させて、ビルド時に開発者に付与する特権を制御できます。
17.3.2. ルート
OpenShift のルートは、外部クライアントが名前でサービスにアクセスできるように、ホスト名でサービスを公開します。OpenShift 上に Route オブジェクトを作成すると、そのオブジェクトが組み込みの HAProxy ロードバランサーによって取得され、要求されたサービスが特定の設定を使用して公開され、外部から利用できるようになります。
Kubernetes の Ingress オブジェクトと同様に、Red Hat はニーズを満たすためにルートの概念を開発し、その背後にある設計原則をコミュニティーに提供することで、Ingress の設計に大きな影響を与えました。ルートには、次の表に示すように、いくつかの追加機能があります。
| 機能 | OpenShift 上の Ingress | OpenShift 上のルート |
|---|---|---|
| 標準 Kubernetes オブジェクト | X | |
| サービスへの外部アクセス | X | X |
| 永続的な (スティッキー) セッション | X | X |
| 負荷分散ストラテジー (例: ラウンドロビン) | X | X |
| レート制限とスロットリング | X | X |
| IP のホワイトリスト登録 | X | X |
| セキュリティー強化のための TLS エッジ終端 | X | X |
| セキュリティー強化のための TLS 再暗号化 | X | |
| セキュリティー強化のための TLS パススルー | X | |
| 重み付けされた複数のバックエンド (トラフィックの分割) | X | |
| 生成されたパターンベースのホスト名 | X | |
| ワイルドカードドメイン | X |
ホスト名の DNS 解決は、ルーティングとは別に処理されます。管理者は、常に正しくルーターに解決されるクラウドドメインを設定することも、無関係なホスト名の DNS レコードを個別に変更してルーターに解決することもあります。
個々のルートは、アノテーションで特定の設定を指定することにより、一部のデフォルトをオーバーライドできます。
関連情報
17.3.3. イメージストリーム
イメージストリームには、タグとイメージのマッピング、ストリーム内でイメージがタグ付けされたときに適用されるメタデータのオーバーライド、およびレジストリー上の Docker イメージリポジトリーへの参照 (オプション) が格納されます。
17.3.3.1. イメージストリームの利点
イメージストリームを使用すると、コンテナーイメージのタグの変更が容易になります。使用しない場合、タグを手動で変更するには、イメージをダウンロードし、ローカルで変更してから、すべてをプッシュして戻す必要があります。タグを手動で変更してから、デプロイメントオブジェクトを更新してアプリケーションをプロモートするには、多くの手順が必要です。
イメージストリームを使用すると、コンテナーイメージを 1 回アップロードし、その仮想タグを OpenShift 内で内部的に管理できます。あるプロジェクトでは開発者用のタグを使用し、そのタグへの参照を内部だけで変更する一方で、実稼働環境では実稼働用のタグを使用し、そのタグを同様に内部で管理できます。レジストリーを扱う必要はありません。
また、イメージストリームをデプロイメント設定と組み合わせて使用して、新しいイメージの発生時やタグの参照の変更時にすぐにデプロイを開始するトリガーを設定することもできます。
17.3.4. ビルド
ビルドとは、入力パラメーターを結果として作成されるオブジェクトに変換するプロセスです。ほとんどの場合、このプロセスは入力パラメーターまたはソースコードを実行可能なイメージに変換するために使用されます。BuildConfig オブジェクトはビルドプロセス全体の定義です。
OpenShift Container Platform は、Docker 形式のコンテナーをビルドイメージから作成し、それらをコンテナーイメージレジストリーにプッシュして Kubernetes を利用します。
ビルドオブジェクトには共通の特性があります。
- ビルドの入力
- ビルドプロセスを完了するための要件
- ビルドプロセスのロギング
- 成功したビルドからのリソースの公開
- ビルドの最終ステータスの公開
ビルドはリソースの制限を利用し、CPU 使用、メモリー使用およびビルドまたは Pod の実行時間などのリソースの制限を指定します。
関連情報
