Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/redspread/spread

Docker to Kubernetes in one command
https://github.com/redspread/spread

Last synced: about 1 month ago
JSON representation

Docker to Kubernetes in one command

Awesome Lists containing this project

README 

        
logo



Build Status Release Hex.pm GoDoc Status



Website | Docs | Slack | Email | Twitter | Facebook



#Spread: Git for Kubernetes



`spread` is a command line tool that makes it easy to version Kubernetes clusters, deploy to Kubernetes clusters in one command, and set up a local Kubernetes cluster (see: [localkube](https://github.com/redspread/localkube)). The project's goals are to:



* Guarantee reproducible Kubernetes deployments

* Be the fastest, simplest way to deploy Docker to production

* Enable collaborative deployment workflows that work well for one person or an entire team



See how we versioned the cluster running our (website) (and you can too!):



logo



Spread is under open, active development. New features will be added regularly over the next few months - explore our [roadmap](./roadmap.md) to see what will be built next and send us pull requests for any features you’d like to see added.



See our [philosophy](./philosophy.md) for more on our mission and values. 



##Requirements

* Running Kubernetes cluster (remote or local)

* [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)

* [Go](https://golang.org/doc/install) (v 1.6)



##Installation



Install with `go get` (-d is for download only):



`go get -d rsprd.com/spread/cmd/spread`



Go into the correct directory:



`cd $GOPATH/src/rsprd.com/spread`



If libgit2 is not installed:



`make install-libgit2`



Then:



`make build/spread`



If an error about libraries missing comes up, set up your library path like:



`export LD_LIBRARY_PATH=/usr/local/lib:$ LD_LIBRARY_PATH`



Or, if you prefer using Homebrew (OS X only): 



`$ brew tap redspread/spread`  

`$ brew install spread-versioning`



##Git for Kubernetes



Spread versions your software environment (i.e. a Kubernetes cluster) like Git versions source code. Because Spread is built on top of libgit2, it takes advantage of Git's interface and functionality. This means after you deploy a Kubernetes object to a cluster, you can version the object by staging, commiting, and pushing it to a Spread repository. 



To get started, initialize Spread and set up a local Spread repository:



`spread init`



Here is our suggested workflow for versioning with Spread:



1. Create or edit your Kubernetes objects

2. Deploy your objects to a local or remote Kubernetes cluster (make sure you've [set up your directory](https://github.com/redspread/spread/tree/versioning#faq) correctly): `spread deploy .`

3. Stage an object: `spread add /`

4. Repeat until all objects have been staged

5. Commit your objects with a message: `spread commit -m "commit message"`

6. Set up your remote repository: `spread remote (add   | remove  | set-url  )`

7. Push your objects to your remote repository: `spread push  `

8. Go ahead and try out the other commands - anything not documented can be accessed using `spread git ...`



If you find any bugs or have any feature requests for Spread versioning, please file an issue!



For more details on Spread commands, [see our docs](https://redspread.readme.io/docs/spread-commands).



##Spread Deploy Quickstart



Check out our Getting Started Guide.



##Localkube --> Minikube



Spread made it easy to set up and iterate with [Localkube](https://github.com/redspread/localkube), a local Kubernetes cluster streamlined for rapid development. We have donated Localkube code to [Minikube](https://github.com/kubernetes/minikube), the official Kubernetes local development solution. It's easy to set up a local cluster with Minikube: https://github.com/kubernetes/minikube.



##What's been done so far

 

* Spread versioning

* `spread deploy [-s] PATH [kubectl context]`: Deploys a Docker project to a Kubernetes cluster. It completes the following order of operations:

	* Reads context of directory and builds Kubernetes deployment hierarchy.

	* Updates all Kubernetes objects on a Kubernetes cluster.

	* Returns a public IP address, if type Load Balancer is specified. 

* [localkube](https://github.com/redspread/localkube): easy-to-setup local Kubernetes cluster for rapid development

* [Initial tutorial](https://redspread.readme.io/v0.1.6/docs/spread-templating-and-tutorials) for templating and parameterization



##What's being worked on now



* Template authoring

* Secret management with Spread versioning

* Inner-app linking

* [Redspread](redspread.com) (hosted Spread repository)



See more of our roadmap here!



##Future Goals

* Peer-to-peer syncing between local and remote Kubernetes clusters

* Automatically spin up local and remote Kubernetes clusters with minimal user input



##FAQ



**How are clusters selected?** Remote clusters are selected from the current kubectl context. Later, we will add functionality to explicitly state kubectl arguments. 



**How should I set up my directory?** In order to take advantage of Spread's one-command deploy feature, `spread deploy`, you'll need to set up your directory with a few specific naming conventions:



* All `ReplicationController` and `Pod` files should go in the root directory

* Any `ReplicationController` files should end in `.rc.yaml` or `.rc.json`, depending on the respective file extension

* Any `Pod` files should end in `.pod.yaml` or `.pod.json`, depending on the respective file extension

* All other Kubernetes object files should go in a directory named `rs`



There is no limit to the number of `ReplicationController`s or `Pod`s in the root directory.



Here is an example directory with Spread's naming conventions:



```Dockerfile

app.rc.yaml

database.rc.yaml

rs

 |_

    service.yaml

    secret.yaml

 ```

 

 **Why version objects instead of just files?** The object is the deterministic representation of state in Kubernetes. A useful analogy is "Kubernetes objects" are to "Docker images" like "Kubernetes object files" are to "Dockerfiles". By versioning the object itself, we can guarantee a 1:1 mapping with the Kubernetes cluster. This allows us to do things like diff two clusters and introduces future potential for linking between objects and repositories. 



##Contributing



We'd love to see your contributions - please see the CONTRIBUTING file for guidelines on how to contribute.



##Reporting bugs

If you haven't already, it's worth going through Elika Etemad's guide for good bug reporting. In one sentence, good bug reports should be both *reproducible* and *specific*.



##Contact

Team: [email protected]   

Slack: slackin.redspread.com  

Planning: Roadmap  

Bugs: Issues



##License

Spread is under the [Apache 2.0 license](https://tldrlegal.com/license/apache-license-2.0-(apache-2.0)). See the LICENSE file for details.