{"id":876,"date":"2018-12-07T04:28:23","date_gmt":"2018-12-07T04:28:23","guid":{"rendered":"https:\/\/www.appservgrid.com\/paw93\/?p=876"},"modified":"2018-12-11T03:10:49","modified_gmt":"2018-12-11T03:10:49","slug":"simplifying-kubernetes-with-docker-compose-and-friends","status":"publish","type":"post","link":"https:\/\/www.appservgrid.com\/paw93\/index.php\/2018\/12\/07\/simplifying-kubernetes-with-docker-compose-and-friends\/","title":{"rendered":"Simplifying Kubernetes with Docker Compose and Friends"},"content":{"rendered":"

Today we\u2019re happy to announce we\u2019re open sourcing our support for using Docker Compose on Kubernetes<\/a>. We\u2019ve had this capability in Docker Enterprise for a little while but as of today you will be able to use this on any Kubernetes cluster you choose.<\/p>\n

\"Compose<\/p>\n

Why do I need Compose if I already have Kubernetes?<\/b><\/h3>\n

The Kubernetes API is really quite large. There are more than 50 first-class objects in the latest release, from Pods and Deployments to ValidatingWebhookConfiguration and ResourceQuota. This can lead to a verbosity in configuration, which then needs to be managed by you, the developer. Let\u2019s look at a concrete example of that.<\/p>\n

The Sock Shop<\/a> is the canonical example of a microservices application. It consists of multiple services using different technologies and backends, all packaged up as Docker images. It also provides example configurations using different tools, including both Compose and raw Kubernetes configuration. Let\u2019s have a look at the relative sizes of those configurations:<\/p>\n

$ git clone https:\/\/github.com\/microservices-demo\/microservices-demo.git
\n$ cd deployment\/kubernetes\/manifests
\n$ (Get-ChildItem -Recurse -File | Get-Content | Measure-Object -line).Lines
\n908
\n$ cd ..\/..\/docker-compose
\n$ (Get-Content docker-compose.yml | Measure-Object -line).Lines
\n174<\/p>\n

Describing the exact same multi-service application using just the raw Kubernetes objects takes more than 5 times the amount of configuration than with Compose. That\u2019s not just an upfront cost to author \u2013 it\u2019s also an ongoing cost to maintain. The Kubernetes API is amazingly general purpose \u2013 it exposes low-level primitives for building the full range of distributed systems. Compose meanwhile isn\u2019t an API but a high-level tool focused on developer productivity. That\u2019s why combining them together makes sense. For the common case of a set of interconnected web services, Compose provides an abstraction that simplifies Kubernetes configuration. For everything else you can still drop down to the raw Kubernetes API primitives. Let\u2019s see all that in action.<\/p>\n

First we need to install the Compose on Kubernetes controller into your Kubernetes cluster. This controller uses the standard Kubernetes extension points to introduce the `Stack` to the Kubernetes API. You can use any Kubernetes cluster you like, but if you don\u2019t already have one available then remember that Docker Desktop<\/a> comes with Kubernetes and the Compose controller built-in, and enabling it is as simple as ticking a box in the settings.<\/p>\n

To install the controller manually on any Kubernetes cluster, see the full documentation<\/a> for the current installation instructions.<\/p>\n

Next let\u2019s write a simple Compose file:<\/p>\n

version: “3.7”
\nservices:
\nweb:
\nimage: dockerdemos\/lab-web
\nports:
\n– “33000:80”
\nwords:
\nimage: dockerdemos\/lab-words
\ndeploy:
\nreplicas: 3
\nendpoint_mode: dnsrr
\ndb:
\nimage: dockerdemos\/lab-db<\/p>\n

We\u2019ll then use the docker client to deploy this to a Kubernetes cluster running the controller:<\/p>\n

$ docker stack deploy –orchestrator=kubernetes -c docker-compose.yml words
\nWaiting for the stack to be stable and running…
\ndb: Ready [pod status: 1\/1 ready, 0\/1 pending, 0\/1 failed]
\nweb: Ready [pod status: 1\/1 ready, 0\/1 pending, 0\/1 failed]
\nwords: Ready [pod status: 1\/3 ready, 2\/3 pending, 0\/3 failed]
\nStack words is stable and running<\/p>\n

We can then interact with those objects via the Kubernetes API. Here you can see we\u2019ve created the lower-level objects like Services, Pods, Deployments and ReplicaSets automatically:<\/p>\n

$ kubectl get all
\nNAME READY STATUS RESTARTS AGE
\npod\/db-85849797f6-bhpm8 1\/1 Running 0 57s
\npod\/web-7974f485b7-j7nvt 1\/1 Running 0 57s
\npod\/words-8fd6c974-44r4s 1\/1 Running 0 57s
\npod\/words-8fd6c974-7c59p 1\/1 Running 0 57s
\npod\/words-8fd6c974-zclh5 1\/1 Running 0 57s<\/p>\n

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
\nservice\/db ClusterIP None <none> 55555\/TCP 57s
\nservice\/kubernetes ClusterIP 10.96.0.1 <none> 443\/TCP 4d
\nservice\/web ClusterIP None <none> 55555\/TCP 57s
\nservice\/web-published LoadBalancer 10.102.236.49 localhost 33000:31910\/TCP 57s
\nservice\/words ClusterIP None <none> 55555\/TCP 57s<\/p>\n

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
\ndeployment.apps\/db 1 1 1 1 57s
\ndeployment.apps\/web 1 1 1 1 57s
\ndeployment.apps\/words 3 3 3 3 57s<\/p>\n

NAME DESIRED CURRENT READY AGE
\nreplicaset.apps\/db-85849797f6 1 1 1 57s
\nreplicaset.apps\/web-7974f485b7 1 1 1 57s
\nreplicaset.apps\/words-8fd6c974 3 3 3 57s<\/p>\n

It\u2019s important to note that this isn\u2019t a one-time conversion. The Compose on Kubernetes API Server introduces the Stack resource to the Kubernetes API. So we can query and manage everything at the same level of abstraction as we\u2019re building the application. That makes delving into the details above useful for understanding how things work, or debugging issues, but not required most of the time:<\/p>\n

$ kubectl get stack
\nNAME STATUS PUBLISHED PORTS PODS AGE
\nwords Running 33000 5\/5 4m<\/p>\n

Integration with other Kubernetes tools<\/b><\/h3>\n

Because Stack is now a native Kubernetes object, you can work with it using other Kubernetes tools. As an example, save the as `stack.yaml`:<\/p>\n

kind: Stack
\napiVersion: compose.docker.com\/v1beta2
\nmetadata:
\nname: hello
\nspec:
\nservices:
\n– name: hello
\nimage: garethr\/skaffold-example
\nports:
\n– mode: ingress
\ntarget: 5678
\npublished: 5678
\nprotocol: tcp<\/p>\n

You can use a tool like Skaffold<\/a> to have the image automatically rebuild and the Stack automatically redeployed whenever you change any of the details of your application. This makes for a great local inner-loop development experience. The following `skaffold.yaml` configuration file is all you need.<\/p>\n

apiVersion: skaffold\/v1alpha5
\nkind: Config
\nbuild:
\ntagPolicy:
\nsha256: {}
\nartifacts:
\n– image: garethr\/skaffold-example
\nlocal:
\nuseBuildkit: true
\ndeploy:
\nkubectl:
\nmanifests:
\n– stack.yaml<\/p>\n

The future<\/b><\/h3>\n

We already have some thoughts about a Helm plugin to make describing your application with Compose and deploying with Helm as easy as possible. We have lots of other ideas for helping to simplify the developer experience of working with Kubernetes too, without losing any of the power of the platform. We also want to work with the wider Cloud Native community, so if you have ideas and suggestions please let us know.<\/p>\n

Kubernetes is designed to be extended, and we hope you like what we\u2019ve been able to release today. If you\u2019re one of the millions of Compose users you can now more easily move to and manage your applications on Kubernetes. If you\u2019re a Kubernetes user struggling with too much low-level configuration then give Compose a try. Let us know in the comments what you think, and head over to GitHub to try things out and even open your first PR:<\/p>\n