Modifying the highlight syntax in markdown file

Using `bash` instead of `console` in script section of
markdown file.

Signed-off-by: Nguyen Hai Truong <truongnh@vn.fujitsu.com>
pull/5331/head
Nguyen Hai Truong 7 years ago
parent 73a17eb599
commit 06fdc39384

@ -109,7 +109,7 @@ generated: 2016-10-06T16:23:20.499029981-06:00
A generated index and packages can be served from a basic webserver. You can test A generated index and packages can be served from a basic webserver. You can test
things out locally with the `helm serve` command, which starts a local server. things out locally with the `helm serve` command, which starts a local server.
```console ```bash
$ helm serve --repo-path ./charts $ helm serve --repo-path ./charts
Regenerating index. This may take a moment. Regenerating index. This may take a moment.
Now serving you on 127.0.0.1:8879 Now serving you on 127.0.0.1:8879
@ -196,7 +196,7 @@ We'll take the second approach, though the first is just as easy.
The first step will be to **create your gh-pages branch**. You can do that The first step will be to **create your gh-pages branch**. You can do that
locally as. locally as.
```console ```bash
$ git checkout -b gh-pages $ git checkout -b gh-pages
``` ```
@ -257,7 +257,7 @@ repository.
Once you have a packaged chart ready, create a new directory, and move your Once you have a packaged chart ready, create a new directory, and move your
packaged chart to that directory. packaged chart to that directory.
```console ```bash
$ helm package docs/examples/alpine/ $ helm package docs/examples/alpine/
$ mkdir fantastic-charts $ mkdir fantastic-charts
$ mv alpine-0.1.0.tgz fantastic-charts/ $ mv alpine-0.1.0.tgz fantastic-charts/
@ -295,7 +295,7 @@ From there, they will add the repository to their helm client via the `helm
repo add [NAME] [URL]` command with any name they would like to use to repo add [NAME] [URL]` command with any name they would like to use to
reference the repository. reference the repository.
```console ```bash
$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com
$ helm repo list $ helm repo list
fantastic-charts https://fantastic-charts.storage.googleapis.com fantastic-charts https://fantastic-charts.storage.googleapis.com
@ -304,7 +304,7 @@ fantastic-charts https://fantastic-charts.storage.googleapis.com
If the charts are backed by HTTP basic authentication, you can also supply the If the charts are backed by HTTP basic authentication, you can also supply the
username and password here: username and password here:
```console ```bash
$ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com --username my-username --password my-password
$ helm repo list $ helm repo list
fantastic-charts https://fantastic-charts.storage.googleapis.com fantastic-charts https://fantastic-charts.storage.googleapis.com

@ -10,7 +10,7 @@
Create a local directory like we did in [the chart repository guide](chart_repository.md), and place your packaged charts in that directory. Create a local directory like we did in [the chart repository guide](chart_repository.md), and place your packaged charts in that directory.
For example: For example:
```console ```bash
$ mkdir fantastic-charts $ mkdir fantastic-charts
$ mv alpine-0.1.0.tgz fantastic-charts/ $ mv alpine-0.1.0.tgz fantastic-charts/
``` ```
@ -18,7 +18,7 @@ $ mv alpine-0.1.0.tgz fantastic-charts/
## Generate an updated index.yaml ## Generate an updated index.yaml
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: 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 $ 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. 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. 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.
For example: For example:
```console ```bash
$ pwd $ pwd
/Users/funuser/go/src/github.com/helm/helm /Users/funuser/go/src/github.com/helm/helm
$ scripts/sync-repo.sh fantastic-charts/ fantastic-charts $ scripts/sync-repo.sh fantastic-charts/ fantastic-charts
@ -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. 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: For example:
```console ```bash
$ gsutil rsync -d -n gs://bucket-name local-dir/ # the -n flag does a dry run $ gsutil rsync -d -n gs://bucket-name local-dir/ # the -n flag does a dry run
Building synchronization state... Building synchronization state...
Starting synchronization Starting synchronization

@ -91,7 +91,7 @@ data:
Initially, this looks good. But if we run it through the template engine, we'll get an unfortunate result: Initially, this looks good. But if we run it through the template engine, we'll get an unfortunate result:
```console ```bash
$ helm install --dry-run --debug ./mychart $ helm install --dry-run --debug ./mychart
SERVER: "localhost:44134" SERVER: "localhost:44134"
CHART PATH: /Users/mattbutcher/Code/Go/src/k8s.io/helm/_scratch/mychart CHART PATH: /Users/mattbutcher/Code/Go/src/k8s.io/helm/_scratch/mychart

@ -37,7 +37,7 @@ comes to template rendering.
For this guide, we'll create a simple chart called `mychart`, and then we'll For this guide, we'll create a simple chart called `mychart`, and then we'll
create some templates inside of the chart. create some templates inside of the chart.
```console ```bash
$ helm create mychart $ helm create mychart
Creating 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. 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/*.* $ 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 With this simple template, we now have an installable chart. And we can install
it like this: it like this:
```console ```bash
$ helm install ./mychart $ helm install ./mychart
NAME: full-coral NAME: full-coral
LAST DEPLOYED: Tue Nov 1 17:36:01 2016 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 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. can retrieve the release and see the actual template that was loaded.
```console ```bash
$ helm get manifest full-coral $ 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: Now when we install our resource, we'll immediately see the result of using this template directive:
```console ```bash
$ helm install ./mychart $ helm install ./mychart
NAME: clunky-serval NAME: clunky-serval
LAST DEPLOYED: Tue Nov 1 17:45:37 2016 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: 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:
```console ```bash
$ helm install --debug --dry-run ./mychart $ helm install --debug --dry-run ./mychart
SERVER: "localhost:44134" SERVER: "localhost:44134"
CHART PATH: /Users/mattbutcher/Code/Go/src/k8s.io/helm/_scratch/mychart CHART PATH: /Users/mattbutcher/Code/Go/src/k8s.io/helm/_scratch/mychart

@ -15,7 +15,7 @@ As we walk through the examples in this section, many of these concepts will bec
For these exercises, we'll start with the `mychart/` chart we created at the beginning of this guide, and we'll add a new chart inside of it. For these exercises, we'll start with the `mychart/` chart we created at the beginning of this guide, and we'll add a new chart inside of it.
```console ```bash
$ cd mychart/charts $ cd mychart/charts
$ helm create mysubchart $ helm create mysubchart
Creating mysubchart Creating mysubchart
@ -45,7 +45,7 @@ data:
Because every subchart is a _stand-alone chart_, we can test `mysubchart` on its own: Because every subchart is a _stand-alone chart_, we can test `mysubchart` on its own:
```console ```bash
$ helm install --dry-run --debug mychart/charts/mysubchart $ helm install --dry-run --debug mychart/charts/mysubchart
SERVER: "localhost:44134" SERVER: "localhost:44134"
CHART PATH: /Users/mattbutcher/Code/Go/src/k8s.io/helm/_scratch/mychart/charts/mysubchart CHART PATH: /Users/mattbutcher/Code/Go/src/k8s.io/helm/_scratch/mychart/charts/mysubchart

@ -33,7 +33,7 @@ Notice on the last line we access `favoriteDrink` as an attribute of `Values`: `
Let's see how this renders. Let's see how this renders.
```console ```bash
$ helm install --dry-run --debug ./mychart $ helm install --dry-run --debug ./mychart
SERVER: "localhost:44134" SERVER: "localhost:44134"
CHART PATH: /Users/mattbutcher/Code/Go/src/k8s.io/helm/_scratch/mychart CHART PATH: /Users/mattbutcher/Code/Go/src/k8s.io/helm/_scratch/mychart
@ -54,8 +54,8 @@ data:
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`: 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`:
```console ```bash
helm install --dry-run --debug --set favoriteDrink=slurm ./mychart $ helm install --dry-run --debug --set favoriteDrink=slurm ./mychart
SERVER: "localhost:44134" SERVER: "localhost:44134"
CHART PATH: /Users/mattbutcher/Code/Go/src/k8s.io/helm/_scratch/mychart CHART PATH: /Users/mattbutcher/Code/Go/src/k8s.io/helm/_scratch/mychart
NAME: solid-vulture NAME: solid-vulture

