Open jakefeasel opened 6 years ago
Hey @jakefeasel, can you flesh out the story? Ralph has a native app and wants to develop it using a container-native workflow....
?
For example: if you already have a dockerfile/chart, you can use draft and share your work with others by creating a custom draft pack repo, and then using that functionality to create new versions of that particular app type each time you start using draft create --pack=
.
Is that what you mean?
Ralph has learned about Kuberenetes and Helm and has rebuilt his service to run within that environment. Ralph has Dockerfiles and Helm charts and clusters running in production. Ralph is happy with the results.
Ralph's application developers need to be able to continue improving the service. They are smart people; they see the value of Kubernetes and are willing to try new things. They have become trained on Helm and run Minikube locally.
However, the developers do not like having to deal with the new overhead that Ralph has imposed on them each time they want to test a change they've made. When they write new code they now have to not only recompile whichever portion they are working on, they also have to rebuild the docker container, delete the current pod, wait for the new one to come up, and probably need to kill existing port-forward processes and restart them. This makes the developers angry at Ralph. They preferred the way things were before Kubernetes; changes were much easier to make then.
Ralph has heard about Draft. It seems to try to solve the problem his developers are facing. If he can find a way to incorporate Draft into his project, it will help Ralph convince his developers that this Kubernetes stuff actually makes their lives better.
Ralph needs documentation that describes how his developers can use Draft with his Helm / k8s project.
Ralph is clearly an a$$h@le. Implementation to follow.
Wonder if you have any update on document describing this case ?
We don't have anything specifically targeting the feedback in this issue. However, DEP 002 goes fairly in-depth on the general design principles we had in mind when first starting out! Let us know if there's something missing from that document.
Hi, @jakefeasel ! I successfully adapted an existing Helm chart to be used with Draft - until we have a full document on this, here's the TL;DR:
draft: {{ default "draft-app" .Values.draft }}
(example)annotations:
buildID: {{ .Values.buildID }}
This is a short version of what you need to do to transform your chart to work, and keep in mind that Draft will override your .Values.image.repository
and .Values.image.tag
found in values.yaml
with the repository and image name setup in Draft (config and draft.toml
) and with an auto-computed ID.
Leaving this open until we have a full document covering how to do this - let us know how this works out.
Thanks!
Current draft docs discuss how to use draft when starting a new project. Also, it is oriented around developers who do not know (and perhaps do not want to know) about Helm / k8s. As someone with an existing Helm / K8s project, I do still see the potential benefits of a project like draft but I don't see how I can use it.
For reference, one of the projects I would like to use with Draft is here: https://github.com/jakefeasel/sqlfiddle3
Thanks!