Be notified of new releases
Create your free GitHub account today to subscribe to this repository for new releases and build software alongside 31 million developers.Sign up
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 logs and
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!
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 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
Under the covers, the underlying storage infrastructure powering
draft history has enabled use cases like the recent enhancements to
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
- 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
draft up or by adding the
auto-connect = true field in
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 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
- 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.
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: