f.StringVar(&i.serviceAccount,"service-account","","name of service account")
f.IntVar(&i.maxHistory,"history-max",0,"limit the maximum number of revisions saved per release. Use 0 for no limit.")
f.StringVar(&i.opts.NodeSelectors,"node-selectors","","labels to specify the node on which Tiller is installed (app=tiller,helm=rocks)")
f.VarP(&i.opts.Output,"output","o","skip installation and output Tiller's manifest in specified format (json or yaml)")
f.StringArrayVar(&i.opts.Values,"override",[]string{},"override values for the Tiller Deployment manifest (can specify multiple or separate values with commas: key1=val1,key2=val2)")
returncmd
}
@ -161,31 +168,66 @@ func (i *initCmd) run() error {
expect:"NAME \tVERSION\tDESCRIPTION \ntesting/mariadb\t0.3.0 \tChart for MariaDB",
expect:"NAME \tCHART VERSION\tAPP VERSION\tDESCRIPTION \ntesting/mariadb\t0.3.0 \t \tChart for MariaDB",
},
{
name:"search for 'alpine', expect two matches",
args:[]string{"alpine"},
expect:"NAME \tVERSION\tDESCRIPTION \ntesting/alpine\t0.2.0 \tDeploy a basic Alpine Linux pod",
expect:"NAME \tCHART VERSION\tAPP VERSION\tDESCRIPTION \ntesting/alpine\t0.2.0 \t2.3.4 \tDeploy a basic Alpine Linux pod",
},
{
name:"search for 'alpine' with versions, expect three matches",
args:[]string{"alpine"},
flags:[]string{"--versions"},
expect:"NAME \tVERSION\tDESCRIPTION \ntesting/alpine\t0.2.0 \tDeploy a basic Alpine Linux pod\ntesting/alpine\t0.1.0 \tDeploy a basic Alpine Linux pod",
expect:"NAME \tCHART VERSION\tAPP VERSION\tDESCRIPTION \ntesting/alpine\t0.2.0 \t2.3.4 \tDeploy a basic Alpine Linux pod\ntesting/alpine\t0.1.0 \t1.2.3 \tDeploy a basic Alpine Linux pod",
},
{
name:"search for 'alpine' with version constraint, expect one match with version 0.1.0",
args:[]string{"alpine"},
flags:[]string{"--version",">= 0.1, < 0.2"},
expect:"NAME \tCHART VERSION\tAPP VERSION\tDESCRIPTION \ntesting/alpine\t0.1.0 \t1.2.3 \tDeploy a basic Alpine Linux pod",
},
{
name:"search for 'alpine' with version constraint, expect one match with version 0.1.0",
expect:"NAME \tCHART VERSION\tAPP VERSION\tDESCRIPTION \ntesting/alpine\t0.2.0 \t2.3.4 \tDeploy a basic Alpine Linux pod\ntesting/alpine\t0.1.0 \t1.2.3 \tDeploy a basic Alpine Linux pod",
f.StringArrayVar(&t.values,"set",[]string{},"set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)")
f.StringVar(&t.nameTemplate,"name-template","","specify template used to name the release")
f.StringVar(&t.kubeVersion,"kube-version","","override the Kubernetes version used as Capabilities.KubeVersion.Major/Minor (e.g. 1.7)")
f.StringVar(&t.outputDir,"output-dir","","writes the executed templates to files in output-dir instead of stdout")
Similarly, Kubernetes defaults the `imagePullPolicy` to `IfNotPresent` if it is not defined at all. If you want a value other than `IfNotPresent`, simply update the value in `values.yaml` to your desired value.
## PodTemplates Should Declare Selectors
All PodTemplate sections should specify a selector. For example:
This part of the Best Practices Guide discusses the creation and formatting of RBAC resources in chart manifests.
RBAC resources are:
- ServiceAccount (namespaced)
- Role (namespaced)
- ClusterRole
- RoleBinding (namespaced)
- ClusterRoleBinding
## RBAC-related values
RBAC-related values in a chart should be namespaced under an `rbac` top-level key. At a minimum this key should contain these sub-keys (explained below):
- `create`
- `serviceAccountName`
Other keys under `rbac` may also be listed and used as well.
## RBAC Resources Should be Created by Default
`rbac.create` should be a boolean value controlling whether RBAC resources are created. The default should be `true`. Users who wish to manage RBAC access controls themselves can set this value to `false` (in which case see below).
## Using RBAC Resources
`rbac.serviceAccountName` should set the name of the ServiceAccount to be used by access-controlled resources created by the chart. If `rbac.create` is true, then a ServiceAccount with this name should be created. If `rbac.create` is false, then it should not be created, but it should still be associated with the same resources so that manually-created RBAC resources created later that reference it will function correctly. (Note that this effectively makes `rbac.serviceAccountName` a required value in these charts.)
It is highly recommended that new charts are created via `helm create` command as the template names are automatically defined as per this best practice.
@ -7,6 +7,7 @@ Helm provides access to files through the `.Files` object. Before we get going w
- It is okay to add extra files to your Helm chart. These files will be bundled and sent to Tiller. Be careful, though. Charts must be smaller than 1M because of the storage limitations of Kubernetes objects.
- Some files cannot be accessed through the `.Files` object, usually for security reasons.
- Files in `templates/` cannot be accessed.
- Files excluded using `.helmignore` cannot be accessed.
- Charts do not preserve UNIX mode information, so file-level permissions will have no impact on the availability of a file when it comes to the `.Files` object.
<!-- (see https://github.com/jonschlinkert/markdown-toc) -->
@ -27,7 +27,7 @@ In the previous section, we use `{{.Release.Name}}` to insert the name of a rele
- `Capabilities.TillerVersion` provides a way to look up the Tiller version. It has the following values: `SemVer`, `GitCommit`, and `GitTreeState`.
- `Template`: Contains information about the current template that is being executed
- `Name`: A namespaced filepath to the current template (e.g. `mychart/templates/mytemplate.yaml`)
- `BasePath`: The namespaced path to the templates directory of the current chart (e.g. `mychart/templates`). This can be used to [include template files](https://github.com/kubernetes/helm/blob/master/docs/charts_tips_and_tricks.md#automatically-roll-deployments-when-configmaps-or-secrets-change)
- `BasePath`: The namespaced path to the templates directory of the current chart (e.g. `mychart/templates`).
The values are available to any top-level template. As we will see later, this does not necessarily mean that they will be available _everywhere_.
Variables are not "global". They are scoped to the block in which they are declared. Earlier, we assigned `$relname` in the top level of the template. That variable will be in scope for the entire template. But in our last example, `$key` and `$val` will only be in scope inside of the `{{range...}}{{end}}` block.
Variables are normally not "global". They are scoped to the block in which they are declared. Earlier, we assigned `$relname` in the top level of the template. That variable will be in scope for the entire template. But in our last example, `$key` and `$val` will only be in scope inside of the `{{range...}}{{end}}` block.
However, there is one variable that is always global - `$` - this
variable will always point to the root context. This can be very
useful when you are looping in a range need to know the chart's release
name.
An example illustrating this:
```yaml
{{- range .Values.tlsSecrets }}
apiVersion: v1
kind: Secret
metadata:
name: {{ .name }}
labels:
# Many helm templates would use `.` below, but that will not work,
# however `$` will work here
app: {{ template "fullname" $ }}
# I cannot reference .Chart.Name, but I can do $.Chart.Name
chart: "{{ $.Chart.Name }}-{{ $.Chart.Version }}"
release: "{{ $.Release.Name }}"
heritage: "{{ $.Release.Service }}"
type: kubernetes.io/tls
data:
tls.crt: {{ .certificate }}
tls.key: {{ .key }}
---
{{- end }}
```
So far we have looked at just one template declared in just one file. But one of the powerful features of the Helm template language is its ability to declare multiple templates and use them together. We'll turn to that in the next section.
@ -18,11 +18,11 @@ We also added two special template functions: `include` and `required`. The `inc
function allows you to bring in another template, and then pass the results to other
template functions.
For example, this template snippet includes a template called `mytpl.tpl`, then
For example, this template snippet includes a template called `mytpl`, then
lowercases the result, then wraps that in double quotes.
```yaml
value: {{include "mytpl.tpl" . | lower | quote}}
value: {{include "mytpl" . | lower | quote}}
```
The `required` function allows you to declare a particular
@ -96,6 +96,35 @@ For example:
The above will render the template when .Values.foo is defined, but will fail
to render and exit when .Values.foo is undefined.
## Creating Image Pull Secrets
Image pull secrets are essentially a combination of _registry_, _username_, and _password_. You may need them in an application you are deploying, but to create them requires running _base64_ a couple of times. We can write a helper template to compose the Docker configuration file for use as the Secret's payload. Here is an example:
First, assume that the credentials are defined in the `values.yaml` file like so:
@ -37,21 +37,22 @@ To check the generated manifests of a release without installing the chart,
the '--debug' and '--dry-run' flags can be combined. This will still require a
round-trip to the Tiller server.
If --verify is set, the chart MUST have a provenance file, and the provenenace
fall MUST pass all verification steps.
If --verify is set, the chart MUST have a provenance file, and the provenance
file MUST pass all verification steps.
There are four different ways you can express the chart you want to install:
There are five different ways you can express the chart you want to install:
1. By chart reference: helm install stable/mariadb
2. By path to a packaged chart: helm install ./nginx-1.2.3.tgz
3. By path to an unpacked chart directory: helm install ./nginx
4. By absolute URL: helm install https://example.com/charts/nginx-1.2.3.tgz
5. By chart reference and repo url: helm install --repo https://example.com/charts/ nginx
CHART REFERENCES
A chart reference is a convenient way of reference a chart in a chart repository.
When you use a chart reference ('stable/mariadb'), Helm will look in the local
When you use a chart reference with a repo prefix ('stable/mariadb'), Helm will look in the local
configuration for a chart repository named 'stable', and will then look for a
chart in that repository whose name is 'mariadb'. It will install the latest
version of that chart unless you also supply a version number with the
@ -70,7 +71,8 @@ helm install [CHART]
```
--ca-file string verify certificates of HTTPS-enabled servers using this CA bundle
--cert-file string identify HTTPS client using this SSL certificate file
--devel use development versions, too. Equivalent to version '>0.0.0-a'. If --version is set, this is ignored.
--dep-up run helm dependency update before installing the chart
--devel use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored.
--dry-run simulate an install
--key-file string identify HTTPS client using this SSL key file
--keyring string location of public keys used for verification (default "~/.gnupg/pubring.gpg")
@ -87,7 +89,7 @@ helm install [CHART]
--tls-cert string path to TLS certificate file (default "$HELM_HOME/cert.pem")
--tls-key string path to TLS key file (default "$HELM_HOME/key.pem")
--tls-verify enable TLS for request and verify remote
-f, --values valueFiles specify values in a YAML file (can specify multiple) (default [])
-f, --values valueFiles specify values in a YAML file or a URL(can specify multiple) (default [])
--verify verify the package before installing it
--version string specify the exact chart version to install. If this is not specified, the latest version is installed
--wait if set, will wait until all Pods, PVCs, Services, and minimum number of Pods of a Deployment are in a ready state before marking the release as successful. It will wait for as long as --timeout
@ -97,13 +99,14 @@ helm install [CHART]
```
--debug enable verbose output
--home string location of your Helm config. Overrides $HELM_HOME (default "$HOME/.helm")
--home string location of your Helm config. Overrides $HELM_HOME (default "~/.helm")
--host string address of Tiller. Overrides $HELM_HOST
--kube-context string name of the kubeconfig context to use
--kubeconfig string path to kubeconfig file. Overrides $KUBECONFIG
--tiller-namespace string namespace of Tiller (default "kube-system")
```
### SEE ALSO
* [helm](helm.md) - The Helm package manager for Kubernetes.
###### Auto generated by spf13/cobra on 15-Aug-2017
###### Auto generated by spf13/cobra on 23-Nov-2017
Ryan Payton
8 years ago