Hey everyone, cofounders of Redspread here, Mackenzie and Dan. We built Spread, our open source command line tool to build and deploy Docker to Kubernetes in one command, to enable rapid iteration with Kubernetes and provide the easiest way to deploy Docker to prod.

Our mission is to enable people to own their own deployment processes and infrastructure, and we're very passionate about that (see our philosophy.md).

Would love your angry bug reports, feature requests, and feedback!

rolling updates to services would be nice. running this as a service (possibly deployed on the kubernetes cluster) to facilitate this via web hooks would be amazing.

Excuse the self promotion, but if you're interested also check out a UI Docker/K8s deployment tool my team open-sourced earlier in the week. It's opinionated, but it might meet some of your needs:

https://makers.airware.com/open-source/vili/

This looks pretty cool, if this does zero down time rolling redeploys from a webhook then this is what I am looking for.

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

'Redspread' is a very interesting name, is there a story behind it?

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

Could you tell me the difference between Spread and [Helm](https://github.com/helm/helm)? What is the advantage of using spread over helm?

Hey! Helm is a package manager like Homebrew or npm while we see ourselves as a versioned workflow similar to git

Great to see such a great tool for deployments. Will you be adding support for managing multiple containers in a single deployment and scaling deployments up/down?

Hey thank you! So right now Spread supports deploying multiple containers in a single deployment. We want to let Kubernetes be Kubernetes as much as possible, so scaling deployments up/down (I assume autoscaling is what you meant!) is actually coming out in 1.2 - with a release date of March 7!

This is awesome. We run a Kubernetes stack on AWS and it's a headache managing our YAML object files. Excited to see where this project goes!

Thanks for the support! :)

How is this any different than what google provides out of the box? I build a cluster and just deploy a container to a pod.

For an argument on why you should build custom workflows on top of Kubernetes instead of using it directly, and how easy that is to do, see http://blog.jonparrott.com/building-a-paas-on-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.

This is cool - We are using Convox to manage an ECS cluster at the moment, but Kubernetes/Container Engine seems to be the better system overall. Container Engine is very complex though (like ECS), so a tool which makes it easier to work with would make it much more practical for us to move over.

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!

Do you have recommendations for another tool to set up a Kubernetes cluster in the first place? At first glance, it seems somewhat complex and easy to misconfigure.

Or is that something you plan to support in redspread as well?

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?

Thanks, it would be. We run on AWS so the ease of setting up on GCE doesn't really matter beyond the experimentation phase.

If it doesn't already exist, a multi-machine Vagrant setup would probably be helpful too.

Nice work!

Kubernetes is a really neat and important piece of tech, but there's so much more tooling needed to make a team productive around it.

Thanks for building awesome tooling and making it open source!

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 :)

Why would I want to have a ctr file separate from my pod or rc?

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.

This is platform agnostic, correct? I can use AWS or DO, right?

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

Can I use this to go from my docker-compose setup on a single machine straight to kubernetes on multiple?

Is there any extra state stored somewhere outside my Kubernetes cluster to manage this workflow?

Not yet but it will be introduced once we release versioning.

So what exactly is Kubernetes?

Hey! Very simply, Kubernetes puts containers on servers. It takes care of a lot of logic around scheduling, networking, health checks (i.e. what happens if a pod goes down).

I wrote a blog post that breaks down basic Kube architecture, if you're interested: https://blog.redspread.com/2015/12/31/basic-kubernetes-vocab...

A little history - it's an open source project by Google, modeled after Google's infrastructure (Borg/Omega). Many of the engineers who designed Borg/Omega are chief architects of Kubernetes.

Blog post on Kube vocab is really clear and simple.. any other suggestions how to learn/read more?

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.

What will the tool set that this tool fits frictionlessly into look like?

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.

What is your monetization strategy for this? (being open source)

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.

cool to see this open source - readme talks about versioning; is that like deployment versioning for kube objects? how is that different than what's coming out in 1.2?

So in 1.2, Deployment API facilitates the transition from state to state for an RC or a pod. This provides a basic form of revision history, but isn't "versioning" - it's more if you could only go back one step.

For us, we see the big use case for full deployment versioning when there are multiple kube objects and config files to track. Already this is introducing some complication into developer workflows - ex: I have a bunch of services, rc's, and secrets. They are parameterized by this configuration. Now I've updated the configuration. I want to propagate that configuration to my cluster "with no downtime” - right now there isn't an easy way to do this.

Congrats on the launch! Why the choice to build on Kubernetes?

Hey thanks! So we evaluated a bunch of different orchestrator options when we were first thinking about Redspread, and Kubernetes was opinionated in a way we liked the best. Google's been running containers in production for a decade now, so a lot of their learnings and best practices are baked into Kube. This article does a pretty good job of laying out the pros/cons of different orchestrators: http://code.haleby.se/2016/02/12/why-we-chose-kubernetes/