<p>I watched a talk from Kelsey Hightower: <a href="https://www.youtube.com/watch?v=XPC-hFL-4lU">https://www.youtube.com/watch?v=XPC-hFL-4lU</a> regarding apps that could deploy itself. I decided to give it a shot.</p>
<p>TLDR;
Imagine you would, for whatever reason, download or somehow get a script that you would need to run in your cluster (ecs, kubernetes, swam, whatever), why should you have to learn how to deploy my program? What if the program could deploy itself?</p>
<p>This would be achieved by running ./binary-name --kubernetes</p>
<p>Feedback would be greatly appreciated.</p>
<p>code:
<a href="https://github.com/kasperbe/go-kubernetes-examples/tree/master/selfdeploying-app">https://github.com/kasperbe/go-kubernetes-examples/tree/master/selfdeploying-app</a></p>
<hr/>**评论：**<br/><br/>absdevops: <pre><p>I love it - though something I think would be a little more powerful would be a YAML file to list your namespace, context etc. Currently we store our kube manifests with our applications so its fairly easy to build and deploy as one.</p>
<p>In reality though, I think this process is pretty much covered by helm charts. All you need is the ability for your application to exec a helm command or write a helm plugin to build your project before deploying and you're good to go.</p>
<p>To one up that further - I've seen a scala project recently which can do everything from build to deploy in the build.sbt file</p>
<p>EDIT: I raised a PR to show my ideal structure of doing it</p></pre>kasperbe: <pre><p>Hey! Thanks for the reply.</p>
<p>I wondered if I should add the whole build to deploy thing, but that would imply that I would use this to build and deploy all of my services, which I don't think is a good idea. If it's my own service, it's easy enough for me to know how to deploy it as well.</p>
<p>The intention behind this was to easy it for people who don't know anything about my service.</p>
<p>Say you download a script to read logs from multiple pods into a single stream, normally you'd have to deploy that pod and run kubectl get pods... to see the output.</p>
<p>Instead you could do something like ./log-read --kubernetes pod1 pod2 and it just reads the logs of those pods until you terminate the program, and it cleans up after itself.</p>
<p>I have been thinking about maybe doing something like
--kubernetes -d to detach the process so your deploy servers can actually deploy it without knowing that kubernetes exists, the program just does it.</p>
<p>Let me know what you think! :-)</p></pre>winter_mutex: <pre><p>Hey, very cool idea. You may be interested in the new <a href="https://metaparticle.io" rel="nofollow">metaparticle</a> project announced at this week's kubecon. <a href="https://venturebeat.com/2017/12/06/kubernetes-cofounder-launches-programming-library-to-simplify-cloud-native-development/" rel="nofollow">more info</a>.</p></pre>kasperbe: <pre><p>Hey there!</p>
<p>This indeed does look interesting, thanks for sharing! :)</p></pre>
