Refactor chart for 1.0, add tests, update TF (#2)

* Refactor chart for 1.0, add tests, update TF * Fix typo in helper comment * Add NOTES for post install instructions * Fix typo in NOTES * Fix replication port for enterprise * Change updateStrategy to OnDelete * Add icon * Remove cluster address from config * Update README, add contributing doc * Update README * Change HA replicas to 3
openbao · Jul 31, 2019 · b746991 · b746991
1 parent ca40087
commit b746991
Show file tree

Hide file tree

Showing 32 changed files with 1,940 additions and 825 deletions.
diff --git a/.gitignore b/.gitignore
@@ -4,3 +4,7 @@
 terraform.tfstate*
 terraform.tfvars
 values.dev.yaml
+vaul-helm-dev-creds.json
+./test/acceptance/vaul-helm-dev-creds.json
+./test/acceptance/values.yaml
+./test/acceptance/values.yml
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -0,0 +1,55 @@
+# Contributing to Vault Helm
+
+**Please note:** We take Vault's security and our users' trust very seriously.
+If you believe you have found a security issue in Vault, please responsibly
+disclose by contacting us at security@hashicorp.com.
+
+**First:** if you're unsure or afraid of _anything_, just ask or submit the
+issue or pull request anyways. You won't be yelled at for giving it your best
+effort. The worst that can happen is that you'll be politely asked to change
+something. We appreciate any sort of contributions, and don't want a wall of
+rules to get in the way of that. 
+
+That said, if you want to ensure that a pull request is likely to be merged,
+talk to us! You can find out our thoughts and ensure that your contribution
+won't clash or be obviated by Vault's normal direction. A great way to do this
+is via the [Vault Google Group][2]. Sometimes Vault devs are in `#vault-tool`
+on Freenode, too.
+
+This document will cover what we're looking for in terms of reporting issues.
+By addressing all the points we're looking for, it raises the chances we can
+quickly merge or address your contributions.
+
+## Issues
+
+### Reporting an Issue
+
+* Make sure you test against the latest released version. It is possible
+  we already fixed the bug you're experiencing. Even better is if you can test
+  against `master`, as bugs are fixed regularly but new versions are only
+  released every few months.
+
+* Provide steps to reproduce the issue, and if possible include the expected 
+  results as well as the actual results. Please provide text, not screen shots!
+
+* Respond as promptly as possible to any questions made by the Vault
+  team to your issue. Stale issues will be closed periodically.
+
+### Issue Lifecycle
+
+1. The issue is reported.
+
+2. The issue is verified and categorized by a Vault Helm collaborator.
+   Categorization is done via tags. For example, bugs are marked as "bugs".
+
+3. Unless it is critical, the issue may be left for a period of time (sometimes
+   many weeks), giving outside contributors -- maybe you!? -- a chance to
+   address the issue.
+
+4. The issue is addressed in a pull request or commit. The issue will be
+   referenced in the commit message so that the code that fixes it is clearly
+   linked.
+
+5. The issue is closed. Sometimes, valid issues will be closed to keep
+   the issue tracker clean. The issue is still indexed and available for
+   future viewers, or can be re-opened if necessary.
diff --git a/Chart.yaml b/Chart.yaml
@@ -3,6 +3,7 @@ name: vault
 version: 0.1.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
diff --git a/README.md b/README.md
@@ -1,17 +1,12 @@
 # Vault Helm Chart
 
-------
-## WIP - forked from vault-Helm and under heavy development
-------
-
 This repository contains the official HashiCorp Helm chart for installing
 and configuring Vault on Kubernetes. This chart supports multiple use
 cases of Vault on Kubernetes depending on the values provided.
 
-[//]: # (These docs don't exist yet)
-[//]: # (For full documentation on this Helm chart along with all the ways you can)
-[//]: # (use Vault with Kubernetes, please see the)
-[//]: # ([Vault and Kubernetes documentation](https://www.vault.io/docs/platform/k8s/index.html).)
+For full documentation on this Helm chart along with all the ways you can
+use Vault with Kubernetes, please see the
+[Vault and Kubernetes documentation](https://www.vaultproject.io/docs/platform/k8s/index.html).
 
 ## Prerequisites
 
@@ -38,18 +33,9 @@ then be installed directly:
 
     helm install ./vault-helm
 
-[//]: # (These docs don't exist yet)
-[//]: # (Please see the many options supported in the `values.yaml`)
-[//]: # (file. These are also fully documented directly on the)
-[//]: # ([Vault website](https://www.vault.io/docs/platform/k8s/helm.html).)
-
-### Using auto-unseal
-
-Starting with Vault 1.0-beta, auto-unseal features are now included in the open source 
-version on Vault.  In order to use these features, users must ensure that 
-the Vault configuration is provided with the appropriate credentials and authorizations 
-to access the APIs needed for the given key provider, as well as the necessary keys 
-created before hand. 
+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
 
@@ -58,9 +44,22 @@ 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`.
-Both require [Bats](https://github.com/bats-core/bats-core) and `helm` to be
-installed and available on the CLI. The unit tests also require the correct
-version of [yq](https://pypi.org/project/yq/) if running locally.
+
+### 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:
 
@@ -75,8 +74,119 @@ 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/ directory](https://github.com/hashicorp/vault-helm/tree/master/test/terraform)
+[`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.
diff --git a/templates/NOTES.txt b/templates/NOTES.txt
@@ -0,0 +1,14 @@
+
+Thank you for installing HashiCorp Vault!
+
+Now that you have deployed Vault, you should look over the docs on using 
+Vault with Kubernetes available here: 
+
+https://www.vaultproject.io/docs/
+
+
+Your release is named {{ .Release.Name }}. To learn more about the release, try:
+
+  $ helm status {{ .Release.Name }}
+  $ helm get {{ .Release.Name }}
+