34- 第9章：OpenShift上でのコンテナ化アプリケーションのデプロイ-1：Kubernetesリソース作成の説明

type

status

date

slug

summary

OpenShift上でのコンテナ化アプリケーションのデプロイ

目標

OpenShift Container Platformに単一コンテナアプリケーションをデプロイする。

目的

標準的なKubernetesリソースを作成する。

OpenShiftのSource-to-Image機能を使ってアプリケーションをビルドする。

サービスへのルートを作成する。

OpenShift Webコンソールを使用してアプリケーションを作成する。

セクション

Kubernetesリソースの作成（およびガイド付き演習）

Source-to-Image機能を使ったアプリケーションの作成（およびガイド付き演習）

ルートの作成（およびガイド付き演習）

OpenShift Webコンソールを使用したアプリケーションの作成（およびガイド付き演習）

ラボ

OpenShift上でのコンテナ化アプリケーションのデプロイ

Kubernetesリソースの作成

目的

このセクションを完了した後、学生は標準的なKubernetesリソースを作成できるようになります。

OpenShift Container Platform (OCP) リソース

OpenShift Container Platformは、OpenShiftクラスター内のエンティティをマスター・ノードに格納されたオブジェクトとして管理します。これらは collectively「リソース」として知られています。最も一般的なリソースは以下の通りです：

Pod

ノード内で実行される1つまたは複数のコンテナのセットで、ユニークなIPアドレスとボリューム（永続的なストレージ）を共有します。Podはまた、各コンテナのセキュリティおよびランタイムポリシーも定義します。

Label

ラベルは、システム内の任意のリソースに割り当てることができるキーと値のペアで、リソースのグループ化および選択に使用されます。多くのリソースはラベルを使って他のリソースのセットを識別します。

Persistent Volume (PV)

コンテナのデータは一時的であり、コンテナが削除されるとその内容は失われます。Persistent Volumeは、Podがデータを永続化するためにアクセスできるストレージを表し、Podコンテナ内でファイルシステムとしてマウントされます。

通常のOpenShiftユーザーはPersistent Volumeを作成できません。これらはクラスター管理者によって作成およびプロビジョニングされる必要があります。

Persistent Volume Claim (PVC)

Persistent Volume Claimは、プロジェクトからのストレージリクエストです。このリクエストはストレージの望ましい特性（例えば、サイズなど）を指定し、OpenShiftクラスターはそれを管理者が作成した利用可能なPersistent Volumeに一致させます。

リクエストが満たされると、同じプロジェクト内のPodがその名前でClaimを参照すると、そのPod内のコンテナに関連するPVがボリュームとしてマウントされます。

代わりに、PodはEmptyDirタイプのボリュームを参照することができます。これはノードマシン上の一時的なディレクトリであり、Podが停止するとその内容は失われます。

Service (SVC)

サービスは、他のPodからアクセスされるPodのセット（または外部サーバー）を表す名前です。サービスにはIPアドレスとDNS名が割り当てられ、ポートやルートを通じて外部からクラスターに公開することができます。また、サービスからPodを消費するのは簡単で、名前がSERVICE_HOSTの環境変数が自動的に他のPodに注入されます。

Route

ルートは、サービスを外部からアクセスできるようにするために作成された外部DNSエントリ（トップレベルドメインまたは動的に割り当てられた名前）です。管理者は1つ以上のルーターを設定してこれらのルートを処理します。

Replication Controller (RC)

レプリケーションコントローラーは、特定の数のPod（またはレプリカ）が実行されていることを保証します。これらのPodは、レプリケーションコントローラー定義の一部であるテンプレートから作成されます。Podが何らかの理由で失われた場合（例えば、クラスターのノード障害など）、コントローラーは失われたPodを置き換える新しいPodを作成します。

Deployment Configuration (DC)

Deployment Configuration（DC）は、レプリケーションコントローラーを管理して、コンテナイメージの変更に応じてPodのセットを更新します。通常、単一のDeployment Configurationは単一のマイクロサービスに相当します。DCは、完全な再起動、カスタマイズ可能なローリングアップデート、完全にカスタマイズされた動作など、さまざまなデプロイメントパターンをサポートし、外部の継続的インテグレーション（CI）や継続的デリバリー（CD）システムとの統合のためのフックも提供します。

