1.4. アプリケーションリソースの管理
コンソールから、Git リポジトリー、Helm リポジトリー、およびオブジェクトストレージリポジトリーを使用してアプリケーションを作成できます。
重要: Git チャネルは、他のすべてのチャネルタイプ (Helm、オブジェクトストレージ、およびその他の Git namespace) と namespace を共有できます。
アプリケーションの管理を開始する場合は、以下のトピックを参照してください。
1.4.1. Git リポジトリーを使用したアプリケーションの管理
アプリケーションを使用して Kubernetes リソースをデプロイする場合に、リソースは特定のリポジトリーに配置されます。以下の手順で、Git リポジトリーからリソースをデプロイする方法を説明します。アプリケーションモデルおよび定義 でアプリケーションモデルについて確認してください。
ユーザーに必要なアクセス権: アプリケーションを作成できるユーザーロールロールが割り当てられているアクションのみを実行できます。ロールベースのアクセス制御 のドキュメントで、アクセス要件について確認してください。
- コンソールのナビゲーションメニューから Applications をクリックし、一覧表示されているアプリケーションを表示して新規アプリケーションを作成します。
- オプション: 作成するアプリケーションの種類を選択した後に、YAML: On を選んで YAML: アプリケーションの作成および編集時に YAML をコンソールで表示できます。このトピックの後半にある YAML サンプルを参照してください。
使用可能なリポジトリーの一覧から Git を選択し、正しいフィールドに値を入力します。コンソールのガイダンスに従い、入力に基づいて YAML エディターの変更値を確認します。
注記:
- 既存の Git リポジトリーパスを選択し、そのリポジトリーがプライベートの場合は、接続情報を指定する必要がありません。接続情報が事前設定されているため、これらの値を確認する必要はありません。
- 新しい Git リポジトリーパスを入力し、その Git リポジトリーがプライベートの場合は、オプションで Git 接続情報を入力できます。
-
調整オプションに着目します。
merge
オプションは、新規フィールドが追加され、既存フィールドがリソースで更新されることを意味するデフォルトの選択です。replace
を選択することができます。replace
オプションを指定すると、既存のリソースが Git ソースに置き換えられます。サブスクリプションの調整速度をlow
に設定すると、サブスクライブしているアプリケーションリソースの調整に最大 1 時間かかる場合があります。単一アプリケーションビューのカードで、 Sync をクリックして手動で調整します。off
に設定すると、調整はありません。
-
デプロイメントの前後のタスクをオプションで設定します。サブスクリプションがアプリケーションリソースをデプロイする前後に実行する Ansible Tower ジョブがある場合は、Ansible Tower シークレットを設定します。Ansible ジョブを定義する Ansible Tower タスクは、このリポジトリーの
prehook
およびposthook
フォルダー内に配置する必要があります。 - コンソールを使用して認証情報を追加する必要がある場合は、Add credential をクリックします。コンソールの指示に従います。詳細は、認証情報の管理の概要 を参照してください。
- Create をクリックします。
- Overview ページにリダイレクトされ、詳細とトポロジーを確認できます。
1.4.1.1. GitOps パターン
Git リポジトリーを編成してクラスターを管理するベストプラクティスについて説明します。
1.4.1.1.1. GitOps のサンプルディレクトリー
この例のフォルダーは定義されて名前が付けられ、各フォルダーには、マネージドクラスターで実行されるアプリケーションまたは設定が含まれます。
-
root フォルダー
managed-subscriptions
:common-managed
フォルダーをターゲットとするサブスクリプションが含まれます。 -
サブフォルダー
apps/
:managed-clusters
に対する配置でcommon-managed
フォルダーでアプリケーションをサブスクライブするために使用されます。 -
サブフォルダー
config/
:managed-clusters
に対する配置でcommon-managed
フォルダーで設定をサブスクライブするために使用されます。 -
サブフォルダー
policies/
:managed-clusters
に対する配置でポリシーを適用するために使用します。 -
フォルダー
root-subscription/
:managed-subscriptions
フォルダーをサブスクライブするハブクラスターの最初のサブスクリプション。
ディレクトリーの例を参照してください。
common-managed/ apps/ app-name-0/ app-name-1/ config/ config001/ config002/ managed-subscriptions apps/ config/ policies/ root-subscription/
1.4.1.1.2. GitOps フロー
ディレクトリー構造は、root-subscription
> managed-subscriptions
> common-managed
のサブスクリプションフロー用に作成されます。
-
root-subscription/
の単一サブスクリプションは、CLI ターミナルからハブクラスターに適用されます。 サブスクリプションとポリシーは、
managed-subscription
フォルダーからハブクラスターにダウンロードされ、適用されます。-
managed-subscription
フォルダーのサブスクリプションおよびポリシーは、配置に基づいてマネージドクラスターで機能します。 -
配置は、各サブスクリプションまたはポリシーが影響を及ぼす
managed-clusters
を決定します。 - サブスクリプションまたはポリシーは、配置に一致するクラスター上のものを定義します。
-
-
サブスクリプションは、
common-managed
フォルダーのコンテンツを、配置ルールに一致するmanaged-clusters
に適用します。また、配置ルールに一致するすべてのmanaged-clusters
に対して、一般的なアプリケーションおよび設定も適用されます。
1.4.1.1.3. その他の例
-
root-subscription/
の例については、application-subscribe-all を参照してください。 - 同じリポジトリー内の他のフォルダーを参照するサブスクリプションの例は、subscribe-all を参照してください。
-
nginx-apps リポジトリーのアプリケーションアーティファクトを含む
common-managed
フォルダーの例を参照してください。 - Policy collection のポリシーの例を参照してください。
1.4.1.2. Git でサブスクリプションを削除した後、デプロイされたリソースを保持する
Git リポジトリーを使用してサブスクリプションを作成する場合、do-not-delete
アノテーションを追加して、サブスクリプションを削除した後も特定のデプロイ済みリソースを保持できます。do-not-delete
アノテーションは、最上位のデプロイリソースでのみ機能します。do-not-delete
アノテーションを追加するには、次の手順を実行します。
- 少なくとも 1 つのリソースをデプロイするサブスクリプションを作成します。
サブスクリプションを削除した後でも、保持するリソースに次のアノテーションを追加します。
apps.open-cluster-management.io/do-not-delete: 'true'
以下の例を参照してください。
apiVersion: v1 kind: PersistentVolumeClaim metadata: annotations: apps.open-cluster-management.io/do-not-delete: 'true' apps.open-cluster-management.io/hosting-subscription: sub-ns/subscription-example apps.open-cluster-management.io/reconcile-option: merge pv.kubernetes.io/bind-completed: "yes"
サブスクリプションを削除した後、do-not-delete
アノテーションを持つリソースは引き続き存在しますが、他のリソースは削除されます。
1.4.2. Helm リポジトリーを使用したアプリケーションの管理
アプリケーションを使用して Kubernetes リソースをデプロイする場合に、リソースは特定のリポジトリーに配置されます。以下の手順で、Helm リポジトリーからリソースをデプロイする方法を説明します。アプリケーションモデルおよび定義 でアプリケーションモデルについて確認してください。
ユーザーに必要なアクセス権: アプリケーションを作成できるユーザーロールロールが割り当てられているアクションのみを実行できます。ロールベースのアクセス制御 のドキュメントで、アクセス要件について確認してください。
- コンソールのナビゲーションメニューから Applications をクリックし、一覧表示されているアプリケーションを表示して新規アプリケーションを作成します。
- オプション: 作成するアプリケーションの種類を選択した後に、YAML: On を選んで YAML: アプリケーションの作成および編集時に YAML をコンソールで表示できます。このトピックの後半にある YAML サンプルを参照してください。
- 使用できるリポジトリーの一覧から Helm を選択し、正しいフィールドに値を入力します。コンソールのガイダンスに従い、入力に基づいて YAML エディターの変更値を確認します。
- Create をクリックします。
- Overview ページにリダイレクトされ、詳細とトポロジーを確認できます。
1.4.2.1. YAML 例
以下のチャネル定義例では Helm リポジトリーをチャネルとして抽象化します。
注記: Helm では、Helm チャートに含まれる全 Kubernetes リソースにはラベルリリースが必要です。アプリケーショントポロジーの {{ .Release.Name }}`
が正しく表示されるようにします。
apiVersion: v1 kind: Namespace metadata: name: hub-repo --- apiVersion: apps.open-cluster-management.io/v1 kind: Channel metadata: name: helm namespace: hub-repo spec: pathname: [https://kubernetes-charts.storage.googleapis.com/] # URL points to a valid chart URL. type: HelmRepo
以下のチャネル定義は、Helm リポジトリーチャネルの別の例を示しています。
apiVersion: apps.open-cluster-management.io/v1 kind: Channel metadata: name: predev-ch namespace: ns-ch labels: app: nginx-app-details spec: type: HelmRepo pathname: https://kubernetes-charts.storage.googleapis.com/
注記: REST API を確認するには、API を使用してください。
1.4.2.2. Helm でサブスクリプションを削除した後、デプロイされたリソースを保持する
Helm は、サブスクリプションを削除した後、特定のデプロイされたリソースを保持するためのアノテーションを提供します。詳細については、Tell Helm Not To Uninstall a Resource を参照してください。
注記: アノテーションは Helm チャートにある必要があります。
1.4.3. Object Storage リポジトリーを使用したアプリケーションの管理
アプリケーションを使用して Kubernetes リソースをデプロイする場合に、リソースは特定のリポジトリーに配置されます。アプリケーションモデルおよび定義 でアプリケーションモデルについて確認してください。
ユーザーに必要なアクセス権: アプリケーションを作成できるユーザーロールロールが割り当てられているアクションのみを実行できます。ロールベースのアクセス制御 のドキュメントで、アクセス要件について確認してください。
- コンソールのナビゲーションメニューから Applications をクリックし、一覧表示されているアプリケーションを表示して新規アプリケーションを作成します。
- オプション: 作成するアプリケーションの種類を選択した後に、YAML: On を選んで YAML: アプリケーションの作成および編集時に YAML をコンソールで表示できます。このトピックの後半にある YAML サンプルを参照してください。
- 使用できるリポジトリーの一覧から オブジェクトストア を選択し、正しいフィールドに値を入力します。コンソールのガイダンスに従い、入力に基づいて YAML エディターの変更値を確認します。
- Create をクリックします。
- Overview ページにリダイレクトされ、詳細とトポロジーを確認できます。
1.4.3.1. YAML 例
以下のチャネル定義例では、オブジェクトストレージをチャネルとして抽象化します。
apiVersion: apps.open-cluster-management.io/v1 kind: Channel metadata: name: dev namespace: ch-obj spec: type: Object storage pathname: [http://sample-ip:#####/dev] # URL is appended with the valid bucket name, which matches the channel name. secretRef: name: miniosecret gates: annotations: dev-ready: true
注記: REST API を確認するには、API を使用します。
1.4.3.2. Amazon Web Services (AWS) S3 オブジェクトストレージバケットの作成
サブスクリプションを設定して、Amazon Simple Storage Service (Amazon S3) オブジェクトストレージサービスで定義したリソースをサブスクライブできます。以下の手順を参照してください。
- AWS アカウント、ユーザー名、およびパスワードを使用して AWS コンソール にログインします。
- Amazon S3 > Buckets に移動し、バケットホームページに移動します。
- Create Bucket をクリックし、バケットを作成します。
- AWS リージョン を選択します。AWS S3 オブジェクトバケットの接続に不可欠です。
- バケットアクセストークンを作成します。
- ナビゲーションバーのユーザー名に移動して、ドロップダウンメニューから My Security Credentials を選択します。
- AWS IAM credentials タブで Access keys for CLI, SDK, & API access に移動し、Create access key をクリックします。
- Access key ID と Secret access key を保存します。
- オブジェクト YAML ファイルをバケットにアップロードします。
1.4.3.3. AWS バケットのオブジェクトへのサブスクライブ
- シークレットでオブジェクトバケットタイプチャネルを作成し、AccessKeyID、SecretAccessKey、および リージョン を指定して、AWS バケットに接続します。AWS バケットの作成時に、この 3 つのフィールドが作成されます。
URL を追加します。URL に
s3://
またはs3 and aws
のキーワードが含まれる場合は、その URL で AWS S3 バケットのチャネルを特定します。たとえば、以下のバケット URL にはすべて AWS s3 バケット識別子が含まれます。https://s3.console.aws.amazon.com/s3/buckets/sample-bucket-1 s3://sample-bucket-1/ https://sample-bucket-1.s3.amazonaws.com/
注記: バケットを AWS S3 API に接続する場合に、AWS S3 オブジェクトバケット URL は必要ありません。
1.4.3.4. AWS サブスクリプションの例
以下の完全な AWS S3 オブジェクトバケットチャネルのサンプル YAML ファイルを参照してください。
apiVersion: apps.open-cluster-management.io/v1 kind: Channel metadata: name: object-dev namespace: ch-object-dev spec: type: ObjectBucket pathname: https://s3.console.aws.amazon.com/s3/buckets/sample-bucket-1 secretRef: name: secret-dev --- apiVersion: v1 kind: Secret metadata: name: secret-dev namespace: ch-object-dev stringData: AccessKeyID: <your AWS bucket access key id> SecretAccessKey: <your AWS bucket secret access key> Region: <your AWS bucket region> type: Opaque
以下の YAML の例で kind: PlacementRule
および kind: Subscription added
と表示されているため、引き続き他の AWS サブスクリプションおよび配置ルールオブジェクトを作成できます。
apiVersion: apps.open-cluster-management.io/v1 kind: PlacementRule metadata: name: towhichcluster namespace: obj-sub-ns spec: clusterSelector: {} --- apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: obj-sub namespace: obj-sub-ns spec: channel: ch-object-dev/object-dev placement: placementRef: kind: PlacementRule name: towhichcluster
オブジェクトバケットの特定サブフォルダー内にあるオブジェクトをサブスクライブすることもできます。subfolder
アノテーションをサブスクリプションに追加することで、オブジェクトバケットサブスクリプションがサブフォルダーパス内の全リソースのみを強制的に適用します。
subfolder-1
のアノテーションを bucket-path
として参照してください。
annotations: apps.open-cluster-management.io/bucket-path: <subfolder-1>
サブフォルダーの完全なサンプルは、以下を参照してください。
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: annotations: apps.open-cluster-management.io/bucket-path: subfolder1 name: obj-sub namespace: obj-sub-ns labels: name: obj-sub spec: channel: ch-object-dev/object-dev placement: placementRef: kind: PlacementRule name: towhichcluster
1.4.3.5. オブジェクトストレージでサブスクリプションを削除した後、デプロイされたリソースを保持する
オブジェクトストレージリポジトリーを使用してサブスクリプションを作成する場合、do-not-delete
アノテーションを追加して、サブスクリプションを削除した後も特定のデプロイ済みリソースを保持できます。do-not-delete
アノテーションは、最上位のデプロイリソースでのみ機能します。do-not-delete
アノテーションを追加するには、次の手順を実行します。
- 少なくとも 1 つのリソースをデプロイするサブスクリプションを作成します。
サブスクリプションを削除した後でも、保持するリソースに次のアノテーションを追加します。
apps.open-cluster-management.io/do-not-delete: 'true'
以下の例を参照してください。
apiVersion: v1 kind: PersistentVolumeClaim metadata: annotations: apps.open-cluster-management.io/do-not-delete: 'true' apps.open-cluster-management.io/hosting-subscription: sub-ns/subscription-example apps.open-cluster-management.io/reconcile-option: merge pv.kubernetes.io/bind-completed: "yes"
サブスクリプションを削除した後、do-not-delete
アノテーションを持つリソースは引き続き存在しますが、他のリソースは削除されます。