-
Notifications
You must be signed in to change notification settings - Fork 83
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #165 from redspread/versioning
Versioning
- Loading branch information
Showing
99 changed files
with
12,858 additions
and
123 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -4,17 +4,17 @@ | |
|
|
||
| <p align="center"><a href="https://redspread.com">Website</a> | <a href="http://redspread.readme.io">Docs</a> | <a href="http://slackin.redspread.com/">Slack</a> | <a href="mailto:[email protected]">Email</a> | <a href="http://twitter.com/redspread">Twitter</a> | <a href="http://facebook.com/GetRedspread">Facebook</a></p> | ||
|
|
||
| #Spread: Docker to Kubernetes in one command | ||
| #Spread: Git for Kubernetes | ||
|
|
||
| `spread` is a command line tool that makes it easy to version Kubernetes objects (see: [Kit](https://github.com/redspread/kit)), set up a local Kubernetes cluster (see: [localkube](https://github.com/redspread/localkube)), and deploy to Kubernetes clusters in one command. The project's goals are to: | ||
| `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: | ||
|
|
||
| * Enable rapid iteration with Kubernetes | ||
| * Guarantee reproducible Kubernetes deployments | ||
| * Be the fastest, simplest way to deploy Docker to production | ||
| * Work well for a single developer or an entire team (no more broken bash scripts!) | ||
| * Enable collaborative deployment workflows that work well for one person or an entire team | ||
|
|
||
| See how we deployed Mattermost (<a href="https://github.com/redspread/kube-mattermost">and you can too!</a>): | ||
| See how we versioned the cluster running our (<a href="https://redspread.com">website</a>) (and you can too!): | ||
|
|
||
| <p align="center"><img src="http://i.imgur.com/Vohnd3e.gif" alt="logo" width= "800"/></p> | ||
| <p align="center"><img src="https://redspread.com/img/terminal.gif" alt="logo" width= "800"/></p> | ||
|
|
||
| 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. | ||
|
|
||
|
|
@@ -27,73 +27,84 @@ See our [philosophy](./philosophy.md) for more on our mission and values. | |
|
|
||
| ##Installation | ||
|
|
||
| Install with `go get`: | ||
| Install with `go get` (-d is for download only): | ||
|
|
||
| `go get rsprd.com/spread/cmd/spread` | ||
| `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` | ||
| `$ brew install spread-versioning` | ||
|
|
||
| ##Quickstart | ||
| ##Git for Kubernetes | ||
|
|
||
| Check out our <a href="https://redspread.readme.io/docs/getting-started">Getting Started Guide</a>. | ||
| 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. | ||
|
|
||
| ##Localkube | ||
| To get started, initialize Spread and set up a local Spread repository: | ||
|
|
||
| Spread makes it easy to set up and iterate with [localkube](https://github.com/redspread/localkube), a local Kubernetes cluster streamlined for rapid development. | ||
| `spread init` | ||
|
|
||
| **Requirements:** | ||
| * [Docker](https://docs.docker.com/engine/installation/) | ||
| * [docker-machine](https://docs.docker.com/machine/install-machine/) | ||
| * [VirtualBox](https://www.virtualbox.org/wiki/Downloads) | ||
| Here is our suggested workflow for versioning with Spread: | ||
|
|
||
| (Note: For Mac and Windows users, the fastest way to install everything above is [Docker Toolbox](https://www.docker.com/products/docker-toolbox).) | ||
| 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 <objectType>/<objectName>` | ||
| 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 <name> <url> | remove <name> | set-url <name> <url>)` | ||
| 7. Push your objects to your remote repository: `spread push <remote> <refSpec>` | ||
| 8. Go ahead and try out the other commands - anything not documented can be accessed using `spread git ...` | ||
|
|
||
| **Get started:** | ||
| If you find any bugs or have any feature requests for Spread versioning, please file an issue! | ||
|
|
||
| 1. Create a machine called dev: `docker-machine create --driver virtualbox dev` | ||
| 2. Start your docker-machine: `docker-machine start dev` | ||
| 3. Connect to the docker daemon: `eval "$(docker-machine env dev)"` | ||
| 4. Spin up a local cluster using [localkube](http://github.com/redspread/localkube): `spread cluster start` | ||
| 5. To stop the cluster: `spread cluster stop` | ||
| For more details on Spread commands, [see our docs](https://redspread.readme.io/docs/spread-commands). | ||
|
|
||
| **Suggested workflow:** | ||
| - `docker build` the image that you want to work with [1] | ||
| - Create Kubernetes objects that use the image build above | ||
| - Run `spread deploy .` to deploy to cluster [2] | ||
| - Iterate on your application, updating image and objects running `spread deploy .` each time you want to deploy changes | ||
| - To preview changes, grab the IP of your docker daemon with `docker-machine env <NAME>`and the returned `NodePort`, then put `IP:NodePort` in your browser | ||
| - When finished, run `spread cluster stop` to stop localkube | ||
| ##Spread Deploy Quickstart | ||
|
|
||
| [1] `spread` will soon integrate building ([#59](https://github.com/redspread/spread/issues/59)) | ||
| [2] Since `localkube` shares a Docker daemon with your host, there is no need to push images :) | ||
| Check out our <a href="https://redspread.readme.io/docs/getting-started">Getting Started Guide</a>. | ||
|
|
||
| ##Localkube --> Minikube | ||
|
|
||
| [See more](https://github.com/redspread/localkube) for our suggestions when developing code with `localkube`. | ||
| 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. | ||
| * Established an implicit hierarchy of Kubernetes objects | ||
| * Multi-container deployment | ||
| * Support for Linux and Windows | ||
| * [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 | ||
|
|
||
| * Version control for Kubernetes objects | ||
| * Template authoring | ||
| * Secret management with Spread versioning | ||
| * Inner-app linking | ||
| * [Redspread](redspread.com) (hosted Spread repository) | ||
|
|
||
| See more of our <a href="https://github.com/redspread/spread/blob/master/roadmap.md">roadmap</a> here! | ||
|
|
||
| ##Future Goals | ||
| * Peer-to-peer syncing between local and remote Kubernetes clusters | ||
| * Develop workflow for application and deployment versioning | ||
| * Introduce paramaterization for container configuration | ||
| * Automatically spin up local and remote Kubernetes clusters with minimal user input | ||
|
|
||
| ##FAQ | ||
|
|
||
|
|
@@ -118,6 +129,8 @@ 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 | ||
|
|
||
|
|
||
Oops, something went wrong.