Use Helm to generate an updated index.yaml file by passing in the directory path and the url of the remote repository to the `helm repo index` command like this:
```console
```bash
$ helm repo index fantastic-charts/ --url https://fantastic-charts.storage.googleapis.com
```
This will generate an updated index.yaml file and place in the `fantastic-charts/` directory.
@ -27,7 +27,7 @@ This will generate an updated index.yaml file and place in the `fantastic-charts
Upload the contents of the directory to your GCS bucket by running `scripts/sync-repo.sh` and pass in the local directory name and the GCS bucket name.
@ -51,7 +51,7 @@ Congratulations your remote chart repository now matches the contents of fantast
You'll want to keep a local copy of the contents of your chart repository or use `gsutil rsync` to copy the contents of your remote chart repository to a local directory.
For example:
```console
```bash
$ gsutil rsync -d -n gs://bucket-name local-dir/ # the -n flag does a dry run
For this guide, we'll create a simple chart called `mychart`, and then we'll
create some templates inside of the chart.
```console
```bash
$ helm create mychart
Creating mychart
```
@ -57,7 +57,7 @@ already there.
And what we're going to do is... _remove them all!_ That way we can work through our tutorial from scratch. We'll actually create our own `NOTES.txt` and `_helpers.tpl` as we go.
```console
```bash
$ rm -rf mychart/templates/*.*
```
@ -95,7 +95,7 @@ When Tiller reads this template, it will simply send it to Kubernetes as-is.
With this simple template, we now have an installable chart. And we can install
it like this:
```console
```bash
$ helm install ./mychart
NAME: full-coral
LAST DEPLOYED: Tue Nov 1 17:36:01 2016
@ -111,7 +111,7 @@ mychart-configmap 1 1m
In the output above, we can see that our ConfigMap was created. Using Helm, we
can retrieve the release and see the actual template that was loaded.
```console
```bash
$ helm get manifest full-coral
---
@ -169,7 +169,7 @@ The `Release` object is one of the built-in objects for Helm, and we'll cover it
Now when we install our resource, we'll immediately see the result of using this template directive:
```console
```bash
$ helm install ./mychart
NAME: clunky-serval
LAST DEPLOYED: Tue Nov 1 17:45:37 2016
@ -189,7 +189,7 @@ You can run `helm get manifest clunky-serval` to see the entire generated YAML.
At this point, we've seen templates at their most basic: YAML files that have template directives embedded in `{{` and `}}`. In the next part, we'll take a deeper look into templates. But before moving on, there's one quick trick that can make building templates faster: When you want to test the template rendering, but not actually install anything, you can use `helm install --debug --dry-run ./mychart`. This will send the chart to the Tiller server, which will render the templates. But instead of installing the chart, it will return the rendered template to you so you can see the output:
Because `favoriteDrink` is set in the default `values.yaml` file to `coffee`, that's the value displayed in the template. We can easily override that by adding a `--set` flag in our call to `helm install`:
@ -33,7 +33,7 @@ plugins do the "detail work" of performing a desired action.
Plugins are installed using the `$ helm plugin install <path|url>` command. You can pass in a path to a plugin on your local file system or a url of a remote VCS repo. The `helm plugin install` command clones or copies the plugin at the path/url given into `$ (helm home)/plugins`
In the example above, we gave Tiller admin access to the entire cluster. You are not at all required to give Tiller cluster-admin access for it to work. Instead of specifying a ClusterRole or a ClusterRoleBinding, you can specify a Role and RoleBinding to limit Tiller's scope to a particular namespace.
Nguyen Hai Truong
7 years ago