1.3. アプリケーションリソースの管理
コンソールから、Git リポジトリー、Helm リポジトリー、およびオブジェクトストレージリポジトリーを使用してアプリケーションを作成できます。
重要: Git チャネルは、他のすべてのチャネルタイプ (Helm、オブジェクトストレージ、およびその他の Git namespace) と namespace を共有できます。
アプリケーションの管理を開始する場合は、以下のトピックを参照してください。
1.3.1. Git リポジトリーを使用したアプリケーションの管理
アプリケーションを使用して Kubernetes リソースをデプロイする場合に、リソースは特定のリポジトリーに配置されます。以下の手順で、Git リポジトリーからリソースをデプロイする方法を説明します。詳細は、「 アプリケーションモデルおよび定義 」を参照してください。
ユーザーに必要なアクセス権: アプリケーションを作成できるユーザーロールロールが割り当てられているアクションのみを実行できます。「ロールベースのアクセス制御」のドキュメントで、アクセス要件について確認してください。
- コンソールのナビゲーションメニューから Manage applications をクリックします。
Create application を クリックします。
以下の手順では、YAML: On を選択し、アプリケーションの作成時にコンソールで YAML を表示します。このトピックの後半にある「YAML サンプル」を参照してください。
以下の値を正しいフィールドに入力します。
- Name: アプリケーションの有効な Kubernetes 名を入力します。
- namespace: 一覧から namespace を選択します。正しいアクセスロールが割り当てられている場合は、有効な Kubernetes 名を使用して namespace を作成することもできます。
- 使用できるリポジトリーの一覧から Git を選択します。
必要な URL パスを入力するか、既存のパスを選択します。
既存の Git リポジトリーパスを選択し、そのリポジトリーがプライベートの場合には、接続情報を指定する必要はありません。接続情報が事前設定されているので、これらの値を確認する必要はありません。
新しい Git リポジトリーパスを入力し、その Git リポジトリーがプライベートの場合には、オプションで Git 接続情報を入力できます。
- ブランチ、パス、コミットハッシュなど、オプションでフィールドに値を入力します。オプションのフィールドは、フィールドまたはマウスオーバーのテキストで定義されます。
調整オプションに着目します。
mergeオプションは、新規フィールドが追加され、既存フィールドがリソースで更新されることを意味するデフォルトの選択です。replaceを選択することができます。replaceオプションを指定すると、既存のリソースが Git ソースに置き換えられます。-
サブスクリプションの調整速度を
lowに設定すると、サブスクライブしているアプリケーションリソースの調整に最大 1 時間かかる場合があります。単一アプリケーションビューのカードで、 Sync をクリックして手動で調整します。offに設定すると、調整はありません。
-
サブスクリプションの調整速度を
デプロイメントの前後のタスクをオプションで設定します。
サブスクリプションがアプリケーションリソースをデプロイする前後に実行する Ansible Tower ジョブがある場合は、Ansible Tower シークレットを設定します。Ansible ジョブを定義する Ansible Tower タスクは、このリポジトリーの
prehookおよびposthookフォルダー内に配置する必要があります。コンソールの Credential セクションからドロップダウンメニューをクリックし、Ansible 認証情報を選択します。認証情報を追加する必要がある場合は、「 認証情報の管理」を参照してください。
Select clusters to deploy で、アプリケーションの配置ルールの情報を更新できます。以下から選択します。
- ローカルクラスターへのデプロイ
- すべてのオンラインクラスターおよびローカルクラスターへのデプロイ
- 指定されたラベルに一致するクラスターのみへのアプリケーションリソースのデプロイ
- 配置ルールが定義済みの既存の namespace にアプリケーションを作成した場合には、既存の配置設定を選択する こともできます。
- Settings から、アプリケーションの動作を指定できます。特定の期間にデプロイメントへの変更をブロックまたは有効にするには、Deployment window のオプションおよび Time window configuration を選択します。
- 別のリポジトリーを選択するか、または Save をクリックします。
- 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 のサブスクリプションフロー用に作成されます。
-
root-subscription/の単一サブスクリプションは、CLI ターミナルからハブクラスターに適用されます。 サブスクリプションとポリシーは、
managed-subscriptionフォルダーからハブクラスターにダウンロードされ、適用されます。-
managed-subscriptionフォルダーのサブスクリプションおよびポリシーは、配置に基づいてマネージドクラスターで機能します。 -
配置は、各サブスクリプションまたはポリシーが影響を及ぼす
managed-clustersを決定します。 - サブスクリプションまたはポリシーは、配置に一致するクラスター上のものを定義します。
-
-
サブスクリプションは、
common-managedフォルダーのコンテンツを、配置ルールに一致するmanaged-clustersに適用します。また、配置ルールに一致するすべてのmanaged-clustersに対して、一般的なアプリケーションおよび設定も適用されます。
1.3.1.1.3. その他の例
-
root-subscription/の例については、application-subscribe-all を参照してください。 - 同じリポジトリー内の他のフォルダーを参照するサブスクリプションの例は、subscribe-all を参照してください。
-
nginx-apps リポジトリーのアプリケーションアーティファクトを含む
common-managedフォルダーの例を参照してください。 - Policy collection のポリシーの例を参照してください。
