36- 第9章：OpenShift上でのコンテナ化アプリケーションのデプロイ-3：（S2I）でアプリケーション作成の説明

type

status

date

slug

summary

category

icon

password

书籍

アプリケーションの作成：Source-to-Image（S2I）

目的

このセクションを終えた後、学生はOpenShift Container PlatformのSource-to-Image（S2I）機能を使用してアプリケーションをデプロイできるようになります。

Source-to-Image（S2I）プロセス

Source-to-Image（S2I）は、アプリケーションのソースコードからコンテナイメージを作成するための便利な機能です。この機能は、アプリケーションのソースコードをGitサーバーから取得し、そのソースコードを希望する言語とフレームワークに基づいたベースコンテナに注入し、新しいコンテナイメージを作成してアセンブルされたアプリケーションを実行します。

以下の図は、oc new-appコマンドでアプリケーションソースコードリポジトリを引数として使用した場合に作成されるリソースを示しています。デプロイメント設定（Deployment Configuration）とその依存リソースが作成されることがわかります。

図 9.2：デプロイメント設定と依存リソース

S2IはOpenShift Container Platformでアプリケーションをビルドする主要な戦略です。ソースビルドを使用する主な理由は次の通りです：

ユーザーの効率性：開発者はDockerfileやyum installなどのOSコマンドを理解する必要がありません。標準的なプログラミング言語ツールを使って作業できます。

パッチ適用：S2Iでは、ベースイメージにセキュリティ問題が見つかった場合、そのイメージをセキュリティパッチで更新することで、そのイメージをベースに使用するすべてのアプリケーションを一貫して再ビルドできます。例えば、PHPベースイメージにセキュリティ問題が見つかった場合、そのイメージを更新すると、そのイメージを使用しているすべてのアプリケーションが更新されます。

速度：S2Iでは、ビルドプロセスが複雑な操作を多く行っても、新しいレイヤーを作成せずに実行されるため、ビルドが速くなります。

エコシステム：S2Iは、ベースイメージやスクリプトをカスタマイズして再利用できる、アプリケーションタイプを超えた共有エコシステムを促進します。

イメージストリーム

OpenShiftは、ユーザーアプリケーションの新しいバージョンを迅速にポッドにデプロイします。新しいアプリケーションを作成するには、アプリケーションのソースコードに加えて、ベースイメージ（S2Iビルダーイメージ）が必要です。これらの2つのコンポーネントのいずれかが更新されると、新しいコンテナイメージが作成され、古いコンテナイメージを使用して作成されたポッドは新しいイメージを使用するポッドに置き換えられます。

アプリケーションコードが変更されたときにコンテナイメージを更新する必要があることは明白ですが、ビルダーイメージが変更された場合にもデプロイされたポッドを更新する必要があることは、必ずしも直感的ではありません。

イメージストリームリソースは、イメージストリームタグに関連付けられた特定のコンテナイメージを名前付けする構成です。イメージストリームタグはこれらのコンテナイメージのエイリアスです。アプリケーションはイメージストリームに対してビルドされます。OpenShiftインストーラーは、インストール時にいくつかのイメージストリームをデフォルトでポピュレートします。利用可能なイメージストリームを確認するには、oc getコマンドを使用します：

注

OpenShiftのインスタンスには、ローカルの追加やOpenShiftのリリースポイントに応じて、これらのイメージストリームがさらに多いまたは少ない場合があります。

OpenShiftは、イメージストリームが変更されたことを検出し、その変更に基づいてアクションを実行する機能を持っています。たとえば、nodejs-010-rhel7イメージにセキュリティ問題が見つかった場合、イメージリポジトリでそれを更新し、OpenShiftは自動的にアプリケーションコードの新しいビルドをトリガーできます。

組織は、Red HatがサポートするいくつかのベースS2Iイメージを選択する可能性が高いですが、独自のベースイメージを作成することもできます。

*イメージストリーム（ImageStream）**は、OpenShiftでコンテナイメージのバージョン管理を行うためのリソースです。以下のポイントで簡潔にまとめます：

基本機能：イメージストリームは、特定のコンテナイメージ（例えばnodejs:8）を管理し、そのバージョンを追跡します。

役割：アプリケーションが使用するコンテナイメージの基盤となる「基本イメージ」を定義します。

更新：イメージストリームを更新することで、アプリケーションのコンテナイメージが新しいバージョンの基本イメージを使うようになります。

要するに、イメージストリームはコンテナの基本イメージの管理を簡素化し、新しいバージョンが出ると自動的にアプリケーションの更新をサポートします。

S2IとCLIを使ってアプリケーションを構築する

S2Iを使ってアプリケーションを構築するには、OpenShift CLIを使用できます。CLIからoc new-appコマンドを使って、S2Iプロセスを使ってアプリケーションを作成できます。

例：

コマンドの詳細：

チルダ（~）の左側に表示されるのは使用するイメージストリームです。

チルダの後にあるURLはソースコードのGitリポジトリの場所を示します。

-nameオプションでアプリケーションの名前を設定します。

