1.4. アプリケーションリソースの管理


コンソールから、Git リポジトリー、Helm リポジトリー、およびオブジェクトストレージリポジトリーを使用してアプリケーションを作成できます。

重要: Git チャネルは、他のすべてのチャネルタイプ (Helm、オブジェクトストレージ、およびその他の Git namespace) と namespace を共有できます。

アプリケーションの管理を開始する場合は、以下のトピックを参照してください。

1.4.1. Git リポジトリーを使用したアプリケーションの管理

アプリケーションを使用して Kubernetes リソースをデプロイする場合に、リソースは特定のリポジトリーに配置されます。以下の手順で、Git リポジトリーからリソースをデプロイする方法を説明します。アプリケーションモデルおよび定義 でアプリケーションモデルについて確認してください。

ユーザーに必要なアクセス権: アプリケーションを作成できるユーザーロールロールが割り当てられているアクションのみを実行できます。ロールベースのアクセス制御 のドキュメントで、アクセス要件について確認してください。

  1. コンソールのナビゲーションメニューから Applications をクリックし、一覧表示されているアプリケーションを表示して新規アプリケーションを作成します。
  2. オプション: 作成するアプリケーションの種類を選択した後に、YAML: On を選んで YAML: アプリケーションの作成および編集時に YAML をコンソールで表示できます。このトピックの後半にある YAML サンプルを参照してください。
  3. 使用可能なリポジトリーの一覧から Git を選択し、正しいフィールドに値を入力します。コンソールのガイダンスに従い、入力に基づいて YAML エディターの変更値を確認します。

    注記:

    • 既存の Git リポジトリーパスを選択し、そのリポジトリーがプライベートの場合は、接続情報を指定する必要がありません。接続情報が事前設定されているため、これらの値を確認する必要はありません。
    • 新しい Git リポジトリーパスを入力し、その Git リポジトリーがプライベートの場合は、オプションで Git 接続情報を入力できます。
    • 調整オプションに着目します。merge オプションは、新規フィールドが追加され、既存フィールドがリソースで更新されることを意味するデフォルトの選択です。replace を選択することができます。replace オプションを指定すると、既存のリソースが Git ソースに置き換えられます。サブスクリプションの調整速度を low に設定すると、サブスクライブしているアプリケーションリソースの調整に最大 1 時間かかる場合があります。単一アプリケーションビューのカードで、 Sync をクリックして手動で調整します。off に設定すると、調整はありません。
  4. デプロイメントの前後のタスクをオプションで設定します。サブスクリプションがアプリケーションリソースをデプロイする前後に実行する Ansible Tower ジョブがある場合は、Ansible Tower シークレットを設定します。Ansible ジョブを定義する Ansible Tower タスクは、このリポジトリーの prehook および posthook フォルダー内に配置する必要があります。
  5. コンソールを使用して認証情報を追加する必要がある場合は、Add credential をクリックします。コンソールの指示に従います。詳細は、認証情報の管理の概要 を参照してください。
  6. Create をクリックします。
  7. 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 のサブスクリプションフロー用に作成されます。

  1. root-subscription/ の単一サブスクリプションは、CLI ターミナルからハブクラスターに適用されます。
  2. サブスクリプションとポリシーは、managed-subscription フォルダーからハブクラスターにダウンロードされ、適用されます。

    • managed-subscription フォルダーのサブスクリプションおよびポリシーは、配置に基づいてマネージドクラスターで機能します。
    • 配置は、各サブスクリプションまたはポリシーが影響を及ぼす managed-clusters を決定します。
    • サブスクリプションまたはポリシーは、配置に一致するクラスター上のものを定義します。
  3. サブスクリプションは、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. 少なくとも 1 つのリソースをデプロイするサブスクリプションを作成します。
  2. サブスクリプションを削除した後でも、保持するリソースに次のアノテーションを追加します。

    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 リポジトリーからリソースをデプロイする方法を説明します。アプリケーションモデルおよび定義 でアプリケーションモデルについて確認してください。

ユーザーに必要なアクセス権: アプリケーションを作成できるユーザーロールロールが割り当てられているアクションのみを実行できます。ロールベースのアクセス制御 のドキュメントで、アクセス要件について確認してください。

  1. コンソールのナビゲーションメニューから Applications をクリックし、一覧表示されているアプリケーションを表示して新規アプリケーションを作成します。
  2. オプション: 作成するアプリケーションの種類を選択した後に、YAML: On を選んで YAML: アプリケーションの作成および編集時に YAML をコンソールで表示できます。このトピックの後半にある YAML サンプルを参照してください。
  3. 使用できるリポジトリーの一覧から Helm を選択し、正しいフィールドに値を入力します。コンソールのガイダンスに従い、入力に基づいて YAML エディターの変更値を確認します。
  4. Create をクリックします。
  5. 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 リソースをデプロイする場合に、リソースは特定のリポジトリーに配置されます。アプリケーションモデルおよび定義 でアプリケーションモデルについて確認してください。

ユーザーに必要なアクセス権: アプリケーションを作成できるユーザーロールロールが割り当てられているアクションのみを実行できます。ロールベースのアクセス制御 のドキュメントで、アクセス要件について確認してください。

  1. コンソールのナビゲーションメニューから Applications をクリックし、一覧表示されているアプリケーションを表示して新規アプリケーションを作成します。
  2. オプション: 作成するアプリケーションの種類を選択した後に、YAML: On を選んで YAML: アプリケーションの作成および編集時に YAML をコンソールで表示できます。このトピックの後半にある YAML サンプルを参照してください。
  3. 使用できるリポジトリーの一覧から オブジェクトストア を選択し、正しいフィールドに値を入力します。コンソールのガイダンスに従い、入力に基づいて YAML エディターの変更値を確認します。
  4. Create をクリックします。
  5. 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) オブジェクトストレージサービスで定義したリソースをサブスクライブできます。以下の手順を参照してください。

  1. AWS アカウント、ユーザー名、およびパスワードを使用して AWS コンソール にログインします。
  2. Amazon S3 > Buckets に移動し、バケットホームページに移動します。
  3. Create Bucket をクリックし、バケットを作成します。
  4. AWS リージョン を選択します。AWS S3 オブジェクトバケットの接続に不可欠です。
  5. バケットアクセストークンを作成します。
  6. ナビゲーションバーのユーザー名に移動して、ドロップダウンメニューから My Security Credentials を選択します。
  7. AWS IAM credentials タブで Access keys for CLI, SDK, & API access に移動し、Create access key をクリックします。
  8. Access key IDSecret access key を保存します。
  9. オブジェクト YAML ファイルをバケットにアップロードします。

1.4.3.3. AWS バケットのオブジェクトへのサブスクライブ

  1. シークレットでオブジェクトバケットタイプチャネルを作成し、AccessKeyIDSecretAccessKey、および リージョン を指定して、AWS バケットに接続します。AWS バケットの作成時に、この 3 つのフィールドが作成されます。
  2. 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. 少なくとも 1 つのリソースをデプロイするサブスクリプションを作成します。
  2. サブスクリプションを削除した後でも、保持するリソースに次のアノテーションを追加します。

    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 アノテーションを持つリソースは引き続き存在しますが、他のリソースは削除されます。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.