fbpx

Docker Composeなどの便利なツールでKubernetesをわかりやすくしよう #docker #kubernetes #k8s

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

私たちは、Compose on Kubernetesサポートをオープンソース化したことを喜んでお伝えいたします。 Docker Enterprise Edition (Docker EE)ではこの機能が使用可能となっていましたが、昨年12月4日以降、あらゆるKubernetesクラスタでこのサポートをご利用いただけるようにしました。

すでにKubernetesがあるのに、Docker Composeが必要なのですか?

Kubernetes APIは、非常に規模が大きいものです。PodやDeploymentからValidatingWebhookConfigurationやResourceQuotaに至るまで、最新のリリースには50以上もの第一級オブジェクトがあります。そのため設定作業が冗長化し、開発者、つまりあなたが設定管理しなければならない手間が増えることとなります。その具体的な例を見てみましょう。

Sock Shopは、マイクロサービスアプリケーションの典型的なサンプルです。このアプリケーションは、さまざまな技術とバックエンドを使用する多数のサービスから成っており、そのすべてをDockerイメージとしてパッケージングしています。また、Docker ComposeとKubernetesの生の設定など、さまざまなツールを使用する設定例も提供しています。これらの設定について、それぞれの行数を見てみましょう:


$ git clone https://github.com/microservices-demo/microservices-demo.git
$ cd deployment/kubernetes/manifests
$ (Get-ChildItem -Recurse -File | Get-Content | Measure-Object -line).Lines
 
908
$ cd ../../docker-compose
$ (Get-Content docker-compose.yml | Measure-Object -line).Lines
 
174

生のKubernetesオブジェクトを使用する場合、まったく同じマルチサービスアプリケーションの記述でDocker Composeを使用した場合の5倍もの量の設定が必要です。コードサイズは初回の作成コストのみならず、今後継続してかかるメンテナンスコストにもなります。Kubernetes APIは、驚くほど汎用性に優れています。あらゆる種類の分散型システムを構築するための低レベルな基本機能を公開しています。一方Docker ComposeはAPIではありませんが、開発者の生産性に特化した高レベルなツールです。それゆえ両者を共に使用することに意味があるのです。相互接続した一連のウェブサービスでのよくある例に対して、Docker ComposeはKubernetes設定をシンプルにする抽象化を提供します。その他すべては、生のKubernetes APIの基本機能に任せることができます。実際の様子を見てみましょう。

まずKubernetesクラスタに対して、Docker Compose用のKubernetesコントローラを導入する必要があります。このコントローラは"スタック"というDockerの概念をKubernetes APIに導入するために、Kubernetesの標準的なエクステンションポイントを使用します。どのようなKubernetesクラスタでも利用可能ですが、手元に使えるKubernetesがなければDocker Desktopを使いましょう。Docker DesktopはKubernetesとDocker Composeコントローラを内蔵しており、設定でチェックボックスをチェックするだけでそれらを有効にすることができます。

Kubernetesクラスタにコントローラを手動でインストールするには、このインストール手順の完全なドキュメントをご参照ください。

次はシンプルなDocker Composeファイルを書いてみましょう:


version: "3.7"
services:
web:
image: dockerdemos/lab-web
ports:
- "33000:80"
words:
image: dockerdemos/lab-words
deploy:
replicas: 3
endpoint_mode: dnsrr
db:
image: dockerdemos/lab-db

次にDockerクライアントを使用し、コントローラを実行しているKubernetesクラスタにデプロイします:


$ docker stack deploy --orchestrator=kubernetes -c docker-compose.yml words
Waiting for the stack to be stable and running...
db: Ready [pod status: 1/1 ready, 0/1 pending, 0/1 failed]
web: Ready [pod status: 1/1 ready, 0/1 pending, 0/1 failed]
words: Ready [pod status: 1/3 ready, 2/3 pending, 0/3 failed]
Stack words is stable and running

