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 Automation Platform ジョブがある場合は、Ansible Automation Platform シークレットを設定します。ジョブを定義する Ansible Automation Platform タスクは、このリポジトリーの prehook および posthook フォルダー内に配置する必要があります。
  5. コンソールを使用して認証情報を追加する必要がある場合は、Add credential をクリックします。コンソールの指示に従います。詳細は、認証情報の管理の概要 を参照してください。
  6. Create をクリックします。
  7. Overview ページにリダイレクトされ、詳細とトポロジーを確認できます。

1.4.1.1. その他の例

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

注記: do-not-delete アノテーションを使用してデプロイされたままのリソースは、namespace にバインドされます。そのため、残りのリソースを削除するまで namespace を削除することはできません。

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

注記: do-not-delete アノテーションを使用してデプロイされたままのリソースは、namespace にバインドされます。そのため、残りのリソースを削除するまで namespace を削除することはできません。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.