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

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

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

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

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

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

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

  1. コンソールのナビゲーションメニューから Manage applications をクリックします。

  2. Create application を クリックします。

    以下の手順では、YAML: On を選択し、アプリケーションの作成時にコンソールで YAML を表示します。このトピックの後半にある「YAML サンプル」を参照してください。

  3. 以下の値を正しいフィールドに入力します。

    • Name: アプリケーションの有効な Kubernetes 名を入力します。
    • namespace: 一覧から namespace を選択します。正しいアクセスロールが割り当てられている場合は、有効な Kubernetes 名を使用して namespace を作成することもできます。
  4. 使用できるリポジトリーの一覧から Git を選択します。

  5. 必要な URL パスを入力するか、既存のパスを選択します。

    既存の Git リポジトリーパスを選択し、そのリポジトリーがプライベートの場合には、接続情報を指定する必要はありません。接続情報が事前設定されているので、これらの値を確認する必要はありません。

    新しい Git リポジトリーパスを入力し、その Git リポジトリーがプライベートの場合には、オプションで Git 接続情報を入力できます。

  6. ブランチやパスなど、オプションでフィールドに値を入力します。
  7. 調整オプションに注意してください。merge オプションは、新規フィールドが追加され、既存フィールドがリソースで更新されることを意味するデフォルトの選択です。replace を選択することができます。replace オプションを指定すると、既存のリソースが Git ソースに置き換えられます。

  8. デプロイメントの前後のタスクをオプションで設定します。

    テクノロジープレビュー: サブスクリプションがアプリケーションリソースをデプロイする前後に実行する Ansible Tower ジョブがある場合には、Ansible Tower のシークレットを設定します。Ansible ジョブを定義する Ansible Tower タスクは、このリポジトリーの prehook および posthook フォルダー内に配置する必要があります。

    シークレットをアプリケーション namespace に作成した場合は、ドロップダウンメニューから Ansible Tower シークレットを選択できます。この例では、接続情報は設定されており、これらの値を表示する必要はありません。

    新しい Ansible Tower シークレット名を入力して新しいシークレットを作成する場合は、Ansible Tower ホストおよびトークンを入力する必要があります。

  9. Select clusters to deploy で、アプリケーションの配置ルールの情報を更新できます。以下から選択します。

    • ローカルクラスターへのデプロイ
    • すべてのオンラインクラスターおよびローカルクラスターへのデプロイ
    • 指定されたラベルに一致するクラスターのみへのアプリケーションリソースのデプロイ
    • 配置ルールが定義済みの既存の namespace にアプリケーションを作成した場合には、既存の配置設定を選択する こともできます。
  10. Settings から、アプリケーションの動作を指定できます。特定の期間にデプロイメントへの変更をブロックまたは有効にするには、Deployment window のオプションおよび Time window configuration を選択します。
  11. 別のリポジトリーを選択するか、または Save をクリックします。
  12. Overview ページにリダイレクトされ、詳細とトポロジーを確認できます。

1.3.1.1. GitOps パターン

Git リポジトリーを編成してクラスターを管理するベストプラクティスについて説明します。

1.3.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.3.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.3.1.1.3. その他の例
  • root-subscription/ の例については、application-subscribe-all を参照してください。
  • 同じリポジトリー内の他のフォルダーを参照するサブスクリプションの例は、subscribe-all を参照してください。
  • nginx-apps リポジトリーのアプリケーションアーティファクトを含む common-managed フォルダーの例を参照してください。
  • Policy collection のポリシーの例を参照してください。