public_git
/
helmfile
mirror of https://github.com/helmfile/helmfile.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Correct minor spelling and grammar issues in README.md (#385)

This commit is contained in:
Sam Weston 2018-10-23 07:21:00 +01:00 committed by KUOKA Yusuke
parent 5ad916003f
commit bfc86de92d
1 changed files with 21 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
README.md
View File

@ -24,7 +24,7 @@ To avoid upgrades for each iteration of `helm`, the `helmfile` executable delega
## configuration syntax ## configuration syntax
**CAUTION**: This documentation is for the development version of helmfile. If you are looking for the documentation for any of releases, please switch to the corresponding release tag like [v0.31.0](https://github.com/roboll/helmfile/tree/v0.31.0). **CAUTION**: This documentation is for the development version of Helmfile. If you are looking for the documentation for any of releases, please switch to the corresponding release tag like [v0.31.0](https://github.com/roboll/helmfile/tree/v0.31.0).
The default helmfile is `helmfile.yaml`: The default helmfile is `helmfile.yaml`:
@ -39,7 +39,7 @@ repositories:
context: kube-context # kube-context (--kube-context) context: kube-context # kube-context (--kube-context)
#default values to set for args along with dedicated keys that can be set by contributers, cli args take precedence overe these #default values to set for args along with dedicated keys that can be set by contributers, cli args take precedence over these
helmDefaults: helmDefaults:
tillerNamespace: tiller-namespace #dedicated default key for tiller-namespace tillerNamespace: tiller-namespace #dedicated default key for tiller-namespace
kubeContext: kube-context #dedicated default key for kube-context kubeContext: kube-context #dedicated default key for kube-context
@ -238,15 +238,15 @@ please look at their [documentation](https://github.com/databus23/helm-diff#helm
### apply ### apply
The `helmfile apply` sub-command begins by executing `diff`. If `diff` finds that there is any changes, `sync` is executed. Adding `--interactive` instructs helmfile to request your confirmation before `sync`. The `helmfile apply` sub-command begins by executing `diff`. If `diff` finds that there is any changes, `sync` is executed. Adding `--interactive` instructs Helmfile to request your confirmation before `sync`.
An expected use-case of `apply` is to schedule it to run periodically, so that you can auto-fix skews between the desired and the current state of your apps running on Kubernetes clusters. An expected use-case of `apply` is to schedule it to run periodically, so that you can auto-fix skews between the desired and the current state of your apps running on Kubernetes clusters.
### delete ### delete
The `helmfile delete` sub-command deletes all the releases defined in the manfiests. The `helmfile delete` sub-command deletes all the releases defined in the manifests.
`helmfile --interactive delete` instructs helmfile to request your confirmation before actually deleting releases. `helmfile --interactive delete` instructs Helmfile to request your confirmation before actually deleting releases.
Note that `delete` doesn't purge releases. So `helmfile delete && helmfile sync` results in sync failed due to that releases names are not deleted but preserved for future references. If you really want to remove releases for reuse, add `--purge` flag to run it like `helmfile delete --purge`. Note that `delete` doesn't purge releases. So `helmfile delete && helmfile sync` results in sync failed due to that releases names are not deleted but preserved for future references. If you really want to remove releases for reuse, add `--purge` flag to run it like `helmfile delete --purge`.
@ -274,13 +274,13 @@ Using manifest files in conjunction with command line argument can be a bit conf
A few rules to clear up this ambiguity: A few rules to clear up this ambiguity:
- Absolute paths are always resolved as absolute paths - Absolute paths are always resolved as absolute paths
- Relative paths referenced *in* the helmfile manifest itself are relative to that manifest - Relative paths referenced *in* the Helmfile manifest itself are relative to that manifest
- Relative paths referenced on the command line are relative to the current working directory the user is in - Relative paths referenced on the command line are relative to the current working directory the user is in
For additional context, take a look at [paths examples](PATHS.md) For additional context, take a look at [paths examples](PATHS.md)
## Labels Overview ## Labels Overview
A selector can be used to only target a subset of releases when running helmfile. This is useful for large helmfiles with releases that are logically grouped together. A selector can be used to only target a subset of releases when running Helmfile. This is useful for large helmfiles with releases that are logically grouped together.
Labels are simple key value pairs that are an optional field of the release spec. When selecting by label, the search can be inverted. `tier!=backend` would match all releases that do NOT have the `tier: backend` label. `tier=fronted` would only match releases with the `tier: frontend` label. Labels are simple key value pairs that are an optional field of the release spec. When selecting by label, the search can be inverted. `tier!=backend` would match all releases that do NOT have the `tier: backend` label. `tier=fronted` would only match releases with the `tier: frontend` label.
@ -301,7 +301,7 @@ In addition to built-in ones, the following custom template functions are availa
- `readFile` reads the specified local file and generate a golang string - `readFile` reads the specified local file and generate a golang string
- `fromYaml` reads a golang string and generates a map - `fromYaml` reads a golang string and generates a map
- `setValuleAtPath PATH NEW_VALUE` traverses a golang map, replaces the value at the PATH with NEW_VALUE - `setValueAtPath PATH NEW_VALUE` traverses a golang map, replaces the value at the PATH with NEW_VALUE
- `toYaml` marshals a map into a string - `toYaml` marshals a map into a string
### Values Files Templates ### Values Files Templates
@ -316,7 +316,7 @@ releases
- values.yaml.gotmpl - values.yaml.gotmpl
``` ```
Every values file whose file extension is `.gotmpl` is considered as a tempalte file. Every values file whose file extension is `.gotmpl` is considered as a template file.
Suppose `values.yaml.gotmpl` was something like: Suppose `values.yaml.gotmpl` was something like:
@ -486,15 +486,15 @@ releases:
Environment Secrets are encrypted versions of `Environment Values`. Environment Secrets are encrypted versions of `Environment Values`.
You can list any number of `secrets.yaml` files created using `helm secrets` or `sops`, so that You can list any number of `secrets.yaml` files created using `helm secrets` or `sops`, so that
helmfile could automatically decrypt and merge the secrets into the environment values. Helmfile could automatically decrypt and merge the secrets into the environment values.
Suppose you have environment secrets defined in `hemlfile.yaml`: Suppose you have environment secrets defined in `helmfile.yaml`:
```yaml ```yaml
environments: environments:
production: production:
secrets: secrets:
- environments/produdction/secrets.yaml - environments/production/secrets.yaml
releases: releases:
- name: myapp - name: myapp
@ -538,7 +538,7 @@ All the yaml files under the specified directory are processed in the alphabetic
In case you want more control over how multiple `helmfile.yaml` files are organized, use `helmfiles:` configuration key in the `helmfile.yaml`: In case you want more control over how multiple `helmfile.yaml` files are organized, use `helmfiles:` configuration key in the `helmfile.yaml`:
Suppose you have multiple microservices organized in a Git reposistory that looks like: Suppose you have multiple microservices organized in a Git repository that looks like:
- `myteam/` (sometimes it is equivalent to a k8s ns, that is `kube-system` for `clusterops` team) - `myteam/` (sometimes it is equivalent to a k8s ns, that is `kube-system` for `clusterops` team)
- `apps/` - `apps/`
@ -566,7 +566,7 @@ for d in apps/*; do helmfile -f $d diff; if [ $? -eq 2 ]; then helmfile -f $d sy
At this point, you'll start writing a `Makefile` under `myteam/` so that `make sync-all` will do the job. At this point, you'll start writing a `Makefile` under `myteam/` so that `make sync-all` will do the job.
It does work, but you can rely on the helmfile's feature instead. It does work, but you can rely on the Helmfile feature instead.
Put `myteam/helmfile.yaml` that looks like: Put `myteam/helmfile.yaml` that looks like:
@ -603,13 +603,13 @@ The possibility is endless. Try importing values from your golang app, bash scri
## Hooks ## Hooks
A helmfile hook is a per-release extension point that is composed of: A Helmfile hook is a per-release extension point that is composed of:
- `events` - `events`
- `command` - `command`
- `args` - `args`
helmfile triggers various `events` while it is running. Helmfile triggers various `events` while it is running.
Once `events` are triggered, associated `hooks` are executed, by running the `command` with `args`. Once `events` are triggered, associated `hooks` are executed, by running the `command` with `args`.
Currently supported `events` are: Currently supported `events` are:
@ -617,7 +617,7 @@ Currently supported `events` are:
- `prepare` - `prepare`
- `cleanup` - `cleanup`
Hooks associated to `prepare` events are triggered after each release in your helmfile is loaded from YAML, before executed. Hooks associated to `prepare` events are triggered after each release in your helmfile is loaded from YAML, before execution.
Hooks associated to `cleanup` events are triggered after each release is processed. Hooks associated to `cleanup` events are triggered after each release is processed.
@ -662,7 +662,7 @@ Do you prefer `kustomize` to write and organize your Kubernetes apps, but still
like rollback, history, and so on? This section is for you! like rollback, history, and so on? This section is for you!
The combination of `hooks` and [helmify-kustomize](https://gist.github.com/mumoshu/f9d0bd98e0eb77f636f79fc2fb130690) The combination of `hooks` and [helmify-kustomize](https://gist.github.com/mumoshu/f9d0bd98e0eb77f636f79fc2fb130690)
enables you to integrate [kustomize](https://github.com/kubernetes-sigs/kustomize) into helmfle. enables you to integrate [kustomize](https://github.com/kubernetes-sigs/kustomize) into Helmfile.
That is, you can use `kustommize` to build a local helm chart from a kustomize overlay. That is, you can use `kustommize` to build a local helm chart from a kustomize overlay.
@ -707,14 +707,14 @@ Voilà! You can mix helm releases that are backed by remote charts, local charts
## Guides ## Guides
Use the [Helmfile Best Practices Guide](/docs/writing-helmfile.md) to write advanced helmfiles that features: Use the [Helmfile Best Practices Guide](/docs/writing-helmfile.md) to write advanced helmfiles that feature:
- Default values - Default values
- Layering - Layering
## Using env files ## Using env files
helmfile itself doesn't have an ability to load env files. But you can write some bash script to achieve the goal: Helmfile itself doesn't have an ability to load env files. But you can write some bash script to achieve the goal:
```console ```console
set -a; . .env; set +a; helmfile sync set -a; . .env; set +a; helmfile sync
@ -730,7 +730,7 @@ Use it when you're running `helmfile` manually on your local machine or a kind o
For your local use-case, aliasing it like `alias hi='helmfile --interactive'` would be convenient. For your local use-case, aliasing it like `alias hi='helmfile --interactive'` would be convenient.
## Running helmfile without an Internet connection ## Running Helmfile without an Internet connection
Once you download all required charts into your machine, you can run `helmfile charts` to deploy your apps. Once you download all required charts into your machine, you can run `helmfile charts` to deploy your apps.
It basically run only `helm upgrade --install` with your already-downloaded charts, hence no Internet connection is required. It basically run only `helm upgrade --install` with your already-downloaded charts, hence no Internet connection is required.