@ -184,7 +184,7 @@ Once you have a dependencies file, you can run `helm dependency update`
and it will use your dependency file to download all the specified and it will use your dependency file to download all the specified
charts into your `charts/` directory for you. charts into your `charts/` directory for you.
```console ```bash
$ helm dep up foochart $ helm dep up foochart
Hang tight while we grab the latest from your chart repositories... Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "local" chart repository ...Successfully got an update from the "local" chart repository
@ -630,7 +630,7 @@ A values file is formatted in YAML. A chart may include a default
`values.yaml` file. The Helm install command allows a user to override `values.yaml` file. The Helm install command allows a user to override
values by supplying additional YAML values: values by supplying additional YAML values:
```console ```bash
$ helm install --values=myvals.yaml wordpress $ helm install --values=myvals.yaml wordpress
``` ```
@ -800,7 +800,7 @@ The `helm` tool has several commands for working with charts.
It can create a new chart for you: It can create a new chart for you:
```console ```bash
$ helm create mychart $ helm create mychart
Created mychart/ Created mychart/
``` ```
@ -808,7 +808,7 @@ Created mychart/
Once you have edited a chart, `helm` can package it into a chart archive Once you have edited a chart, `helm` can package it into a chart archive
for you: for you:
```console ```bash
$ helm package mychart $ helm package mychart
Archived mychart-0.1.-.tgz Archived mychart-0.1.-.tgz
``` ```
@ -816,7 +816,7 @@ Archived mychart-0.1.-.tgz
You can also use `helm` to help you find issues with your chart's You can also use `helm` to help you find issues with your chart's
formatting or information: formatting or information:
```console ```bash
$ helm lint mychart $ helm lint mychart
No issues found No issues found
``` ```

