Skip to content
This repository has been archived by the owner on Sep 15, 2022. It is now read-only.

Upgrade readme file #43

Merged
merged 3 commits into from
Oct 18, 2019
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
59 changes: 42 additions & 17 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,37 +10,46 @@ For more information, read the [Helm Broker documentation](https://kyma-project.

To run the project, download these tools:

* [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)
* [Helm CLI](https://github.com/kubernetes/helm#install)
* [Minikube](https://kubernetes.io/docs/tasks/tools/install-minikube/) for local installation
* [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) 1.16
* [Helm CLI](https://github.com/kubernetes/helm#install) 2.14
* [Docker](https://docs.docker.com/install/) 19.03 (for local installation)
* [Kind](https://github.com/kubernetes-sigs/kind#installation-and-usage) 0.5 (for local installation)

>**NOTE:** For non-local installation, use Kubernetes v1.15.

## Installation
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should somewhere describe that you can just execute the
./hack/run-dev-kind.sh which will execute all those steps for you. Now it is a piece of secret knowledge.

IMO here we can have just info about this script with prerequisite and in the directory where this ./hack/run-dev-kind.sh have details what is done under the hood and if someone wants to do it manually then can do it.


To run the Helm Broker, you need a Kubernetes cluster with Tiller and Service Catalog. Follow these steps to set up the Helm Broker on Minikube with all necessary dependencies:
To run the Helm Broker, you need a Kubernetes cluster with Tiller and Service Catalog. Follow these steps to set up the Helm Broker on Kind with all necessary dependencies:

1. Run the Minikube:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe we can just have a short script under the hack folder so user/developer will need to just execute
./hack/run-dev-kind.sh

this script can even automate that kind and helm will be downloaded for you if you will specify additional flag, we already have some helpers for that in /hack/ci dir.

so sth like:

./hack/run-dev-kind.sh --skip-deps-installation # such thing will resuse your own kind and helm
# or
./hack/run-dev-kind.sh --install-deps # such thing will install own kind and helm instead of reusing your own

I do not have strong preferences if skip or install is a better approach

WDYT?
because copying that each time is boring :(

1. Create a local cluster on Kind:
```bash
minikube start
kind create cluster
```

2. Install Tiller into your cluster:
```bash
helm init
kubectl create serviceaccount --namespace kube-system tiller
kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
helm init --service-account tiller --upgrade --wait
```

3. Install the Service Catalog as a Helm chart:
3. Install Service Catalog as a Helm chart:
```bash
helm repo add svc-cat https://svc-catalog-charts.storage.googleapis.com
helm install svc-cat/catalog --name catalog --namespace catalog
```

4. Install the Helm Broker chart:
4. Clone the Helm Broker repository:
```bash
helm install charts/helm-broker --name helm-broker --namespace helm-broker
git clone git@github.com:kyma-project/helm-broker.git
```
## Usage

5. Install the Helm Broker chart from the cloned repository:
```bash
helm install charts/helm-broker --name helm-broker --namespace helm-broker
```

## Usage

If you have installed the Helm Broker with the Service Catalog, you can add your addon repositories and provision ServiceInstances. Read [this](https://kyma-project.io/docs/master/components/helm-broker#details-create-addons-repository) document to learn how. You can find more ready-to-use addons [here](https://github.com/kyma-project/addons). Follow this example to configure the Helm Broker and provision the Redis instance:

Expand All @@ -49,7 +58,6 @@ If you have installed the Helm Broker with the Service Catalog, you can add your
kubectl apply -f hack/examples/sample-addons.yaml
```


After the Helm Broker processes the addons' configuration, you can see the Redis ClusterServiceClass:

```bash
Expand Down Expand Up @@ -116,22 +124,39 @@ Use the following environment variables to configure the Controller component of

To set up the project, download these tools:

* [Go](https://golang.org/dl/) 1.11.4
* [Dep](https://github.com/golang/dep) v0.5.0
* [Go](https://golang.org/dl/) 1.12
* [Dep](https://github.com/golang/dep) 0.5
* [Docker](https://www.docker.com/)

>**NOTE:** The versions of Go and Dep are compliant with the `buildpack` used by Prow. For more details, read [this](https://github.com/kyma-project/test-infra/blob/master/prow/images/buildpack-golang/README.md) document.

### Project structure

The repository has the following structure:

```
├── .github # Pull request and issue templates
├── charts # Charts to install by Helm
├── cmd # Main applications for project
├── config # Configuration file templates or default configurations
├── deploy # Dockerfiles to build images
├── docs # Documentation files
├── hack # Scripts used by the Helm Broker developers
├── internal # Private application and library code
├── pkg # Library code to use by external applications
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could you add also short readme to pkg, similar to this one: https://github.com/kyma-project/helm-broker/tree/master/hack

this folder is quite important and IMO is good to have a clear statement about its purpose

same thing for test folder, so it's dedicated for integrations/e2e etc. do not store there e.g. verify-gofmt.sh script, or sth similar because such thing should be placed under /hack dir.

└── test # Additional external test applications and test data
```

### Run tests

Before each commit, use the `before-commit.sh` script. The script runs unit tests that check your changes and build binaries. If you want to run the Helm Broker locally, read [this](/docs/run-local.md) document.

You can also run integration tests that check if all parts of the Helm Broker work together.
These are the prerequisites for integration tests:

- [Kubebuilder](https://github.com/kubernetes-sigs/kubebuilder)
- [Etcd](https://github.com/etcd-io/etcd/releases/tag/v3.4.0)
- [Minio](https://min.io/download)
- [Kubebuilder](https://github.com/kubernetes-sigs/kubebuilder) 1.0.8
- [Etcd](https://github.com/etcd-io/etcd#etcd) 3.4
- [Minio](https://min.io/download) RELEASE.2019-10-12T01-39-57Z

Run integration tests using this command:

Expand Down
106 changes: 106 additions & 0 deletions hack/run-dev-kind.sh
Original file line number Diff line number Diff line change
@@ -0,0 +1,106 @@
#!/usr/bin/env bash

set -o errexit

readonly SUPPORTED_KIND_VERSION="v0.5.1"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just require this specified in deps_ver.sh

readonly CURRENT_DIR=$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )
readonly REPO_ROOT_DIR=$( cd ${CURRENT_DIR}/../ && pwd )

readonly SC_NAMESPACE="catalog"
readonly SC_CHART_NAME="catalog"
readonly HB_NAMESPACE="helm-broker"
readonly HB_CHART_NAME="helm-broker"

source "${CURRENT_DIR}/ci/lib/utilities.sh" || { echo 'Cannot load CI utilities.'; exit 1; }
source "${CURRENT_DIR}/ci/lib/deps_ver.sh" || { echo 'Cannot load dependencies versions.'; exit 1; }

print_warning() {
echo -e "\033[33m $1 \033[39m"
}

print_error() {
echo -e "\033[31m $1 \033[39m"
}

print_done() {
echo -e "\033[32m $1 \033[39m"
}

kind::check_kind() {
if ! which kind >/dev/null; then
print_error "Kind is not installed on your host, install it and try again"
exit 1
fi

local version=$(kind version)
if [[ "${version}" != "${STABLE_KIND_VERSION}" ]]; then
print_warning "Your kind is in ${version}. Your version is not equal than the supported version of kind ${STABLE_KIND_VERSION}"
fi
}

helm::check_helm() {
if ! which helm >/dev/null; then
print_error "Helm is not installed on your host, install it and try again"
exit 1
fi
}

install::tiller() {
shout '- Installing Tiller...'
kubectl --namespace kube-system create sa tiller
kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
helm init --service-account tiller --upgrade --wait
}

tiller::assert_tiller_is_up() {
Copy link
Contributor

@mszostok mszostok Oct 17, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: this can be dropped because we already using the --wait flag during the init action

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer to leave it, if everything will be ok then it is only one iteration and we will be sure tiller is up.

LIMIT=15
COUNTER=0

while [ ${COUNTER} -lt ${LIMIT} ]; do
if [[ $(kubectl get deployment -n kube-system tiller-deploy -ojson | jq '.status.availableReplicas') == 1 ]];then
echo "Tiller is up"
return 0
else
print_warning "Tiller is not ready"
fi
(( COUNTER++ ))
echo -e "Tiller is not ready yet, retry (${COUNTER} attempt out of ${LIMIT})..."
sleep 1
done
}

install::service_catalog() {
shout '- Provisioning Service Catalog chart...'

helm repo add svc-cat https://svc-catalog-charts.storage.googleapis.com
helm install svc-cat/catalog --name ${SC_CHART_NAME} --namespace ${SC_NAMESPACE} --wait
}

install::helm_broker() {
shout '- Provisioning Helm Broker chart...'

helm install ${REPO_ROOT_DIR}/charts/helm-broker --name ${HB_CHART_NAME} --namespace ${HB_NAMESPACE} --wait
}

main() {
# check if docker is running; docker ps -q should only work if the daemon is ready
docker ps -q > /dev/null

# check if kind and helm exist and have proper supported version if required
kind::check_kind
helm::check_helm

export KUBERNETES_VERSION=${STABLE_KUBERNETES_VERSION}
kind::create_cluster

install::tiller
tiller::assert_tiller_is_up

install::service_catalog
install::helm_broker

print_done "Cluster creation complete. You can now use the cluster with:"
print_done "export KUBECONFIG=\"\$(kind get kubeconfig-path --name=\"${KIND_CLUSTER_NAME}\")\""
}

main
8 changes: 8 additions & 0 deletions pkg/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
# Pkg directory

Library code to use by external applications. Other projects will import these libraries expecting them to work.

## Purpose

The `/pkg` directory is a good way to explicitly communicate that the code in that directory is safe for use by others.
Note that the `/internal` directory is a better way to ensure your private packages.
7 changes: 7 additions & 0 deletions test/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
# Test directory

Additional external test applications and test data.

## Purpose

Dedicated for integrations/e2e tests. Do not store here any scripts for formatting code or tools for checking imports, consider `/hack` directory instead.