oc new-appコマンドは、ローカルまたはリモートのGitリポジトリからソースコードを使用してアプリケーションを作成することができます。ソースリポジトリだけが指定されている場合、oc new-appはアプリケーションを構築するために使用する適切なイメージストリームを識別しようとします。アプリケーションコードに加えて、S2IはDockerfileを識別して新しいイメージを作成することもできます。

以下の例は、現在のディレクトリにあるGitリポジトリを使用してアプリケーションを作成します：

注意

ローカルのGitリポジトリを使用する場合、そのリポジトリにはOpenShiftインスタンスがアクセス可能なURLを指すリモートオリジンが設定されている必要があります。

リモートGitリポジトリとサブディレクトリを指定してアプリケーションを作成することも可能です：

特定のブランチを参照するリモートGitリポジトリを使ってアプリケーションを作成することもできます：

もしコマンドにイメージストリームが指定されていない場合、new-appはリポジトリのルートにある特定のファイルを基に使用する言語ビルダーを特定しようとします。

言語ファイル例：

ruby: Rakefile, Gemfile, config.ru

Java EE: pom.xml

nodejs: app.json, package.json

php: index.php, composer.json

python: requirements.txt, config.py

perl: index.pl, cpanfile

言語が検出されると、new-appはその言語に対応したイメージストリームタグを検索するか、検出された言語の名前と一致するイメージストリームを検索します。

JSONリソース定義ファイルは、-o jsonパラメータと出力リダイレクションを使って作成できます：

このJSON定義ファイルによって、いくつかのリソースが作成されます。最初のリソースは「イメージストリーム」です：

この部分は「イメージストリーム」というリソースタイプを定義しています。

イメージストリームの名前を「myapp」に設定しています。

次に「ビルド構成（BuildConfig）」が登場します。ビルド構成は、ソースコードを実行可能なイメージに変換するために必要な入力パラメーターとトリガーを定義します。ビルド構成（BC）は2番目のリソースであり、以下はOpenShiftが実行可能なイメージを作成するために使用するパラメーターの概要です：

この部分では、「ビルド構成」というリソースタイプを定義しています。

ビルド構成の名前を「myapp」に設定しています。

ソースコードのGitリポジトリのアドレスを定義しています。

S2I（Source-to-Image）戦略を使用することを定義しています。

ビルダーイメージとして php:5.5 イメージストリームを指定しています。

出力イメージストリームの名前を myapp:latest に設定しています。

要するに、このJSON定義ファイルは、アプリケーションのソースコードをGitリポジトリから取得し、指定したビルダーイメージを使ってビルドを行い、その結果として myapp:latest という名前のイメージを生成するためのリソースを定義しています。

このJSON定義ファイルには、3番目のリソースとして「デプロイメント設定（DeploymentConfig）」が含まれています。デプロイメント設定は、OpenShiftでのデプロイメントプロセスをカスタマイズする役割を持ちます。これには、新しいコンテナインスタンスを作成するために必要なパラメータやトリガーが含まれ、Kubernetesのレプリケーションコントローラに変換されます。デプロイメント設定が提供する機能の一部は以下の通りです：

既存のデプロイメントから新しいデプロイメントへの移行戦略をユーザーがカスタマイズ可能。

前のデプロイメントへのロールバック。

手動によるレプリケーションスケーリング。

以下はその一部の例です：

この部分は「デプロイメント設定（DeploymentConfig）」リソースタイプを定義しています。

デプロイメント設定の名前を「myapp」に設定。

「ConfigChange」トリガーは、レプリケーションコントローラのテンプレートが変更されるたびに新しいデプロイメントを作成します。

「ImageChange」トリガーは、「myapp:latest」イメージがレポジトリに新しいバージョンとして利用可能になるたびに新しいデプロイメントを作成します。

myapp:latest コンテナイメージがデプロイされるべきであることを定義。

コンテナポートも指定されています。

最後のリソースはサービスです。サービスに関しては、前の章で説明しています。

注意デフォルトでは、oc new-app コマンドでルートは作成されません。アプリケーション作成後にルートを作成できますが、Webコンソールを使用すると、テンプレートを使うため自動的にルートが作成されます。

アプリケーションを作成した後、ビルドプロセスが開始されます。ビルドのリストを表示するには次のコマンドを使用します：

ビルドログを表示するためのコマンドは次の通りです：

注意ビルドがまだ実行中でない場合、またはs2iビルドポッドがまだ展開されていない場合、上記のコマンドはエラーを返すことがあります。その場合は、少し待ってから再試行してください。

新しいビルドをトリガーするには、次のコマンドを使用します：

BuildConfigとDeploymentConfigの関係

BuildConfig ポッドは、OpenShiftでイメージを作成し、内部Dockerレジストリにプッシュする役割を果たします。ソースコードやコンテンツの更新は、新しいビルドが必要となり、これによりイメージが更新されます。

DeploymentConfig ポッドは、OpenShiftでポッドをデプロイする役割を果たします。DeploymentConfigポッドが実行される結果として、内部Dockerレジストリにデプロイされたイメージからポッドが作成されます。設定により、既存のポッドは削除されることがあります。