@ -15,7 +15,7 @@ Helm and Tiller.
We use Make to build our programs. The simplest way to get started is: We use Make to build our programs. The simplest way to get started is:
```console ```bash
$ make bootstrap build $ make bootstrap build
``` ```
@ -91,13 +91,13 @@ developer-oriented distribution. Once this is installed, you can use
development may not be available in Google Cloud Container Registry. If you're getting development may not be available in Google Cloud Container Registry. If you're getting
image pull errors, you can override the version of Tiller. Example: image pull errors, you can override the version of Tiller. Example:
```console ```bash
helm init --tiller-image=gcr.io/kubernetes-helm/tiller:2.7.2 helm init --tiller-image=gcr.io/kubernetes-helm/tiller:2.7.2
``` ```
Or use the latest version: Or use the latest version:
```console ```bash
helm init --canary-image helm init --canary-image
``` ```
@ -105,7 +105,7 @@ For developing on Tiller, it is sometimes more expedient to run Tiller locally
instead of packaging it into an image and running it in-cluster. You can do instead of packaging it into an image and running it in-cluster. You can do
this by telling the Helm client to us a local instance. this by telling the Helm client to us a local instance.
```console ```bash
$ make build $ make build
$ bin/tiller $ bin/tiller
``` ```
@ -113,7 +113,7 @@ $ bin/tiller
And to configure the Helm client, use the `--host` flag or export the `HELM_HOST` And to configure the Helm client, use the `--host` flag or export the `HELM_HOST`
environment variable: environment variable:
```console ```bash
$ export HELM_HOST=localhost:44134 $ export HELM_HOST=localhost:44134
$ helm install foo $ helm install foo
``` ```

