概要

問題の定義

ほとんどのアプリケーションデリバリーシナリオでは、アプリケーションアーティファクトのパッケージ形式とデリバリーメカニズムが対象となりますが、データストアやメッセージキューなどのアプリケーションのインフラストラクチャ依存関係は必ずしも対象とは限りません。つまり、アプリケーションとインフラストラクチャのデリバリーは連携されていません。多くの場合、アプリケーションは特定のデプロイメントに直接関連しないインフラストラクチャリソースに大きく依存しており、存在しないインフラストラクチャリソースの問題がデプロイメントの失敗を引き起こす可能性があります。これに加えて、アプリケーションとインフラストラクチャのライフサイクルは同期されておらず、ワークロードをデリバリーする際に追加の複雑さと課題を生み出します。

例:

• 開発者がローカル環境でアプリケーションをテストするためにストレージクラスを使用しているが、上位環境では利用できない。
• アプリケーションワークロードのデプロイと、そのサービスへのトラフィックをルーティングするための必要なIngressのデプロイは、別々の承認プロセスとフローとなる。
• 複雑なマイクロサービスアーキテクチャのデリバリーと、持続可能なGitOpsデプロイパターンの実現は、関連するものの別個のワークフローとして扱われる。

インフラと協調したアプリケーションデリバリーを実現するためのCI/CDパイプラインとその構成要素の設定は、組織内の暗黙知の一部であり、組織・システム・ドメインの境界を越えて容易に移転できません。

さらに、アプリケーションデリバリーを扱う際にはインフラが常に利用可能であると想定されることが多いです。ある時点では、インフラもGitOpsメカニズムやデプロイパイプラインを用いて展開できることが有用となる可能性があります。したがって、インフラデプロイとアプリケーションデリバリー／デプロイツール間には常に断絶が存在し、これがデプロイ問題や設定ミスを招く恐れがあります。

現在、これらのユースケースに対する普遍的なベストプラクティスや推奨事項は存在せず、プラットフォーム非依存な方法でアプリケーション全体を宣言する標準も確立されていません。

CrossplaneやTerraformといった主にインフラストラクチャのプロビジョニングに用いられるプロジェクトや、そのインフラ上でアプリケーションをプロビジョニングするArgo、Flux、Keptnなどのツールが存在します。また、OAMやDaprといったインフラを抽象化し、アプリケーションに代わって自動的に「注入」する新興プロジェクトもありますが、これらは（まだ）パブリッククラウドプラットフォームといった実装プロバイダーに広く採用されていません。本ワーキンググループは、アプリケーションとインフラストラクチャの連携がどのような形を取るべきかを明確化し、そのようなケースにおけるベストプラクティスを開発すべきと考えます。

この問題を解決することを目的としたツールの組み合わせにはどのようなものがあり、どのようなギャップが存在するのか？

このセクションでは、現在存在するソリューションのいくつかの組み合わせを提案し、その長所と短所を評価し、何が欠けているかを検討します（上記の例を最初のユースケースとして）。

インフラストラクチャ展開を目的とした既知のパターン例

網羅性を保証するものではありません：