Build Configuration (BC)

Build Configuration（BC）は、Gitサーバーに保存されたソースコードからコンテナイメージをビルドすることを管理します。ビルドは、Source-to-Image（S2I）プロセスまたはDockerfileを使用して行われます。Build Configurationは、外部のCIおよびCDシステムとの統合のためのフックもサポートしています。

Project

プロジェクトは、メンバーとその役割のリストを持っています。上記の用語の多くは、OpenShiftプロジェクト内（Kubernetesの用語ではネームスペース内）に存在します。プロジェクトには、ビューアー、エディター、管理者などの役割と、実行中のPodに対するセキュリティ制御、プロジェクトが使用できるリソースの制限があります。リソース名はプロジェクト内で一意です。開発者はプロジェクトの作成を要求できますが、リソースのクォータを管理するのは管理者です。

管理者が管理するリソースの種類に関係なく、OpenShiftのコマンドラインツール（oc）は、これらのリソースの更新、修正、削除、および管理を一貫した方法で行うためのツールを提供します。また、最も頻繁に使用されるリソースタイプを扱うための補助ツールも提供します。

oc typesコマンドを使用すると、OpenShiftで利用可能なすべてのリソースタイプを簡単に確認できます。

oc new-appを使ったアプリケーションの作成

シンプルなアプリケーション、複雑なマルチティアアプリケーション、マイクロサービスアプリケーションは、単一のリソース定義ファイルで記述できます。このファイルには、複数のPod定義、Podを接続するためのService定義、アプリケーションPodを水平スケーリングするためのレプリケーションコントローラーまたはDeploymentConfig、アプリケーションデータを永続化するためのPersistentVolumeClaim、およびOpenShiftで管理できるその他の必要なリソースが含まれます。

oc new-appコマンドを使用すると、-o jsonや-o yamlオプションを指定して、JSONまたはYAML形式でスケルトンのリソース定義ファイルを作成できます。このファイルはカスタマイズして、oc create -f <filename>コマンドでアプリケーションを作成するために使用することができます。また、他のリソース定義ファイルと統合して、複合的なアプリケーションを作成することもできます。

oc new-appコマンドは、さまざまな方法でOpenShift上でアプリケーションPodを作成できます。既存のDockerイメージから、Dockerfileから、またはSource-to-Image（S2I）プロセスを使用してソースコードからPodを作成できます。

oc new-app -hコマンドを実行すると、OpenShiftで新しいアプリケーションを作成するためのさまざまなオプションを簡単に理解できます。

以下のコマンドは、Docker Hubからmysqlというイメージを基に、ラベルをdb=mysqlに設定したアプリケーションを作成します：

次の図は、oc new-appコマンドがコンテナイメージを引数に取った場合に作成するKubernetesおよびOpenShiftリソースを示しています：

次のコマンドは、プライベートなDockerイメージレジストリからイメージを基にアプリケーションを作成します：

次のコマンドは、Gitリポジトリに保存されたソースコードを基にアプリケーションを作成します：

次のセクションでは、Source-to-Image（S2I）プロセスとそれに関連する概念について学び、oc new-app を使ってOpenShift向けのアプリケーションを構築するためのより高度な方法について学びます。

OpenShiftリソースを管理するための便利なコマンド

OpenShiftリソースを管理するために使用されるいくつかの重要なコマンドについて説明します。

通常、管理者としては、oc get コマンドをよく使用します。このコマンドは、クラスター内のリソースに関する情報を取得します。一般的に、このコマンドはリソースの最も重要な特性のみを出力し、詳細な情報は省略します。

RESOURCE_NAME パラメータを省略すると、指定された RESOURCE_TYPE のすべてのリソースがまとめて表示されます。以下は oc get pods コマンドを実行した際のサンプル出力です。

`oc get all`