@ -98,7 +98,7 @@ go if you want to test the latest (pre-release) Helm version.
You must have a working Go environment with You must have a working Go environment with
[glide](https://github.com/Masterminds/glide) installed. [glide](https://github.com/Masterminds/glide) installed.
```console ```bash
$ cd $GOPATH $ cd $GOPATH
$ mkdir -p src/k8s.io $ mkdir -p src/k8s.io
$ cd src/k8s.io $ cd src/k8s.io
@ -162,7 +162,7 @@ stable, but they offer you the chance to test out the latest features.
The easiest way to install a canary image is to use `helm init` with the The easiest way to install a canary image is to use `helm init` with the
`--canary-image` flag: `--canary-image` flag:
```console ```bash
$ helm init --canary-image $ helm init --canary-image
``` ```
@ -179,7 +179,7 @@ The process of building Tiller is explained above.
Once `tiller` has been built, simply start it: Once `tiller` has been built, simply start it:
```console ```bash
$ bin/tiller $ bin/tiller
Tiller running on :44134 Tiller running on :44134
``` ```
@ -193,7 +193,7 @@ connecting to the one in-cluster. There are two ways to do this. The
first is to specify the `--host` option on the command line. The second first is to specify the `--host` option on the command line. The second
is to set the `$HELM_HOST` environment variable. is to set the `$HELM_HOST` environment variable.
```console ```bash
$ export HELM_HOST=localhost:44134 $ export HELM_HOST=localhost:44134
$ helm version # Should connect to localhost. $ helm version # Should connect to localhost.
Client: &version.Version{SemVer:"v2.0.0-alpha.4", GitCommit:"db...", GitTreeState:"dirty"} Client: &version.Version{SemVer:"v2.0.0-alpha.4", GitCommit:"db...", GitTreeState:"dirty"}
@ -210,7 +210,7 @@ As of Helm 2.2.0, Tiller can be upgraded using `helm init --upgrade`.
For older versions of Helm, or for manual upgrades, you can use `kubectl` to modify For older versions of Helm, or for manual upgrades, you can use `kubectl` to modify
the Tiller image: the Tiller image:
```console ```bash
$ export TILLER_TAG=v2.0.0-beta.1 # Or whatever version you want $ export TILLER_TAG=v2.0.0-beta.1 # Or whatever version you want
$ kubectl --namespace=kube-system set image deployments/tiller-deploy tiller=gcr.io/kubernetes-helm/tiller:$TILLER_TAG $ kubectl --namespace=kube-system set image deployments/tiller-deploy tiller=gcr.io/kubernetes-helm/tiller:$TILLER_TAG
deployment "tiller-deploy" image updated deployment "tiller-deploy" image updated
@ -227,7 +227,7 @@ tiller-deploy --namespace kube-system`, or more concisely `helm reset`.
Tiller can then be re-installed from the client with: Tiller can then be re-installed from the client with:
```console ```bash
$ helm init $ helm init
``` ```

@ -41,7 +41,7 @@ I'm trying to install Helm/Tiller, but something is not right.
Set the `$HELM_HOME` environment variable, and then run `helm init`: Set the `$HELM_HOME` environment variable, and then run `helm init`:
```console ```bash
export HELM_HOME=/some/path export HELM_HOME=/some/path
helm init --client-only helm init --client-only
``` ```

@ -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` 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`
```console ```bash
$ helm plugin install https://github.com/technosophos/helm-template $ helm plugin install https://github.com/technosophos/helm-template
``` ```

@ -24,7 +24,7 @@ that `kubectl` uses.
To find out which cluster Tiller would install to, you can run To find out which cluster Tiller would install to, you can run
`kubectl config current-context` or `kubectl cluster-info`. `kubectl config current-context` or `kubectl cluster-info`.
```console ```bash
$ kubectl config current-context $ kubectl config current-context
my-cluster my-cluster
``` ```
@ -53,7 +53,7 @@ guide](install.md).
Once you have Helm ready, you can initialize the local CLI and also Once you have Helm ready, you can initialize the local CLI and also
install Tiller into your Kubernetes cluster in one step: install Tiller into your Kubernetes cluster in one step:
```console ```bash
$ helm init $ helm init
``` ```
@ -75,7 +75,7 @@ To install a chart, you can run the `helm install` command. Helm has
several ways to find and install a chart, but the easiest is to use one several ways to find and install a chart, but the easiest is to use one
of the official `stable` charts. of the official `stable` charts.
```console ```bash
$ helm repo update # Make sure we get the latest list of charts $ helm repo update # Make sure we get the latest list of charts
$ helm install stable/mysql $ helm install stable/mysql
NAME: wintering-rodent NAME: wintering-rodent
@ -154,7 +154,7 @@ Guide](using_helm.md)
It's easy to see what has been released using Helm: It's easy to see what has been released using Helm:
```console ```bash
$ helm ls $ helm ls
NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE
wintering-rodent 1 Thu Oct 18 15:06:58 2018 DEPLOYED mysql-0.10.1 5.7.14 default wintering-rodent 1 Thu Oct 18 15:06:58 2018 DEPLOYED mysql-0.10.1 5.7.14 default
@ -166,7 +166,7 @@ The `helm list` function will show you a list of all deployed releases.
To uninstall a release, use the `helm delete` command: To uninstall a release, use the `helm delete` command:
```console ```bash
$ helm delete wintering-rodent $ helm delete wintering-rodent
release "wintering-rodent" deleted release "wintering-rodent" deleted
``` ```
@ -174,7 +174,7 @@ release "wintering-rodent" deleted
This will uninstall `wintering-rodent` from Kubernetes, but you will This will uninstall `wintering-rodent` from Kubernetes, but you will
still be able to request information about that release: still be able to request information about that release:
```console ```bash
$ helm status wintering-rodent $ helm status wintering-rodent
LAST DEPLOYED: Thu Oct 18 14:21:18 2018 LAST DEPLOYED: Thu Oct 18 14:21:18 2018
NAMESPACE: default NAMESPACE: default
@ -220,6 +220,6 @@ rollback`).
To learn more about the available Helm commands, use `helm help` or type To learn more about the available Helm commands, use `helm help` or type
a command followed by the `-h` flag: a command followed by the `-h` flag:
```console ```bash
$ helm get -h $ helm get -h
``` ```

