ComposeからKubernetes、そしてクラウドへ:Kanvasによるインフラ設計と運用

Dockerは長い間、コンテナを動かす最も簡単な方法でした。開発者は docker-compose.yml ファイルから始め、 docker compose upを実行し、高速で動作させます。

チームが成長し、ワークロードがKubernetesに拡大し、クラウドサービスに統合されるにつれて、シンプルさは薄れていきます。Kubernetesはクラウドのオペレーティングシステムとなっていますが、クラスターが孤立して存在することはほとんどありません。実際のプラットフォームは、AWS Sの3 バケット、Azure仮想マシン、Google Cloud SQLデータベースなど、独自のクラウドサービスが複雑に混在し、コンテナ化されたワークロードと並行して動作しています。あなたとチームは、YAMLの海の中でクラスターやクラウドを扱っています。

このハイブリッドなスプロールを管理するには、Docker Desktop、Kubernetes CLI、クラウドプロバイダーコンソール、インフラストラクチャ・アズ・コード間のコンテキスト切り替えを意味します。複数の異なるツールを同時に使いこなすと、シンプルさは薄れていきます。

この混乱から明確さを取り戻すのが、Layer5の新しいDocker Kanvas拡張機能です。これはDocker Desktopに直接組み込まれた視覚的で協調的なワークスペースで、Kubernetesリソースだけでなく、AWS、GCP、Azureにわたるクラウドインフラ全体の設計、展開、運用を可能にします。

カンヴァスとは何か?

Kanvas は、エンジニアがマルチクラウドおよびKubernetesネイティブのインフラを可視化、管理、設計するための協働プラットフォームです。Kanvasは、 インフラをコードとして 考える概念を 、設計としてのインフラへと変革します。つまり、アーキテクチャ図はもはや単なるドキュメントではなく、展開を動かす真実の源となるのです。Meshery(Cloud Native Computing Foundationの最高速オープンソースプロジェクトの一つ)の上に構築されたKanvasは、単純なKubernetesマニフェストを超え、特定のクラウドリソースのプロパティや挙動を記述するMesheryモデルを用いて進化しています。これにより、Kanvasは膨大なインフラストラクチャ・アズ・ア・サービス(IaaS)コンポーネントカタログをサポートできます。 

• AWS: 55+サービス(例:EC2、Lambda、RDS、DynamoDB)。
• Azure: 50+コンポーネント(例:仮想マシン、Blob Storage、VNet)を扱います。
• GCP:Compute Engine、BigQuery、Pub/Subなど 60+サービス。

Kanvasは、抽象建築と具体的な操作のギャップを、デザイナーとオペレーターという2つの統合モードを通じて埋めています。

デザイナーモード (宣言モード)

デザイナーモードはクラウドアーキテクトやDevOpsチームのための「ブループリントスタジオ」として機能し、宣言的モデリング(インフラの構築方法を段階的に説明するのではなく)を重視し、GitOpsのワークフローやチームベースの計画に最適です。 

• 共同で構築・反復を行う:注釈、 デザインレビュー用のコメント、コンポーネント間の接続を追加して、データの流れ、アーキテクチャ、関係性を可視化します。
• 展開の試行と検証: 本番環境に入る前に、設定が有効で必要な権限があるかを 試行して試行を行ってください。 
• 輸出入: ブラウンフィールドは既存のクラスタを接続したり、GitHubリポジトリからHelmチャートをインポートして設計します。 
• パターンの再利用、クローン、共有:リファレンスアーキテクチャ、サンプル構成、インフラテンプレートの カタログ から選び、白紙の設計ではなく実証済みの設計図から始めましょう。Googleドキュメントのようにデザインを共有するのと同じです。GitHubのリポジトリと同じようにデザインをクローンします。プルリクエストのようにデザインをマージします。

オペレーターモード(命令型モード)

Kanvasオペレーターモードは静的なダイアグラムをライブで管理されるインフラに変換します。オペレーターモードに切り替えると、Kanvasは設定ツールではなく、Kubernetesコントローラー(AWS Controllers for Kubernetes(ACK)やGoogle Config Connectorなど)を使って設計をアクティブに管理するアクティブなインフラストラクチャコンソールとなります。

オペレーターモードでは以下が可能です:

• 負荷試験と性能管理: オペレーター内蔵の負荷発生装置を使えば、あらかじめ定義されたパフォーマンスプロファイルに対して遅延やスループットを分析し、ストレステストを実行し、デザイナーモードで行われたインフラ構成変更の影響を測定するための基準値を確立できます。

• マルチプレイヤー、インタラクティブ端末: コンテナでシェルセッションを開き、コマンドを実行し、ビジュアルトポロジーを離れずにコンテナログをストリーミング・検索してください。セッションをチームメイトと共有することでトラブルシューティングを効率化しましょう。コンテキスト内に留まり、kubectlのような外部コマンドラインツールへのコンテキスト切り替えは避けましょう。
• 統合観測性: Prometheusの統合を使って、CPU使用率、メモリ、リクエスト遅延などの主要なパフォーマンス指標を重ね合わせ、建築内のスポット「ホットスポット」を視覚的に素早く見つけましょう。既存のGrafanaダッシュボードをインポートして、より深い分析を行ってください。
• マルチクラスター、マルチクラウドの運用: 複数のKubernetesクラスター(異なるクラウドや地域にまたがる)を接続し、GKEクラスターとEKSクラスターにまたがるワークロードを単一のトポロジービューで管理します。すべてを単一のKanvasインターフェースから。

