This is my quick feedback for recently announced Draft, kubernetes development tool.
The purpose of this article is to capture and share my first hot impressions , observations and define a place of the tool in kubernetes landscape.
Architecture
The tool consists from command line client and agent running on k8s cluster. Architecture is similar to helm but this where the difference begins.
Client responsibilities: app folder init, continuous build and registry update.
Agent responsibilities: helm package deployments and release lifecycle management.
Installing
The procedure is straightforward and requires no deep infrastructure knowledge, I will not cover it.
Just a couple surprises which can be easily fixed:
I had to create dockerhub organization since draft don’t work with default user.
Currenly not all steps are automated even if you deploy to cloud. I had to manualy create wildcard DNS alias to ingress controller, for example:
*.draft.lab.mydomain.com A ALIAS myingress_lb_name
User workflow
- A developer navigate to the root of the application repository.
- Runs draft create detects an application type using pluggable packs.
- $draft up start watching project folder for changes.
- Write code.
- On any change draft triggers pipeline: docker image build -> helm chart package -> docker image push to registry -> Ziro downtime helm chart deploy to kubernetes -> application updated.
The workflow is intended as pre VCS commit for development purposes, however, user can extend and build more advanced pipelines using this tool.
Pack is a prototype of your future build/deploy package and contains Dockerfile, default helm chart specific to application type. Draft application autodect functionality depends on it.
Impression
Considering growing popularity of Helm, it was expected to find that draft is built on top of it, actually, user experience is very similar. Very UNIX way, one small tool makes one task… Lightweigh , written in Golang.
The tool implements battle tested heroku workflow and uses community recognized such as docker, kubernetes and helm.
Simplest way to setup end to end delivery pipeline for the app. Basicaly, user gets most of OpenShift PaaS functionality minus security and visual aspects.
Developer 100% in controls application build and deploy automation.
Pluggable packs allow easy extension.
Very optimistic about future of this tool and believe it can become defacto standard build&deploy suite as yum or apt for linux systems.
Happy Sailing!
Other reading: