Skip to content
Snippets Groups Projects
Unverified Commit ec3d0670 authored by Tirumarai Selvan's avatar Tirumarai Selvan Committed by GitHub
Browse files

Update README.md

parent b82c3359
No related branches found
No related tags found
No related merge requests found
...@@ -56,31 +56,15 @@ kubectl --namespace kube-system expose deployment gitkubed --type=LoadBalancer - ...@@ -56,31 +56,15 @@ kubectl --namespace kube-system expose deployment gitkubed --type=LoadBalancer -
gitkube install gitkube install
``` ```
#### Example ## Workflow
Follow this [example](https://github.com/hasura/gitkube-example) repo for a typical workflow of gitkube.
## How it works
Gitkube has three components:
1. Remote: Custom resource defined by a K8s CRD
2. gitkube-controller: Controller that manages Remote objects and propogates changes to gitkubed
3. gitkubed: Git host that builds docker image from the repo and rolls out deployment
### High-level architecture
![Architecture](https://raw.githubusercontent.com/hasura/gitkube/master/artifacts/gitkube-v0.1.png)
### Workflow
- Local dev: User creates a base git repo for the application with Dockerfile and K8s deployment - Local dev: User creates a base git repo for the application with Dockerfile and K8s deployment
- Setting Remote: User defines a spec for Remote containing the rules for `git push` - Setting Remote: User defines a spec for Remote containing the rules for `git push`
- Deploying application: Once a Remote is setup, application can be deployed to K8s using `git push <remote> master` - Deploying application: Once a Remote is setup, application can be deployed to K8s using `git push <remote> master`
#### Local dev ### Local dev
User should have a git repo with source code and a Dockerfile. User should also create a base K8s deployment for the application. User should have a git repo with source code and a Dockerfile. User should also create a base K8s deployment for the application.
#### Setting Remote ### Setting Remote
A Remote resource consists of 3 parts: A Remote resource consists of 3 parts:
1. authorizedKeys: List of ssh-keys for authorizing `git push`. 1. authorizedKeys: List of ssh-keys for authorizing `git push`.
...@@ -115,7 +99,7 @@ spec: ...@@ -115,7 +99,7 @@ spec:
dockerfile: example/www/Dockerfile # Location of Dockerfile for the source code dockerfile: example/www/Dockerfile # Location of Dockerfile for the source code
``` ```
#### Deploying application ### Deploying application
Once a Remote is created, it gets a git remote URL which you can find in its `status` spec Once a Remote is created, it gets a git remote URL which you can find in its `status` spec
...@@ -139,12 +123,21 @@ And finally, `git push` ...@@ -139,12 +123,21 @@ And finally, `git push`
$ git push sampleremote master $ git push sampleremote master
``` ```
## Roadmap ### More examples
Follow this [example](https://github.com/hasura/gitkube-example) repo for more workflows with gitkube.
## How it works
Gitkube has three components:
1. Remote: Custom resource defined by a K8s CRD
2. gitkube-controller: Controller that manages Remote objects and propogates changes to gitkubed
3. gitkubed: Git host that builds docker image from the repo and rolls out deployment
Gitkube is open to evolution. Some of the features to be added in future include: ### High-level architecture
![Architecture](https://raw.githubusercontent.com/hasura/gitkube/master/artifacts/gitkube-v0.1.png)
- Allowing all apps (daemonset, statefulset) to be deployed using `git push`. Current support is limited to deployments. [#19](https://github.com/hasura/gitkube/issues/19)
- Allowing different git hooks to be integrated [#20](https://github.com/hasura/gitkube/issues/20)
## Contributing ## Contributing
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please to comment