Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

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

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

非推奨: アプリケーション サブスクリプション と、アプリケーションサブスクリプションを使用するすべてのプロセス。更新された機能は、GitOps の概要 を参照してください。

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

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

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

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

非推奨: アプリケーション サブスクリプション と、アプリケーションサブスクリプションを使用するすべてのプロセスが非推奨になりました。更新された機能は、GitOps の概要 を参照してください。

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

  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 を削除することはできません。

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

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

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

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

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

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

Legal Notice

Theme

© 2026 Red Hatトップに戻る