@ -39,7 +39,7 @@ subjects:
_Note: The cluster-admin role is created by default in a Kubernetes cluster, so you don't have to define it explicitly._ _Note: The cluster-admin role is created by default in a Kubernetes cluster, so you don't have to define it explicitly._
```console ```bash
$ kubectl create -f rbac-config.yaml $ kubectl create -f rbac-config.yaml
serviceaccount "tiller" created serviceaccount "tiller" created
clusterrolebinding "tiller" created clusterrolebinding "tiller" created
@ -50,7 +50,7 @@ $ helm init --service-account tiller
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. 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.
```console ```bash
$ kubectl create namespace tiller-world $ kubectl create namespace tiller-world
namespace "tiller-world" created namespace "tiller-world" created
$ kubectl create serviceaccount tiller --namespace tiller-world $ kubectl create serviceaccount tiller --namespace tiller-world
@ -71,7 +71,7 @@ rules:
verbs: ["*"] verbs: ["*"]
``` ```
```console ```bash
$ kubectl create -f role-tiller.yaml $ kubectl create -f role-tiller.yaml
role "tiller-manager" created role "tiller-manager" created
``` ```
@ -94,14 +94,14 @@ roleRef:
apiGroup: rbac.authorization.k8s.io apiGroup: rbac.authorization.k8s.io
``` ```
```console ```bash
$ kubectl create -f rolebinding-tiller.yaml $ kubectl create -f rolebinding-tiller.yaml
rolebinding "tiller-binding" created rolebinding "tiller-binding" created
``` ```
Afterwards you can run `helm init` to install Tiller in the `tiller-world` namespace. Afterwards you can run `helm init` to install Tiller in the `tiller-world` namespace.
```console ```bash
$ helm init --service-account tiller --tiller-namespace tiller-world $ helm init --service-account tiller --tiller-namespace tiller-world
$HELM_HOME has been configured at /Users/awesome-user/.helm. $HELM_HOME has been configured at /Users/awesome-user/.helm.
@ -126,7 +126,7 @@ In the example above, we gave Tiller admin access to the namespace it was deploy
For example, let's install Tiller in the namespace `myorg-system` and allow Tiller to deploy resources in the namespace `myorg-users`. For example, let's install Tiller in the namespace `myorg-system` and allow Tiller to deploy resources in the namespace `myorg-users`.
```console ```bash
$ kubectl create namespace myorg-system $ kubectl create namespace myorg-system
namespace "myorg-system" created namespace "myorg-system" created
$ kubectl create serviceaccount tiller --namespace myorg-system $ kubectl create serviceaccount tiller --namespace myorg-system
@ -147,7 +147,7 @@ rules:
verbs: ["*"] verbs: ["*"]
``` ```
```console ```bash
$ kubectl create -f role-tiller.yaml $ kubectl create -f role-tiller.yaml
role "tiller-manager" created role "tiller-manager" created
``` ```
@ -170,7 +170,7 @@ roleRef:
apiGroup: rbac.authorization.k8s.io apiGroup: rbac.authorization.k8s.io
``` ```
```console ```bash
$ kubectl create -f rolebinding-tiller.yaml $ kubectl create -f rolebinding-tiller.yaml
rolebinding "tiller-binding" created rolebinding "tiller-binding" created
``` ```
@ -189,7 +189,7 @@ rules:
verbs: ["*"] verbs: ["*"]
``` ```
```console ```bash
$ kubectl create -f role-tiller-myorg-system.yaml $ kubectl create -f role-tiller-myorg-system.yaml
role "tiller-manager" created role "tiller-manager" created
``` ```
@ -212,7 +212,7 @@ roleRef:
apiGroup: rbac.authorization.k8s.io apiGroup: rbac.authorization.k8s.io
``` ```
```console ```bash
$ kubectl create -f rolebinding-tiller-myorg-system.yaml $ kubectl create -f rolebinding-tiller-myorg-system.yaml
rolebinding "tiller-binding" created rolebinding "tiller-binding" created
``` ```
@ -268,7 +268,7 @@ subjects:
namespace: helm-world namespace: helm-world
``` ```
```console ```bash
$ kubectl create -f helm-user.yaml $ kubectl create -f helm-user.yaml
serviceaccount "helm" created serviceaccount "helm" created
role "tiller-user" created role "tiller-user" created

