This repository serves as an entry point for Onedata continuous deployment pipeline. It's meant to be used by automatic task runners of continuous integration systems as well as individual developers in their daily routine.
Used for deploying particular configuration of a chosen helm chart in a given namespace on a Kubernetes cluster. Please refer to run.sh -h
for a detailed documentation.
Note: originally I planned to use landscaper, but at the time of development it lacked compatibility with the newest helm version. Hence the name. Instead, the landscape is realised just by invoking
helm install -f <config file>...
.
A landscape is a named set of files
landscape.yaml
containing configuration for a helm chartdeploy.sh
a script that contains the deployment procedure for a chart, specifying its repository, name, and version.tmuxp.yaml
an optional tmuxp configuration used to easily connect a deployed helm release. Includes integration with iTerm.
Docker composes with an entry-point which realises a deployment using a container that includes needed versions of git, kubectl, helm etc.
Typically developer wants to deploy a release with customized docker images, the example command that realizes it (uses a convenient flag --prefix
) using a develop landscape:
./run.sh --debug --landscape develop --ns develop --rn develop --tmuxp --prefix docker.onedata.org/ --op oneprovider:ID-795e3f2827 --oc oneclient:ID-f5cd39a89c --oz onezone:ID-df63ec7ae2 --cli rest-cli:ID-07f1c50d9e
On rare occasion, developer might want to customise the release even further. To do that please copy the landscapes/develop landscape directory to landscapes/random_custom_name. In the copied directory modify the landscape.yaml file to customise the deployment process. Next run the same command as above, but replace --landscape develop
with --landscape random_custom_name
.
By default, the charts are downloaded from the Onedata chart repository located at onedata/charts on a gh-pages
branch. In order to modify and test new charts, in the same way, they will be used by the users or automated tasks, one needs:
- to clone the onedata/charts repository and use the
--helm-local-charts-dir <path to cloned chart repo>
flag to allow helm in docker-compose to discover local charts, - change the chart name in
deploy.sh
, from eg. onedata/onedata-3p to onedata-3, that way to deployment will use a local/onedata-3p chart instead of downloading it from the onedata/charts repo.
Virtually the same use case as in Onedata developer, Tthe only extra requirement is the kubectl
configuration which custom location can be passed with --kube-config
flag.
Example command used by our continuous deployment task:
run.sh --kube-config "$KUBE_CONFIG" --ns "$NAMESPACE" --rn "$RELEASE_NAME" --op "$OP_IMAGE" --oc "$OC_IMAGE" --oz "$OZ_IMAGE" --cli "$CLI_IMAGE" --landscape develop --debug
For the sake of automation of performing common tasks on a complex deployment we use tmux, tmuxp with optional iTerm integration support.
When running run.sh
you can supply a --tmuxp
flag that will, in turn, generate a file with a name:
tmuxp.<landscape>.<namespace>.<release name>.<flags>.sh
you can use this script to attach to a deployed release. The script sources a file utils/run_tmuxp.sh
and must be placed in the root fo this repository.
By default the name includes all possible flags cidk
, where:
- c stands for configuring kubectl context by creating a context corresponding to a release parameters and setting this context as default.
- k stands for, if the tmux session exists with the conflicting name, kill it
- d add detach flag to tmuxp command, prevents automatic attach to tmux
- i stands for, attach to the tmux session using iTerm integration.
Similarly to the method above, this script allows you to attach to a deployed release using tmux. This time, the release parameters can be supplied as flags and the script can be used either from the root of this repository or by placing symbolic link to in somewhere in your $PATH
. See -h
for a more detailed description of possible flags.