mfburnett

oof this is very unfortunate; we're also signed up for Azlo through Stripe Atlas

This University of Maryland student made this experimental organ using 49 back-driven stepper motors this summer - absolutely incredible

Probably the simplest/fastest setup guide I've seen to go from zero to a running Kubernetes cluster on OS X

And if anyone has any questions about using Spread with Gitlab CI to deploy to Kubernetes, let us know! (Redspread cofounder here.)

Thanks! :)

Fixed this issue with the message showing "waiting for load balancer" - now it returns the NodePort!

Thanks! What else would you want to see in a general use framework?

Very cool - thanks for sharing!

Yes so the "Waiting for load balancer deployment..." is a confusing message leftover from its original use for a remote cluster - we're fixing it asap, but it actually has already worked. Go ahead and get your Docker daemon IP and then grab the NodePort with `$ kubectl describe services/mattermost-app` and put in the IP:NodePort into your browser to see the Mattermost instance running.

The easiest way to install kubectl is actually to install gcloud first (https://cloud.google.com/sdk/#Quick_Start) and then install kubectl with `$ gcloud components update kubectl`

Thanks for bringing this up!

Love the Convox team! We're both trying to make deploying to our respective orchestrators (EC2 for Convox and Kubernetes for Redspread) easier.

Hey, thank you! We're building out "git for deployment" - starting with a series of commands to make it easy to deploy to and develop with Kubernetes, and working our way to application versioning (capturing and versioning the expected state of an application before it's deployed by an orchestrator, like Kubernetes). Then, we'll make money on the "Github" - collaborative deployment tools built on top of our versioning workflow.

Thank you! Yes, we're approaching it with a Unix philosophy :)

So backstory: first we went with "omnikube", but that name was already taken and caused some early and funny confusion (see our issue on local development). But monokube and hyperkube were already taken, so localkube was our compromise.

Of course - glad you think so! That's exactly why we built it.

Oh haven't seen this! Is it compatible with Kubernetes 1.2? Not a huge fan of scripting - we think it breaks the abstraction of a container.

Previous options were either figuring out how to set up hyperkube (which was kind of a pain) or monokube. Neither were set up for Kubernetes 1.2 or had good networking options!

Hey everyone, cofounder of Redspread (YC W16) here. We just shipped Localkube, local development with Kubernetes. You can set up a full configured Kubernetes 1.2 cluster on your local machine in one command with Spread, our command line tool. Localkube has everything you need for networking, and is a single executable, single container, and single process.

It's the easiest way we've seen to set up a Kubernetes cluster and get started immediately.

What benefits do you expect to see from query cost prediction?

Thank you! Definitely - we see a big need for collaborative deployment tools in this space.

And of course - happy to officially be part of the open source club :)

Definitely - making it easier to interface with Container Engine is a big reason why we built this workflow. Because we wanted to make our own lives easier developing with Kubernetes!

Hey - so right now it's easiest to set up a cluster on GCP. I wrote some simplified directions: https://blog.redspread.com/2016/02/04/google-container-engin...

We don't plan on getting into the hosting game but we have considered making it easy to set up a free temporary test cluster so people can play around with Spread. Would that be useful?

yes, rolling updates are definitely on our roadmap. right now everything is client side - we’re building a light kubernetes workflow - but web hooks are a great idea

Thanks for the support! :)

So right now it's best for two sets of users: 1) those who are looking to deploy Docker to production but don't have any orchestrator set up - Spread makes it really easy to use Kubernetes 2) those who have a remote Kubernetes cluster running, often develop with Kubernetes and want to quickly be able to deploy to that cluster

We're adding a bunch of functionality for building images, pushing to Docker registries, and offline dev with Kubernetes.

So we built Spread to be a workflow that improves on the usual `kubectl create -f ...` `kubectl describe services/example` experience by enabling rapid iteration with Kubernetes. Next on the roadmap is building the image and pushing it to a registry along with deploying to Kubernetes in one command. And it runs wherever Kubernetes runs - so you can use it beyond Google.

Hey! If this workflow we're building is the git for Docker deployment, we'll make money on the GitHub - collaborative deployment tools built on top of this workflow.

It works wherever you've set up a Kubernetes cluster! So as long as you have kubectl configured correctly, you're good to go.

Thank you! So I've also compiled a list of K8s resources we found to be the most helpful: https://blog.redspread.com/2016/01/05/most-useful-kubernetes...

For example, the Godocs for Kubernetes are always kept up-to-date and are great for jumping around structs.

Hey! Good question. So we're encouraging a .ctr file because we think container reusability will become really important, especially as more organizations share containers across teams.

We're playing around with this idea of embedding different kube objects and containers to construct applications across directories, so setting up directories with .ctr files will make the introduction of that feature pretty easy.

Hah yes - it's easy to spell, it rhymes so it's easy to remember, and we got the .com ;)