@ -46,7 +46,7 @@ consult other resources.
The simplest way to generate a certificate authority is to run two commands: The simplest way to generate a certificate authority is to run two commands:
```console ```bash
$ openssl genrsa -out ./ca.key.pem 4096 $ openssl genrsa -out ./ca.key.pem 4096
$ openssl req -key ca.key.pem -new -x509 -days 7300 -sha256 -out ca.cert.pem -extensions v3_ca $ openssl req -key ca.key.pem -new -x509 -days 7300 -sha256 -out ca.cert.pem -extensions v3_ca
Enter pass phrase for ca.key.pem: Enter pass phrase for ca.key.pem:
@ -88,7 +88,7 @@ same time. The names will indicate their target.
First, the Tiller key: First, the Tiller key:
```console ```bash
$ openssl genrsa -out ./tiller.key.pem 4096 $ openssl genrsa -out ./tiller.key.pem 4096
Generating RSA private key, 4096 bit long modulus Generating RSA private key, 4096 bit long modulus
..........................................................................................................................................................................................................................................................................................................................++ ..........................................................................................................................................................................................................................................................................................................................++
@ -100,7 +100,7 @@ Verifying - Enter pass phrase for ./tiller.key.pem:
Next, generate the Helm client's key: Next, generate the Helm client's key:
```console ```bash
$ openssl genrsa -out ./helm.key.pem 4096 $ openssl genrsa -out ./helm.key.pem 4096
Generating RSA private key, 4096 bit long modulus Generating RSA private key, 4096 bit long modulus
.....++ .....++
@ -115,7 +115,7 @@ Again, for production use you will generate one client certificate for each user
Next we need to create certificates from these keys. For each certificate, this is Next we need to create certificates from these keys. For each certificate, this is
a two-step process of creating a CSR, and then creating the certificate. a two-step process of creating a CSR, and then creating the certificate.
```console ```bash
$ openssl req -key tiller.key.pem -new -sha256 -out tiller.csr.pem $ openssl req -key tiller.key.pem -new -sha256 -out tiller.csr.pem
Enter pass phrase for tiller.key.pem: Enter pass phrase for tiller.key.pem:
You are about to be asked to enter information that will be incorporated You are about to be asked to enter information that will be incorporated
@ -141,7 +141,7 @@ An optional company name []:
And we repeat this step for the Helm client certificate: And we repeat this step for the Helm client certificate:
```console ```bash
$ openssl req -key helm.key.pem -new -sha256 -out helm.csr.pem $ openssl req -key helm.key.pem -new -sha256 -out helm.csr.pem
# Answer the questions with your client user's info # Answer the questions with your client user's info
``` ```
@ -150,7 +150,7 @@ $ openssl req -key helm.key.pem -new -sha256 -out helm.csr.pem
Now we sign each of these CSRs with the CA certificate we created (adjust the days parameter to suit your requirements): Now we sign each of these CSRs with the CA certificate we created (adjust the days parameter to suit your requirements):
```console ```bash
$ openssl x509 -req -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -in tiller.csr.pem -out tiller.cert.pem -days 365 $ openssl x509 -req -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -in tiller.csr.pem -out tiller.cert.pem -days 365
Signature ok Signature ok
subject=/C=US/ST=CO/L=Boulder/O=Tiller Server/CN=tiller-server subject=/C=US/ST=CO/L=Boulder/O=Tiller Server/CN=tiller-server
@ -160,7 +160,7 @@ Enter pass phrase for ca.key.pem:
And again for the client certificate: And again for the client certificate:
```console ```bash
$ openssl x509 -req -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -in helm.csr.pem -out helm.cert.pem -days 365 $ openssl x509 -req -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -in helm.csr.pem -out helm.cert.pem -days 365
``` ```
@ -188,7 +188,7 @@ with all of our SSL configuration.
To take a look at what this will generate, run this command: To take a look at what this will generate, run this command:
```console ```bash
$ helm init --dry-run --debug --tiller-tls --tiller-tls-cert ./tiller.cert.pem --tiller-tls-key ./tiller.key.pem --tiller-tls-verify --tls-ca-cert ca.cert.pem $ helm init --dry-run --debug --tiller-tls --tiller-tls-cert ./tiller.cert.pem --tiller-tls-key ./tiller.key.pem --tiller-tls-verify --tls-ca-cert ca.cert.pem
``` ```
@ -207,13 +207,13 @@ putting Tiller in a non-system namespace (`--tiller-namespace=something`) and en
a service account (`--service-account=somename`). But for this example we will stay a service account (`--service-account=somename`). But for this example we will stay
with the basics: with the basics:
```console ```bash
$ helm init --tiller-tls --tiller-tls-cert ./tiller.cert.pem --tiller-tls-key ./tiller.key.pem --tiller-tls-verify --tls-ca-cert ca.cert.pem $ helm init --tiller-tls --tiller-tls-cert ./tiller.cert.pem --tiller-tls-key ./tiller.key.pem --tiller-tls-verify --tls-ca-cert ca.cert.pem
``` ```
In a minute or two it should be ready. We can check Tiller like this: In a minute or two it should be ready. We can check Tiller like this:
```console ```bash
$ kubectl -n kube-system get deployment $ kubectl -n kube-system get deployment
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
... other stuff ... other stuff
@ -227,7 +227,7 @@ cert and the key.
At this point, you should get a _failure_ when you run basic Helm commands: At this point, you should get a _failure_ when you run basic Helm commands:
```console ```bash
$ helm ls $ helm ls
Error: transport is closing Error: transport is closing
``` ```
@ -243,7 +243,7 @@ Helm client to also perform TLS operations.
For a quick test, we can specify our configuration manually. We'll run a normal For a quick test, we can specify our configuration manually. We'll run a normal
Helm command (`helm ls`), but with SSL/TLS enabled. Helm command (`helm ls`), but with SSL/TLS enabled.
```console ```bash
helm ls --tls --tls-ca-cert ca.cert.pem --tls-cert helm.cert.pem --tls-key helm.key.pem helm ls --tls --tls-ca-cert ca.cert.pem --tls-cert helm.cert.pem --tls-key helm.key.pem
``` ```
@ -254,7 +254,7 @@ Tiller's identity.
Typing a line that is cumbersome, though. The shortcut is to move the key, Typing a line that is cumbersome, though. The shortcut is to move the key,
cert, and CA into `$HELM_HOME`: cert, and CA into `$HELM_HOME`:
```console ```bash
$ cp ca.cert.pem $(helm home)/ca.pem $ cp ca.cert.pem $(helm home)/ca.pem
$ cp helm.cert.pem $(helm home)/cert.pem $ cp helm.cert.pem $(helm home)/cert.pem
$ cp helm.key.pem $(helm home)/key.pem $ cp helm.key.pem $(helm home)/key.pem
@ -294,7 +294,7 @@ Therefore, to validate the certificate, the IP address 127.0.0.1 must be listed
For example, to list 127.0.0.1 as an IP SAN when generating the Tiller certificate: For example, to list 127.0.0.1 as an IP SAN when generating the Tiller certificate:
```console ```bash
$ echo subjectAltName=IP:127.0.0.1 > extfile.cnf $ echo subjectAltName=IP:127.0.0.1 > extfile.cnf
$ openssl x509 -req -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -in tiller.csr.pem -out tiller.cert.pem -days 365 -extfile extfile.cnf $ openssl x509 -req -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -in tiller.csr.pem -out tiller.cert.pem -days 365 -extfile extfile.cnf
``` ```