Kanvasデザイナーモードが意図(作りたいもの )が重要な のに対し、オペレーターモードは 現実 (実際に動いているもの)が重要です。Kanvasデザイナーモードとオペレーターモードは、単に同じコインの両面が密接に統合されたものです。 

この理解を踏まえ、Docker Desktopで両方のモードが実際に動作しているか見てみましょう。

ウォークスルー:ComposeからKubernetesまで数分で

Docker Kanvas拡張機能(Docker Hubからインストール)を使えば、既存のDocker ComposeファイルをKubernetesに即座に変換でき、理解、拡張、大規模展開が非常に簡単にできます。

Docker Samples リポジトリには膨大なサンプルが提供されています。下に Springを拠点としたPetClinic の例を使います。 

# sample docker-compose.yml

services:
  petclinic:
    build:
      context: .
      dockerfile: Dockerfile.multi
      target: development
    ports:
      - 8000:8000
      - 8080:8080
    environment:
      - SERVER_PORT=8080
      - MYSQL_URL=jdbc:mysql://mysqlserver/petclinic
    volumes:
      - ./:/app
    depends_on:
      - mysqlserver
    
  mysqlserver:
    image: mysql:8
    ports:
      - 3306:3306
    environment:
      - MYSQL_ROOT_PASSWORD=
      - MYSQL_ALLOW_EMPTY_PASSWORD=true
      - MYSQL_USER=petclinic
      - MYSQL_PASSWORD=petclinic
      - MYSQL_DATABASE=petclinic
    volumes:
      - mysql_data:/var/lib/mysql
      - mysql_config:/etc/mysql/conf.d
volumes:
  mysql_data:
  mysql_config:

Docker Kanvas拡張機能をインストールした状態で:

1. サンプルアプリをインポート: PetClinicの docker-compose.yml ファイルをパソコンに保存し、その後クリックしてファイルをインポートまたはドラッグ&ドロップしてKanvasに移動させます。

Kanvasはスタックのインタラクティブなトポロジーをレンダリングし、サービス、依存関係(MySQLなど)、ボリューム、ポート、構成をKubernetesの対応物にマッピングします。Kanvasはこのレンダリングを段階的に行い、各段階で行われる評価においてより厳格な審査を施しています。この段階的な評価プロセスの詳細を後ほど詳しく見ていきましょう。

2. ペットクリニックのデザインを強化する

ここから、生成されたデザインを視覚的でYAMLなしで強化できます:

• LoadBalancer、Ingress、またはConfigMapを追加する
• データベースのURLや環境変数の シークレット を設定する
• サービス関係の変更や新しいコンポーネントの接続
• コメントやその他の注釈を追加してください。

重要なのは、Kanvasは変更時にデザインを 保存してくれる ことです。これにより、Composeファイルから直接生成される本番環境対応のデプロイアーティファクトが得られます。

3. クラスターへの展開

ワンクリックで、Docker Desktopや他のリモートクラスターに接続された任意のクラスタに設計を展開できます。Kanvasは翻訳を担当し、あなたの設定を適用します。

4. モードを切り替えてアプリとやり取りしましょう

展開後(または既存のワークロードを管理中)に切り替え、オペレーターモードに切り替えて、展開した設計を観察・管理してください。できます：

• デプロイメント、サービス、ポッドおよびそれらの関係を検査してください。
•  コンテナでターミナルセッションを開いて、素早くデバッグしましょう。
•  コンテナログをテールして検索し、リソース指標を監視しましょう。
•  トラフィックを生成し、負荷の高い負荷下での展開パフォーマンスを分析しましょう。
• オペレータービューをチームメイトと共有し、共同管理しましょう。

数分で、Composeベースのプロジェクトが完全に管理されたKubernetesワークロードとなり、Docker Desktopを離れることなく実現します。単純なComposeファイルから完全に管理され、運用可能なワークロードへとシームレスに流れることは、インフラを視覚的に管理しやすいことを示しています。これにより 、Infrastructure as Designの根本的な原則について考えさせられます。

インフラとデザイン

インフラ設計は、スタックの視覚的なレイアウトを構成の主要な推進力とし、コンポーネントの近接性や接続性を調整する行為とインフラの構成プロセスが同一です。言い換えれば、個々の構成要素の存在、不在、近接性、または接続性(これらすべてが一つの構成要素と他方の関係に影響を与えます)が、それぞれの基盤となる構成を補強します。カンヴァスはこの点で非常に知的で、各コンポーネントが他のコンポーネントとどのように関係しているかを非常に細かく理解し、それらの構成をそれに応じて補強します。