管理者がクラスターのすべての主要なリソースのサマリーを確認したい場合、oc get all コマンドを実行できます。このコマンドは、現在のプロジェクトにおける主要なリソースタイプを順番に処理し、それらの情報をサマリー形式で出力します。例えば以下のような出力になります：

`oc describe RESOURCE_TYPE RESOURCE_NAME`

oc get で表示されるサマリー情報が不十分な場合、oc describe コマンドを使用してリソースに関する追加情報を取得できます。oc get コマンドとは異なり、リソースタイプごとに一度にリソースを列挙することはできませんが、ほとんどの主要なリソースについて詳細な情報を表示できます。この機能はすべてのリソースタイプには対応していない場合もあります。以下はポッドリソースの詳細を表示した際の例です：

oc export このコマンドは、リソース定義をエクスポートするために使用できます。典型的な使用例としては、バックアップの作成や定義の修正を支援するために使用されます。デフォルトでは、export コマンドはオブジェクト表現をYAML形式で出力しますが、-o オプションを指定することで、異なる形式で出力することも可能です。

oc create このコマンドは、リソース定義からリソースを作成するために使用されます。通常、これは oc export コマンドと組み合わせて、定義を編集するために使用されます。

oc edit このコマンドは、リソース定義のリソースを編集するために使用されます。デフォルトでは、oc edit コマンドはリソース定義を編集するためにviエディタを開きます。

oc delete RESOURCE_TYPE nameoc delete コマンドは、OpenShiftクラスターからリソースを削除するために使用されます。OpenShiftのアーキテクチャについて基本的な理解が必要で、ポッドなどの管理対象リソースを削除すると、新しいインスタンスが自動的に再作成されることになります。プロジェクトを削除すると、そのプロジェクト内のすべてのリソースとアプリケーションが削除されます。

oc exec CONTAINER_ID options commandoc exec コマンドは、コンテナ内でコマンドを実行するために使用されます。このコマンドを使って、インタラクティブなコマンドや非インタラクティブなバッチコマンドをスクリプトの一部として実行できます。

実演: 基本的なKubernetesリソースの作成

このデモンストレーションでは、インストラクターがOpenShiftでNginxコンテナイメージから基本的なKubernetesリソースを作成する方法を示します。手順を実行せずに、インストラクターに従って学んでください。

OpenShiftにデベロッパーユーザーとしてログインします:

このデモンストレーションで作成するリソースのために新しいプロジェクトを作成します:

デフォルトのクラスタセキュリティポリシーを緩和します。 Security Context Constraints。

Docker Hubからのnginxイメージはrootとして実行されますが、デフォルトのOpenShiftセキュリティポリシーではこれは許可されていません。

管理者ユーザーとして、デフォルトのセキュリティポリシーを変更してコンテナがrootとして実行できるようにします:

開発者ユーザーとして再度OpenShiftにログインし、oc new-app コマンドを使用してnginxコンテナイメージから新しいアプリケーションを作成します。-docker-image オプションを使用して、OpenShiftがインターネットからイメージを取得しないように、クラスルームのプライベートレジストリURIを指定します：

5.oc status コマンドを実行して、新しいアプリケーションの状態を確認し、Nginxイメージのデプロイが成功したかどうかを確認します：

6.このプロジェクト内のPodをリストして、NginxのPodが準備できて実行中かどうかを確認します：

7.oc describe コマンドを使って Pod の詳細を確認します：

8.このプロジェクト内のサービスをリストして、Nginx Pod にアクセスするためのサービスが作成されたかどうかを確認します：

9.Nginx サービスの詳細を取得し、Nginx Pod にアクセスするためのサービス IP を確認します：

10.マスターマシンに SSH セッションを開き、サービス IP を使用して Nginx のデフォルトホームページにアクセスします：

このシナリオでは、サービス IP とポートに直接アクセスすることが可能です。なぜなら、master はクラスルーム環境の OpenShift クラスター全体を管理するマシンだからです。

11.プロジェクトを削除して、プロジェクト内のリソースをすべて削除します：

これでデモンストレーションは終了です。