@ -43,7 +43,7 @@ carefully curated and maintained charts. This chart repository is named
You can see which charts are available by running `helm search`: You can see which charts are available by running `helm search`:
```console ```bash
$ helm search $ helm search
NAME VERSION DESCRIPTION NAME VERSION DESCRIPTION
stable/drupal 0.3.2 One of the most versatile open source content m... stable/drupal 0.3.2 One of the most versatile open source content m...
@ -56,7 +56,7 @@ stable/mysql 0.1.0 Chart for MySQL
With no filter, `helm search` shows you all of the available charts. You With no filter, `helm search` shows you all of the available charts. You
can narrow down your results by searching with a filter: can narrow down your results by searching with a filter:
```console ```bash
$ helm search mysql $ helm search mysql
NAME VERSION DESCRIPTION NAME VERSION DESCRIPTION
stable/mysql 0.1.0 Chart for MySQL stable/mysql 0.1.0 Chart for MySQL
@ -69,7 +69,7 @@ Why is
`mariadb` in the list? Because its package description relates it to `mariadb` in the list? Because its package description relates it to
MySQL. We can use `helm inspect chart` to see this: MySQL. We can use `helm inspect chart` to see this:
```console ```bash
$ helm inspect stable/mariadb $ helm inspect stable/mariadb
Fetched stable/mariadb to mariadb-0.5.1.tgz Fetched stable/mariadb to mariadb-0.5.1.tgz
description: Chart for MariaDB description: Chart for MariaDB
@ -91,7 +91,7 @@ package you want to install, you can use `helm install` to install it.
To install a new package, use the `helm install` command. At its To install a new package, use the `helm install` command. At its
simplest, it takes only one argument: The name of the chart. simplest, it takes only one argument: The name of the chart.
```console ```bash
$ helm install stable/mariadb $ helm install stable/mariadb
Fetched stable/mariadb-0.3.0 to /Users/mattbutcher/Code/Go/src/k8s.io/helm/mariadb-0.3.0.tgz Fetched stable/mariadb-0.3.0 to /Users/mattbutcher/Code/Go/src/k8s.io/helm/mariadb-0.3.0.tgz
NAME: happy-panda NAME: happy-panda
@ -139,7 +139,7 @@ may take a long time to install into the cluster.
To keep track of a release's state, or to re-read configuration To keep track of a release's state, or to re-read configuration
information, you can use `helm status`: information, you can use `helm status`:
```console ```bash
$ helm status happy-panda $ helm status happy-panda
Last Deployed: Wed Sep 28 12:32:28 2016 Last Deployed: Wed Sep 28 12:32:28 2016
Namespace: default Namespace: default
@ -179,7 +179,7 @@ to use your preferred configuration.
To see what options are configurable on a chart, use `helm inspect To see what options are configurable on a chart, use `helm inspect
values`: values`:
```console ```bash
helm inspect values stable/mariadb helm inspect values stable/mariadb
Fetched stable/mariadb-0.3.0.tgz to /Users/mattbutcher/Code/Go/src/k8s.io/helm/mariadb-0.3.0.tgz Fetched stable/mariadb-0.3.0.tgz to /Users/mattbutcher/Code/Go/src/k8s.io/helm/mariadb-0.3.0.tgz
## Bitnami MariaDB image version ## Bitnami MariaDB image version
@ -214,7 +214,7 @@ imageTag: 10.1.14-r3
You can then override any of these settings in a YAML formatted file, You can then override any of these settings in a YAML formatted file,
and then pass that file during installation. and then pass that file during installation.
```console ```bash
$ cat << EOF > config.yaml $ cat << EOF > config.yaml
mariadbUser: user0 mariadbUser: user0
mariadbDatabase: user0db mariadbDatabase: user0db
@ -356,7 +356,7 @@ information you provide. Because Kubernetes charts can be large and
complex, Helm tries to perform the least invasive upgrade. It will only complex, Helm tries to perform the least invasive upgrade. It will only
update things that have changed since the last release. update things that have changed since the last release.
```console ```bash
$ helm upgrade -f panda.yaml happy-panda stable/mariadb $ helm upgrade -f panda.yaml happy-panda stable/mariadb
Fetched stable/mariadb-0.3.0.tgz to /Users/mattbutcher/Code/Go/src/k8s.io/helm/mariadb-0.3.0.tgz Fetched stable/mariadb-0.3.0.tgz to /Users/mattbutcher/Code/Go/src/k8s.io/helm/mariadb-0.3.0.tgz
happy-panda has been upgraded. Happy Helming! happy-panda has been upgraded. Happy Helming!
@ -376,7 +376,7 @@ mariadbUser: user1
We can use `helm get values` to see whether that new setting took We can use `helm get values` to see whether that new setting took
effect. effect.
```console ```bash
$ helm get values happy-panda $ helm get values happy-panda
mariadbUser: user1 mariadbUser: user1
``` ```
@ -388,7 +388,7 @@ cluster. And as we can see above, it shows that our new values from
Now, if something does not go as planned during a release, it is easy to Now, if something does not go as planned during a release, it is easy to
roll back to a previous release using `helm rollback [RELEASE] [REVISION]`. roll back to a previous release using `helm rollback [RELEASE] [REVISION]`.
```console ```bash
$ helm rollback happy-panda 1 $ helm rollback happy-panda 1
``` ```
@ -424,14 +424,14 @@ is not a full list of cli flags. To see a description of all flags, just run
When it is time to uninstall or delete a release from the cluster, use When it is time to uninstall or delete a release from the cluster, use
the `helm delete` command: the `helm delete` command:
```console ```bash
$ helm delete happy-panda $ helm delete happy-panda
``` ```
This will remove the release from the cluster. You can see all of your This will remove the release from the cluster. You can see all of your
currently deployed releases with the `helm list` command: currently deployed releases with the `helm list` command:
```console ```bash
$ helm list $ helm list
NAME VERSION UPDATED STATUS CHART NAME VERSION UPDATED STATUS CHART
inky-cat 1 Wed Sep 28 12:59:46 2016 DEPLOYED alpine-0.1.0 inky-cat 1 Wed Sep 28 12:59:46 2016 DEPLOYED alpine-0.1.0
@ -445,7 +445,7 @@ see the deleted releases? `helm list --deleted` shows those, and `helm
list --all` shows all of the releases (deleted and currently deployed, list --all` shows all of the releases (deleted and currently deployed,
as well as releases that failed): as well as releases that failed):
```console ```bash
⇒ helm list --all ⇒ helm list --all
NAME VERSION UPDATED STATUS CHART NAME VERSION UPDATED STATUS CHART
happy-panda 2 Wed Sep 28 12:47:54 2016 DELETED mariadb-0.3.0 happy-panda 2 Wed Sep 28 12:47:54 2016 DELETED mariadb-0.3.0
@ -469,7 +469,7 @@ several repository tools under the `helm repo` command.
You can see which repositories are configured using `helm repo list`: You can see which repositories are configured using `helm repo list`:
```console ```bash
$ helm repo list $ helm repo list
NAME URL NAME URL
stable https://kubernetes-charts.storage.googleapis.com stable https://kubernetes-charts.storage.googleapis.com
@ -479,7 +479,7 @@ mumoshu https://mumoshu.github.io/charts
And new repositories can be added with `helm repo add`: And new repositories can be added with `helm repo add`:
```console ```bash
$ helm repo add dev https://example.com/dev-charts $ helm repo add dev https://example.com/dev-charts
``` ```
@ -492,7 +492,7 @@ The [Chart Development Guide](charts.md) explains how to develop your own
charts. But you can get started quickly by using the `helm create` charts. But you can get started quickly by using the `helm create`
command: command:
```console ```bash
$ helm create deis-workflow $ helm create deis-workflow
Creating deis-workflow Creating deis-workflow
``` ```
@ -506,14 +506,14 @@ running `helm lint`.
When it's time to package the chart up for distribution, you can run the When it's time to package the chart up for distribution, you can run the
`helm package` command: `helm package` command:
```console ```bash
$ helm package deis-workflow $ helm package deis-workflow
deis-workflow-0.1.0.tgz deis-workflow-0.1.0.tgz
``` ```
And that chart can now easily be installed by `helm install`: And that chart can now easily be installed by `helm install`:
```console ```bash
$ helm install ./deis-workflow-0.1.0.tgz $ helm install ./deis-workflow-0.1.0.tgz
... ...
``` ```

Loading…
Cancel
Save