【Docker Kanvas入門】Docker ComposeファイルをKubernetesに自動変換して本番デプロイを劇的に楽にする方法

DevOps

Docker Desktop拡張の「Kanvas」を使えば、既存のdocker-compose.ymlをKubernetesマニフェストに自動変換でき、K8s移行の最大の壁であるYAML地獄を回避できます。HelmやKustomizeより学習コストが低く、視覚的なUI上でドラッグ＆ドロップによるインフラ設計〜運用監視まで一気通貫で行えます。

Docker ComposeからKubernetesへの移行が一瞬で完了する

[IMAGE: kanvas_overview]

Docker Composeで構築したローカル開発環境を本番のKubernetesクラスタにデプロイしようとして、途方に暮れた経験はありませんか。

docker-compose.ymlに書いた数十行の設定を、Kubernetes用に書き直すと——Deployment、Service、ConfigMap、PersistentVolumeClaim——といったリソースに分解する必要があります。さらにHelmを使うとなると、Chart.yamlやvalues.yamlの書き方、テンプレート構文の学習が必要です。

2026年1月、Dockerはこの問題を根本から解決するツール「Kanvas」を正式リリースしました。

KanvasはDocker Desktop上で動作する拡張機能で、docker-compose.ymlを読み込むだけで対応するKubernetesマニフェストを自動生成します。視覚的なGUIで設計から運用監視まで一気通貫で行えるのが最大の特徴です。

なぜ「Compose書けるけどKubernetesは難しい」という壁が生まれるのか

[IMAGE: compose_vs_k8s_gap]

Docker Composeは直感的です。servicesブロックにコンテナを並べ、portsでポートをマッピングし、volumesでデータを永続化する——これだけで開発環境が動きます。

一方でKubernetesは、同じことをするにも多くの概念理解が必要です。シンプルなnginxコンテナ1つの例でも、Composeの8行がKubernetes YAMLでは40行以上になります。サービスが増えるほどこの差は広がり、チーム全体がKubernetes YAMLを書けるようになるまでの学習コストは無視できません。

Kanvasはこのギャップをゼロにします。

Docker Kanvasで実際にComposeをK8sへ変換してみる

[IMAGE: kanvas_designer_mode]

インストール方法

KanvasはDocker Desktop拡張として提供されています。

docker extension install layer5io/kanvas-docker-extension

または、Docker Desktopの「Extensions」マーケットプレイスから「Kanvas」を検索してインストールできます。

Designer モード：ComposeからK8sへの変換

KanvasにはDesignerモードとOperatorモードの2つのモードがあります。Designerモードでdocker-compose.ymlをインポートすると、各サービスがKubernetesリソースとしてビジュアル表示されます。以下の3サービス構成のComposeファイルを例に見てみましょう。

version: '3.8'

services:
  frontend:
    image: myapp/frontend:latest
    ports:
      - "3000:3000"
    environment:
      - API_URL=http://backend:8080
    depends_on:
      - backend

  backend:
    image: myapp/backend:latest
    ports:
      - "8080:8080"
    environment:
      - DB_HOST=db
      - DB_PORT=5432
    depends_on:
      - db

  db:
    image: postgres:15
    environment:
      - POSTGRES_DB=myapp
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=password
    volumes:
      - db-data:/var/lib/postgresql/data

volumes:
  db-data:

Kanvasはこのファイルを読み込み、frontend-deployment.yaml・backend-deployment.yaml・db-statefulset.yaml・configmap.yamlを自動生成します。

生成されたマニフェストの確認

自動生成されるDeploymentには、Kubernetes移行時に見落としがちなresourcesフィールドが適切なデフォルト値で補完されています。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend
  labels:
    app: backend
    managed-by: kanvas
spec:
  replicas: 1
  selector:
    matchLabels:
      app: backend
  template:
    metadata:
      labels:
        app: backend
    spec:
      containers:
      - name: backend
        image: myapp/backend:latest
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "128Mi"
            cpu: "100m"
          limits:
            memory: "256Mi"
            cpu: "500m"

Operator モード：デプロイ後の運用監視

Designerモードでマニフェストを確認・調整したら、Operatorモードに切り替えます。各Podのログ・メトリクス・ネットワークトラフィック・ターミナルアクセスがリアルタイムで確認できます。

実務での活用シナリオ

シナリオ1: レガシーComposeアプリのK8s移行
開発チームが長年docker-compose.ymlで管理してきたアプリをクラスタ環境へ移行する際、マニフェスト生成を自動化してチームはビジネスロジックに集中できます。

シナリオ2: 新規プロジェクトのスタート
ローカルはCompose、本番はKubernetesという構成をゼロから作る場合、KanvasでアーキテクチャをGUI設計→マニフェスト生成→GitOps配置のフローが組めます。

シナリオ3: Helm学習中チームの橋渡し
Kanvasで動くマニフェストを生成し、後からHelmチャートに移行する段階的アプローチが取れます。

Docker ComposeユーザーがKubernetesを恐れなくていい時代が来た

[IMAGE: kanvas_workflow_summary]

Docker Kanvasの登場で、Kubernetes移行の最大の障壁だった「YAMLの壁」が大幅に低くなりました。Dockerチームが提唱する「Infrastructure as Design」——宣言的にインフラを設計するという考え方——は、開発者とインフラエンジニアの間のコミュニケーションギャップを埋める重要なコンセプトです。

今すぐKanvasを試す3ステップ

  1. Docker Desktopを最新版（v4.35以上）に更新する
  2. docker extension install layer5io/kanvas-docker-extensionを実行する
  3. 既存のdocker-compose.ymlをKanvasにインポートして生成されたマニフェストを確認する

まとめ

ツール 対象ユーザー 特徴 学習コスト
Docker Kanvas Composeユーザー 視覚的・自動変換 低
Helm 中〜大規模チーム パッケージ管理・再利用性 高
Kustomize K8s中級者 プレーンYAML・環境差分管理 中

Docker KanvasはHelmの代替ではなく「Helmへの入口」です。まずKanvasで動くマニフェストを手に入れ、規模が大きくなってからHelmやKustomizeへ移行する段階的アプローチが、2026年現在の現実的な選択肢です。

参考リンク

コメント