Skip to content

Commit

Permalink
Update to 0.3.0 (#154)
Browse files Browse the repository at this point in the history
  • Loading branch information
jasonodonnell committed Dec 19, 2019
1 parent 16bb899 commit 7d8ae7d
Show file tree
Hide file tree
Showing 4 changed files with 8 additions and 157 deletions.
6 changes: 5 additions & 1 deletion CHANGELOG.md
Original file line number Diff line number Diff line change
@@ -1,5 +1,7 @@
## Unreleased

## 0.3.0 (December 19th, 2019)

Features:

* Extra containers can now be added to the Vault pods
Expand All @@ -10,7 +12,9 @@ Improvements:

* Moved `global.image` to `server.image`
* Changed UI service template to route pods that aren't ready via `publishNotReadyAddresses: true`
* Added better HTTP/HTTPS scheme support to http probes.
* Added better HTTP/HTTPS scheme support to http probes
* Added configurable node port for Vault service
* `server.authDelegator` is now enabled by default

Bugs:

Expand Down
3 changes: 2 additions & 1 deletion Chart.yaml
Original file line number Diff line number Diff line change
@@ -1,9 +1,10 @@
apiVersion: v1
name: vault
version: 0.2.1
version: 0.3.0
description: Install and configure Vault on Kubernetes.
home: https://www.vaultproject.io
icon: https://github.com/hashicorp/vault/raw/f22d202cde2018f9455dec755118a9b84586e082/Vault_PrimaryLogo_Black.png
sources:
- https://github.com/hashicorp/vault
- https://github.com/hashicorp/vault-helm
- https://github.com/hashicorp/vault-k8s
154 changes: 0 additions & 154 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -36,157 +36,3 @@ then be installed directly:
Please see the many options supported in the `values.yaml`
file. These are also fully documented directly on the
[Vault website](https://www.vaultproject.io/docs/platform/k8s/helm.html).

## Testing

The Helm chart ships with both unit and acceptance tests.

The unit tests don't require any active Kubernetes cluster and complete
very quickly. These should be used for fast feedback during development.
The acceptance tests require a Kubernetes cluster with a configured `kubectl`.

### Prequisites
* [Bats](https://github.com/bats-core/bats-core)
```bash
brew install bats-core
```
* [yq](https://pypi.org/project/yq/)
```bash
brew install python-yq
```
* [helm](https://helm.sh)
```bash
brew install kubernetes-helm
```

### Running The Tests

To run the unit tests:

bats ./test/unit

To run the acceptance tests:

bats ./test/acceptance

If the acceptance tests fail, deployed resources in the Kubernetes cluster
may not be properly cleaned up. We recommend recycling the Kubernetes cluster to
start from a clean slate.

**Note:** There is a Terraform configuration in the
[`test/terraform/`](https://github.com/hashicorp/vault-helm/tree/master/test/terraform) directory
that can be used to quickly bring up a GKE cluster and configure
`kubectl` and `helm` locally. This can be used to quickly spin up a test
cluster for acceptance tests. Unit tests _do not_ require a running Kubernetes
cluster.

### Writing Unit Tests

Changes to the Helm chart should be accompanied by appropriate unit tests.

#### Formatting

- Put tests in the test file in the same order as the variables appear in the `values.yaml`.
- Start tests for a chart value with a header that says what is being tested, like this:
```
#--------------------------------------------------------------------
# annotations
```

- Name the test based on what it's testing in the following format (this will be its first line):
```
@test "<section being tested>: <short description of the test case>" {
```

When adding tests to an existing file, the first section will be the same as the other tests in the file.

#### Test Details

[Bats](https://github.com/bats-core/bats-core) provides a way to run commands in a shell and inspect the output in an automated way.
In all of the tests in this repo, the base command being run is [helm template](https://docs.helm.sh/helm/#helm-template) which turns the templated files into straight yaml output.
In this way, we're able to test that the various conditionals in the templates render as we would expect.

Each test defines the files that should be rendered using the `-x` flag, then it might adjust chart values by adding `--set` flags as well.
The output from this `helm template` command is then piped to [yq](https://pypi.org/project/yq/).
`yq` allows us to pull out just the information we're interested in, either by referencing its position in the yaml file directly or giving information about it (like its length).
The `-r` flag can be used with `yq` to return a raw string instead of a quoted one which is especially useful when looking for an exact match.

The test passes or fails based on the conditional at the end that is in square brackets, which is a comparison of our expected value and the output of `helm template` piped to `yq`.

The `| tee /dev/stderr ` pieces direct any terminal output of the `helm template` and `yq` commands to stderr so that it doesn't interfere with `bats`.

#### Test Examples

Here are some examples of common test patterns:

- Check that a value is disabled by default

```
@test "ui/Service: no type by default" {
cd `chart_dir`
local actual=$(helm template \
-x templates/ui-service.yaml \
. | tee /dev/stderr |
yq -r '.spec.type' | tee /dev/stderr)
[ "${actual}" = "null" ]
}
```

In this example, nothing is changed from the default templates (no `--set` flags), then we use `yq` to retrieve the value we're checking, `.spec.type`.
This output is then compared against our expected value (`null` in this case) in the assertion `[ "${actual}" = "null" ]`.


- Check that a template value is rendered to a specific value
```
@test "ui/Service: specified type" {
cd `chart_dir`
local actual=$(helm template \
-x templates/ui-service.yaml \
--set 'ui.serviceType=LoadBalancer' \
. | tee /dev/stderr |
yq -r '.spec.type' | tee /dev/stderr)
[ "${actual}" = "LoadBalancer" ]
}
```

This is very similar to the last example, except we've changed a default value with the `--set` flag and correspondingly changed the expected value.

- Check that a template value contains several values
```
@test "server/standalone-StatefulSet: custom resources" {
cd `chart_dir`
local actual=$(helm template \
-x templates/server-statefulset.yaml \
--set 'server.standalone.enabled=true' \
--set 'server.resources.requests.memory=256Mi' \
--set 'server.resources.requests.cpu=250m' \
. | tee /dev/stderr |
yq -r '.spec.template.spec.containers[0].resources.requests.memory' | tee /dev/stderr)
[ "${actual}" = "256Mi" ]
local actual=$(helm template \
-x templates/server-statefulset.yaml \
--set 'server.standalone.enabled=true' \
--set 'server.resources.limits.memory=256Mi' \
--set 'server.resources.limits.cpu=250m' \
. | tee /dev/stderr |
yq -r '.spec.template.spec.containers[0].resources.limits.memory' | tee /dev/stderr)
[ "${actual}" = "256Mi" ]
```

*Note:* If testing more than two conditions, it would be good to separate the `helm template` part of the command from the `yq` sections to reduce redundant work.

- Check that an entire template file is not rendered
```
@test "syncCatalog/Deployment: disabled by default" {
cd `chart_dir`
local actual=$(helm template \
-x templates/server-statefulset.yaml \
--set 'global.enabled=false' \
. | tee /dev/stderr |
yq 'length > 0' | tee /dev/stderr)
[ "${actual}" = "false" ]
}
```
Here we are check the length of the command output to see if the anything is rendered.
This style can easily be switched to check that a file is rendered instead.
2 changes: 1 addition & 1 deletion values.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -72,7 +72,7 @@ server:

image:
repository: "vault"
tag: 1.3.1
tag: "1.3.1"
# Overrides the default Image Pull Policy
pullPolicy: IfNotPresent

Expand Down

0 comments on commit 7d8ae7d

Please sign in to comment.