これでKubernetes APIを通してこれらのオブジェクトとの通信が可能となりました。Serviceをはじめ、Pod、Deployment、そしてReplicaSetなどの低レベルなオブジェクトを自動作成できたことをご覧ください:


$ kubectl get all
NAME READY STATUS RESTARTS AGE
pod/db-85849797f6-bhpm8 1/1 Running 0 57s
pod/web-7974f485b7-j7nvt 1/1 Running 0 57s
pod/words-8fd6c974-44r4s 1/1 Running 0 57s
pod/words-8fd6c974-7c59p 1/1 Running 0 57s
pod/words-8fd6c974-zclh5 1/1 Running 0 57s
 
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/db ClusterIP None 55555/TCP 57s
service/kubernetes ClusterIP 10.96.0.1 443/TCP 4d
service/web ClusterIP None 55555/TCP 57s
service/web-published LoadBalancer 10.102.236.49 localhost 33000:31910/TCP 57s
service/words ClusterIP None 55555/TCP 57s
 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
deployment.apps/db 1 1 1 1 57s
deployment.apps/web 1 1 1 1 57s
deployment.apps/words 3 3 3 3 57s
 
NAME DESIRED CURRENT READY AGE
replicaset.apps/db-85849797f6 1 1 1 57s
replicaset.apps/web-7974f485b7 1 1 1 57s
replicaset.apps/words-8fd6c974 3 3 3 57s

重要なことは、このアプリを起動するためだけの処理ではないということです。Docker Compose用のKubernetesコントローラは、StackというリソースをKubernetes APIを導入しました。これにより、今後アプリケーションを構築する際、すべての問い合わせと管理を、同じ抽象化レベルで行うことが可能となります。このことは使いやすさを越えて、各部が機能する仕組みや問題のデバッグについて、時間をかけずに掘り下げて理解する一助となります:


$ kubectl get stack
NAME STATUS PUBLISHED PORTS PODS AGE
words Running 33000 5/5 4m

その他のKubernetesツールとの統合

今やStackはネイティブのKubernetesオブジェクトなので、その他のKubernetesツールを同時に使用して作業することも可能です。例として、次を stack.yaml として保存します:


kind: Stack
apiVersion: compose.docker.com/v1beta2
metadata:
name: hello
spec:
services:
- name: hello
image: garethr/skaffold-example
ports:
- mode: ingress
target: 5678
published: 5678
protocol: tcp

Skaffoldのようなツールを使用すれば、イメージを自動で再構築し、アプリケーションの詳細をいかに変更をした場合でも、自動でStackの再デプロイが可能になります。このことが素晴らしい内部ループ開発体験を可能とします。必要なのは、次の skaffold.yaml 設定ファイルのみです。


apiVersion: skaffold/v1alpha5
kind: Config
build:
tagPolicy:
sha256: {}
artifacts:
- image: garethr/skaffold-example
local:
useBuildkit: true
deploy:
kubectl:
manifests:
- stack.yaml

今後の抱負

Docker Composeでアプリケーションの記述を作成し、Helmで簡単にデプロイできるようにするために、Helmプラグインについて検討中です。この他にも、プラットフォームのいかなる機能も失わずに、Kubernetesでより簡単に作業できる開発体験を促進するための、多くのアイデアがあります。また私たちは、より広範なクラウドネイティブのコミュニティと協力したいと考えていますので、ご意見やご提案があれば是非お知らせください。

Kubernetesは拡張可能な設計ですので、今回のリリースが皆さまのお役に立てることを願っています。あなたがもし、数百万人のDocker Compose ユーザのうちの一人ならば、これによってKubernetesへのアプリケーション移行がより簡単に、またその管理もより簡単になりました。あなたがもし、Kubernetesユーザで、多すぎる低レベルの設定に苦戦しているならば、Docker Composeを是非お試しください。コメント欄にご意見をお寄せください。またGitHubにアクセスしてお試しください。問題があればお気軽にissueを登録してください:


原文: Simplifying Kubernetes with Docker Compose and Friends

New call-to-action
新規CTA