• Terraform
• Crossplane
• ACK
• Pulumi
• CDK
• Open Service Broker ( https://www.openservicebrokerapi.org/)

アプリケーションデプロイを目的とした既知のパターン例

GitOps

このパターンは、Helm、Kustomize、または生のYAMLなどの既存ツールを基盤とし、Gitリポジトリ内の真実のソースからの変更をクラスターに適用するプロセスを自動化します。ArgoCDやFluxはこのパターンを実装するプロジェクトの例です。

アプリケーションオペレーター

このパターンは、DeploymentなどのネイティブKubernetesリソースを拡張し、アプリケーションのデプロイとライフサイクル管理を強化することを目的としています。重要な機能の一つはカナリアデプロイであり、Ingressやサービスメッシュとの連携、およびアプリケーションに関するドメイン知識が必要です。ArgoRolloutやFlaggerは、これらの高度な機能を備えたこのパターンを実装するプロジェクトの例です。

宣言型パイプライン

このパターンでは、ワークフローやプロセスをカプセル化した宣言型パイプラインを構築できます。これは、アーティファクトの構築、テスト、セキュリティ制御への適合確認といった CIプロセスの一部となり得ます。また、アーティファクトのデプロイ、カスタムテストの実行、カスタムカナリアロジックの実装といったCDライフサイクルでも使用可能です。宣言型パイプラインは、グラフ内の次のポイントへ移動するための決定ポイントを持つ 有向グラフ と考えることができます。決定は自動化される場合もあれば、通知システムと連動した手動承認が必要な場合もあります。KeptnやArgoWorkflowといったプロジェクトは、宣言型パイプライン構築を可能にするソリューションの例です。

コンポジションオペレーター

KubernetesのCRDによるリソース表現は複雑で、他のCRDへの依存関係を持つ場合もあります。特にインフラストラクチャリソースに関しては、アプリケーションチームと運用チームの間で関心の分離が必要となります。このパターンでは、複数の他のCRDを構成要素としてリソースを組み立て、最上位CRDが要求するパラメータ数を簡素化または隠蔽できます。CrossPlane XRD/XRCやKubeVelaはこのパターンを提供するプロジェクトの例です。

インフラストラクチャオペレーター

クラウドプロバイダーのインフラストラクチャリソースをCRDとして宣言し、Kubernetes上のアプリケーションデプロイメントライフサイクルに統合する必要性があります。インフラストラクチャオペレーターパターンでは、CRDをクラスタに適用し、オペレーターが要求と望ましい状態を収束させるための必要なロジックを実装します。クラウドプロバイダへのオペレーター統合は、ネイティブクラウドプロバイダAPI、CloudFormationテンプレート、TerraFormなど、様々な形態を取ることができます。CrossPlane ProviderやAWS Controller for Kubernetes (ACK) は、このパターンを提供するプロジェクトの例です。

TAG App Delivery憲章との整合性

アプリケーションデリバリーは基盤インフラ（外部データベースやメッセージキューなどのサービス）と密接に結びつくため、パッケージ形式やデリバリーワークフローに影響を及ぼすことが多くなります。本トピックはTAG憲章における「アプリケーション定義（記述・パラメータ・構成を含む）」「アプリケーションバンドリングとデプロイ」「アプリケーションデリバリーワークフローと戦略」を扱います。これらは構成駆動型ツール（「GitOps」）を用いて実施されるべきであるため、「構成ソース駆動型ワークフロー」領域にも関連します。

作業モード／期待される成果

本グループは、これらのユースケース（例：コードとしてのApp-Ready-Platform）を扱うための概念を議論し、計画を立て、デモインフラストラクチャ（コードとして）を開発します。これは様々なツール（ランドスケープへのリンク）を用いて実装され、エンドユーザー向けの青写真となり得ます。さらに検証済みのベストプラクティスはホワイトペーパーとして文書化される可能性があります。

目標

本シナリオにおける主要ステークホルダー（CKA/CKAD資格を有する可能性のあるエンジニア）に焦点を当て、クラウドインフラ上でのアプリケーションワークロード提供を実現することを目的とする。

• ベンダーおよびエンドユーザーへのインタビュー
• 製品の成功要因と課題点を特定する焦点質問
• 現在の実践手法とランドスケープの把握
• ランドスケープレーダー
• Podtato-headプロジェクトにおけるIaCとCDツール間の相互運用性事例の提供
• アプリケーションとインフラストラクチャのデプロイ統合手法に関するエンドユーザー向けアイデア・事例の提供
• 実践的な作業とエンドユーザーの実装方法に基づくパターンをホワイトペーパーで提供。業界内で見られる実践例やトレンドを提示し、エンドユーザーに価値ある情報を強調。

非目標

• 新たな標準規格の策定
• マイクロサービスアプリケーションやクラウドネイティブアーキテクチャの構築方法に関する見解
• デプロイ方法の定義
• 新たなCNCFオープンソースプロジェクトの創設