Kanvasがスタックのアーキテクチャのトポロジーを段階的にレンダリングするプロセスを理解してください。初期レンダリングでは各部品の軽量な分析を行い、新しいデザインの内容の基準を設定します。次のレンダリング段階では、Kanvasがスタックの各コンポーネントの構成や相互依存関係を内省し、各コンポーネントが互いにどのように関係しているかを積極的に評価し、より高度な分析を施します。Kanvasはこの関係評価の結果として、コンポーネントの設定を追加、削除、更新します。

この 関係性評価 のプロセスは継続しています。設計を変更するたびに、Kanvasは各コンポーネント構成を再評価します。

例を挙げると、Kubernetesの同じ名前空間の近くにKubernetesデプロイメントを設置すると、一方が磁化して次の展開に移り、あなたのデプロイメントが名前空間内に視覚的に配置され、同時にそのデプロイの設定が新しい名前空間の指定を含むように変異します。Kanvasは、変更を加えるたびに、設計上のインフラリソースの構成を積極的に 評価 し、 変化させます 。

Kanvasが設計の変化をインテリジェントに解釈し適応し、設定や関係を自動的に管理する能力こそが 、インフラを設計として実現する鍵です。この力は、カンヴァスに一定の知性を与える高度なシステムから来ているが、その信頼性は政策駆動型のエンジンである。

決定論的真実に支えられたAIのような知能

生成AIがインフラ設計を劇的に加速させる時代において、「幻覚」—もっともらしいが機能的には無効な構成—のリスクは依然として重要なボトルネックとなっています。KanvasはAIの生成力と硬直的で決定論的な政策エンジンを組み合わせることでこれを解決しています。

このエンジンはアーキテクチャのガードレールとして機能し、AIが構成の正確性を評価する度合いを正確にコントロールできます。単純な視覚的な図から、検証済みの展開可能な設計図へと変貌させます。

AIモデルが確率的に機能するのに対し、Kanvasのポリシーエンジンは決定論的に機能し、設計を自動的に解析してグラウンドトゥルースルールに基づいてコンポーネント間の接続を識別、検証、強制します。これらのルールはそれぞれのKanvasモデルで静的に定義され、バージョン管理されています。

• 深い文脈化: 評価は単なる可視化を超えています。関係をコンテキスト認識かつ宣言的として扱い、コンポーネント間の相互作用(例:データフロー、依存関係、リソース共有)を解釈することで、設計が単なる想像力だけでなく、展開可能で準拠であることを保証します。
• 意味的厳密性: このエンジンは、ポートを自動設定するTCP接続のようなインフラ的に意味のある 関係 と 、非意味的関係 (注釈のようなユーザー定義のビジュアル)を区別します。これにより、美的選択がインフラの健全性を損なうことが決してありません。

カンヴァスは信頼が二元論ではないことを認めています。エンジンがAI生成の提案とどのように相互作用するかを細かく制御することで、自分のデザインに対する主権を維持します。

• 「ヒューマン・イン・ザ・ループ」スライダー: 保険評価の厳格さを調整できます。AIに高水準アーキテクチャを提案させつつ、セキュリティ設定(ポート露出やIAMロールなど)に厳格なポリシーを強制させることも可能です。
• 選択的評価: 特定のカテゴリーの設定で評価を無効にすることができます。例えば、AIが有効なKubernetesサービス定義を生成すると信頼しつつ、ポリシーエンジンに完全に依存してリンクするIngressコントローラーの検証を行える場合もあります。

Kanvasは単にエラーをフラグ付けするだけでなく、高度な検出・修正戦略を用いてこれらの問題を解決するために積極的に取り組んでいます。

• インテリジェントスキャン:エンジンはコンポーネントの種類、種類、サブタイプ(例:ポート露出を通じてServiceにリンクするDeployment)に基づいて潜在的な関係をスキャンし、AIが見落としがちな論理的なギャップを検出します。
• パッチとリソルバー: 部分的または幻覚的な構成が検出されると、Kanvasはパッチを適用して欠落した構成を伝播したり、競合を解決するために構成を動的に調整したりします。これにより、最終的なインフラストラクチャ・アズ・コードのエクスポート(例:Kubernetesマニフェスト、Helmチャート)がクリーンでバージョン可能かつ安全であることを保証します。

複雑さを明晰さに変えよう

Kanvasは現代のインフラ管理における推測を排除します。Docker Composeに慣れている開発者にとっては、Kubernetesやクラウドサービスへの自然な橋渡しとなり、可視性とコラボレーションが組み込まれています。

Kanvasは視覚デザインとリアルタイム操作を直接Docker Desktopに取り入れます。Composeファイル、Kubernetesマニフェスト、Helm Charts、Kustomizeファイルをインポートして、すぐに使えるアーキテクチャのカタログを探索し、数分でKubernetesに展開できます。YAMLの整理は不要です。

設計はOCI準拠の画像として エクスポートしたり、Docker Hub、GitHub Container Registry、AWS ECRなどのレジストリを通じて共有したりすることで、設計のバージョンを守り、ポータブルなままインフラを維持できます。

Kanvas拡張機能を からインストールしてください Docker Hub そして、今日からインフラの設計を始めましょう。