Spring is here, as well as Draft v0.12.0! 🌷
This release introduces one of the most significant architectural changes to Draft since its inception. Draft v0.12.0 introduces a purely client-side interaction model, departing from the traditional client/server model Draft is known for. Read more about it below!
Along with the re-architecture, we've added pack support for Rust, new commands like draft history, and big improvements to draft up, draft logs and draft connect!
Because there are several very large changes to Draft this release (including how applications are bootstrapped using draft create), it is best to start from complete scratch. In order to upgrade, you will need to delete the now-departed draftd from your cluster with helm delete --purge draft, delete your local Draft configuration via rm -rf ~/.draft, grab and unpack one of the clients provided and re-run draft init according to the installation guide.
See the CHANGELOG for more information on what changed in this release.
We would love for you to be part of our community! 💜 Come join the discussion in Kubernetes Slack: #draft-users.
Install Draft
Installation for Draft can be done either with brew install draft (for Mac users) or by grabbing a release binary for their OS of choice.
draft history
draft history is a new command for Draft v0.12.0. In a nutshell, it displays the build history of an application pushed to a Kubernetes cluster via draft up. It's a very useful command to view past builds, which can then be further processed by draft logs.
Under the covers, the underlying storage infrastructure powering draft history has enabled use cases like the recent enhancements to draft logs, draft connect and draft up --auto-connect, which will now connect and fetch the logs from the most recent release if no arguments are provided.
draft connect enhancements
Ever since we released draft connect in v0.7.0, we've been gathering feedback from community members on how they're using Draft, their use cases and feature requests. Some of the main feature requests around draft connect have been:
- an option to specify local ports instead of random ports - one use case was for front-end developers running server-side applications remotely on Kubernetes and developing the front-end application locally - they needed a specific local port in order to use it with a tool that offers live reloading
- the ability to configure
draft connectindraft.toml - connect to a sidecar container in your pod and specify port mapping for the connection
- an option to automatically connect after re-deploying the application
With Draft v0.12.0, users can specify local ports using draft connect -p <local>:<remote> or by adding an override-ports config in draft.toml, allowing the use of live reload tools. Auto connecting to your deployment is done by simply passing --auto-connect to draft up or by adding the auto-connect = true field in draft.toml.
Connecting to a specific container is done using draft connect -c <target-container>, opening the possibility to connect to sidecar containers and even attach remote debuggers!
You can find more information about configuring draft connect in the documentation.
Draft re-architecture
Draft was originally designed around a client/server architecture: Draft and Draftd. Draft would package and ship uploads to Draftd, while Draftd lived inside the Kubernetes cluster, building Docker images, pushing to container registries and deploying to Kubernetes using Helm.
After playing around with the idea of switching to a client-only architecture, we discovered several clear wins:
- Draft gains support to deploy to any distribution of Kubernetes
draft init(and therefore the setup process) has been vastly simplified- Users can now push and pull images from any container registry during the build stage by calling
docker login - RBAC/TLS configuration between draft, draftd, tiller and the container registry has been greatly simplified
- Alternative container builder runtimes like buildah or img can be provided without bloating the system setup
With this new architecture in place, we're seeing significant performance gains, and users trying out Draft in the Cloud can use their cloud infrastructure's familiar toolkit to interact with their infrastructure like az acr login. We even heard from one user that with this shift in design, they are able to get Draft deploying their applications to a GKE cluster with a 3rd party (gitlab based) private registry!
On the performance side, internal testing with the example applications are showing a dev cycle clocking in around 2 seconds to re-build and deploy changes to an application on Minikube. Comparing to the previous release's ~18 second best case scenario, this is a MASSIVE performance gain. 💥
><> vim main.go
><> draft up
Draft Up Started: 'example-go'
example-go: Building Docker Image: SUCCESS ⚓ (2.0005s)
example-go: Releasing Application: SUCCESS ⚓ (0.0642s)
example-go: Build ID: 01C9MTW8P5D0XRWY27CR9QDSMA
Inspect the logs with `draft logs 01C9MTW8P5D0XRWY27CR9QDSMA`
We're super excited to hear your feedback on all these new changes! Please give us feedback, issues or comments on Slack and the issue queue.
What's Next?
Draft v0.13.0 development is now underway. Our big goals for v0.13.0 continue to focus on more features around building applications for Kubernetes.
Feeling interested in contributing? Come join the discussion in Kubernetes Slack: #draft-dev!