Stevedore a tool to load the cluster with containers for kubernetes to orchestrate. It is a wrapper on Helm, gets all the features of helm, defines a workflow through which helm charts can be deployed and managed. It offers,
- Declarative way to mange dependencies.
- Terraform style plan and apply to see what exactly going to change
- Ability to specify overrides for any given environment at ease
- Support storing of configurations multiple config store (Plugin support for custom stores)
TLDR; Kubernetes follows a declarative style of configuring infrastructure. Stevedore provides a way through which helm interactions can be done declarative through a YAML configuration.
git clone [email protected]:gojekfarm/stevedore.git
cd stevedore
make install ## Required to have go installed in the machine
stevedore --help ## Verify the installation
Example guide for installing 'redis' helm chart via the stevedore into minikube.
First, add the kubernetes cluster to stevedore context, in our case its minikube
$ stevedore config add-context \
--name minikube \
--environment local \
--environment-type dev \
--kube-context minikube \
--type local
Successfully added the below context:
Name minikube
Type local
Environment local
Environment Type dev
Kubernetes Context minikube
Successfully switched to context: minikubecreate a stevedore manifest file and save it as redis.yaml
kind: StevedoreManifest
version: 2
deployTo:
- contextName: minikube
environmentType: dev
spec:
- release:
name: redis
namespace: default
chart: stable/redis
values:
password: password$ stevedore plan -f redis.yamlstevedore will show the detailed plan on what are the resources which will be created
## partial output of plan command
Release changes:
RELEASE MANIFEST CHANGES
redis +ConfigMap/redis
(redis.yaml) +ConfigMap/redis-health
+Secret/redis
+Service/redis-headless
+Service/redis-master
+Service/redis-slave
+StatefulSet/redis-master
+StatefulSet/redis-slave
File changes:
FILENAME ADDITIONS MODIFICATIONS DESTRUCTIONS
redis.yaml 8 0 0plan will not modify the actual resources.
to use the output of the plan to apply command, specify the artifact folder via additional artifact path --artifact/-a stevedore plan -f redis.yaml -a out
to, install / update the changes
$ stevedore apply -f redis.yamlto install the / update the changes planned via plan command specify the files from the artifact directory
$ stevedore apply -f out/redis.yamlto proceed further and persist the changes, confirm the action
Context Details:
------------------
Name: minikube
Type: local
Environment: local
Kubernetes Context: minikube
Environment Type: dev
KubeConfig File:
------------------
Confirm to apply: [y/N]to auto apply specify --yes
Stevedore offers easy way to manage overrides for different environment.
consider the following requirements for four different environments (dev, test, integration and production) where redis will be installed.
- dev, test environment may not need persistent to be enabled.
kind: StevedoreOverride
version: 2
spec:
- matches:
environmentType: dev
values:
master:
persistence:
enabled: false
slave:
persistence:
enabled: false
- matches:
environmentType: test
values:
master:
persistence:
enabled: false
slave:
persistence:
enabled: false- integration environment resource request will be little higher than dev and test environment
kind: StevedoreOverride
version: 2
spec:
- matches:
environmentType: integration
values:
master:
resources:
requests:
memory: 256Mi
cpu: 100m
slave:
resources:
requests:
memory: 256Mi
cpu: 100m- production environment needs persistent to be enabled and has the highest value for resource quota
kind: StevedoreOverride
version: 2
spec:
- matches:
environmentType: production
values:
master:
resources:
requests:
memory: 1024Mi
cpu: 1000m
persistence:
enabled: false
slave:
resources:
requests:
memory: 1024Mi
cpu: 1000m
persistence:
enabled: falseto use the override feature, save these overrides as override.yaml and during plan and apply pass on the overrides
$ stevedore plan -f redis.yaml -o override.yaml
$ stevedore apply -f redis.yaml -o override.yamlSimilar to overrides, stevedore provides an easy way to manage environment, cluster specific overrides
to provide a different password for different environment templatize the password field as ${PASSWORD}
kind: StevedoreManifest
version: 2
deployTo:
- contextName: minikube
environmentType: dev
spec:
- release:
name: redis
namespace: default
chart: stable/redis
values:
password: ${REDIS_PASSWORD}now, you can define an environment file or export an environment variable for the stevedore to pick it up.
kind: StevedoreEnv
version: 2
spec:
- matches:
environmentType: dev
env:
REDIS_PASSWORD: dev
---
kind: StevedoreEnv
version: 2
spec:
- matches:
environmentType: test
env:
REDIS_PASSWORD: testStevedoreManifest use this to define the release manifest which is interpreted by the stevedore and perform install / upgrade
StevedoreEnv use this to define environment/context/cluster specific value (eg., database connection string, password, replica count etc.,)
StevedoreOverride use this to define overrides for an environment/context/cluster
goversion:1.14- Clone the repo to
$GOPATH/src/github.com/gojekfarm/stevedore - Run
make buildto build dependencies, format, vet, lint, test and compile - Run
make compileto compile for local development machine (usecompile-linuxto compile for linux os amd64 architecture) - Run
make installto install stevedore $GOPATH/bin
Logo designed by Kartik Narayanan checkout his various work here, you can reach out him at @hajaarfunda
Copyright 2018-2020, GO-JEK Tech (http://gojek.tech)
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.