From 06fdc39384264d98d0480f3d7707f172ddfa89a8 Mon Sep 17 00:00:00 2001 From: Nguyen Hai Truong Date: Wed, 20 Feb 2019 14:05:42 +0700 Subject: [PATCH] Modifying the highlight syntax in markdown file Using `bash` instead of `console` in script section of markdown file. Signed-off-by: Nguyen Hai Truong --- docs/chart_repository.md | 10 +++--- docs/chart_repository_sync_example.md | 8 ++--- .../control_structures.md | 2 +- docs/chart_template_guide/getting_started.md | 12 +++---- .../subcharts_and_globals.md | 4 +-- docs/chart_template_guide/values_files.md | 6 ++-- docs/charts.md | 10 +++--- docs/developers.md | 10 +++--- docs/install.md | 12 +++---- docs/install_faq.md | 2 +- docs/plugins.md | 2 +- docs/quickstart.md | 14 ++++---- docs/rbac.md | 22 ++++++------ docs/tiller_ssl.md | 28 +++++++-------- docs/using_helm.md | 36 +++++++++---------- 15 files changed, 89 insertions(+), 89 deletions(-) diff --git a/docs/chart_repository.md b/docs/chart_repository.md index e3bbe3c7d..52ebf858c 100644 --- a/docs/chart_repository.md +++ b/docs/chart_repository.md @@ -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 things out locally with the `helm serve` command, which starts a local server. -```console +```bash $ helm serve --repo-path ./charts Regenerating index. This may take a moment. 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 locally as. -```console +```bash $ git checkout -b gh-pages ``` @@ -257,7 +257,7 @@ repository. Once you have a packaged chart ready, create a new directory, and move your packaged chart to that directory. -```console +```bash $ helm package docs/examples/alpine/ $ mkdir 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 reference the repository. -```console +```bash $ helm repo add fantastic-charts https://fantastic-charts.storage.googleapis.com $ helm repo list 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 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 list fantastic-charts https://fantastic-charts.storage.googleapis.com diff --git a/docs/chart_repository_sync_example.md b/docs/chart_repository_sync_example.md index 931275431..92af0d75a 100644 --- a/docs/chart_repository_sync_example.md +++ b/docs/chart_repository_sync_example.md @@ -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. For example: -```console +```bash $ mkdir 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 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. For example: -```console +```bash $ pwd /Users/funuser/go/src/github.com/helm/helm $ 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. For example: -```console +```bash $ gsutil rsync -d -n gs://bucket-name local-dir/ # the -n flag does a dry run Building synchronization state... Starting synchronization diff --git a/docs/chart_template_guide/control_structures.md b/docs/chart_template_guide/control_structures.md index d411c2f79..d1542456b 100644 --- a/docs/chart_template_guide/control_structures.md +++ b/docs/chart_template_guide/control_structures.md @@ -91,7 +91,7 @@ data: 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 SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/k8s.io/helm/_scratch/mychart diff --git a/docs/chart_template_guide/getting_started.md b/docs/chart_template_guide/getting_started.md index eb1d966d3..bedd03e74 100644 --- a/docs/chart_template_guide/getting_started.md +++ b/docs/chart_template_guide/getting_started.md @@ -37,7 +37,7 @@ comes to template rendering. 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: -```console +```bash $ helm install --debug --dry-run ./mychart SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/k8s.io/helm/_scratch/mychart diff --git a/docs/chart_template_guide/subcharts_and_globals.md b/docs/chart_template_guide/subcharts_and_globals.md index b37a82bca..5745a312b 100644 --- a/docs/chart_template_guide/subcharts_and_globals.md +++ b/docs/chart_template_guide/subcharts_and_globals.md @@ -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. -```console +```bash $ cd mychart/charts $ helm create mysubchart Creating mysubchart @@ -45,7 +45,7 @@ data: 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 SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/k8s.io/helm/_scratch/mychart/charts/mysubchart diff --git a/docs/chart_template_guide/values_files.md b/docs/chart_template_guide/values_files.md index 218da19dc..e76aa8fab 100644 --- a/docs/chart_template_guide/values_files.md +++ b/docs/chart_template_guide/values_files.md @@ -33,7 +33,7 @@ Notice on the last line we access `favoriteDrink` as an attribute of `Values`: ` Let's see how this renders. -```console +```bash $ helm install --dry-run --debug ./mychart SERVER: "localhost:44134" 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`: -```console -helm install --dry-run --debug --set favoriteDrink=slurm ./mychart +```bash +$ helm install --dry-run --debug --set favoriteDrink=slurm ./mychart SERVER: "localhost:44134" CHART PATH: /Users/mattbutcher/Code/Go/src/k8s.io/helm/_scratch/mychart NAME: solid-vulture diff --git a/docs/charts.md b/docs/charts.md index d91dfe54e..6ceb4a022 100644 --- a/docs/charts.md +++ b/docs/charts.md @@ -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 charts into your `charts/` directory for you. -```console +```bash $ helm dep up foochart Hang tight while we grab the latest from your chart repositories... ...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 by supplying additional YAML values: -```console +```bash $ 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: -```console +```bash $ helm create mychart Created mychart/ ``` @@ -808,7 +808,7 @@ Created mychart/ Once you have edited a chart, `helm` can package it into a chart archive for you: -```console +```bash $ helm package mychart 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 formatting or information: -```console +```bash $ helm lint mychart No issues found ``` diff --git a/docs/developers.md b/docs/developers.md index fb704cb17..3a1d629f7 100644 --- a/docs/developers.md +++ b/docs/developers.md @@ -15,7 +15,7 @@ Helm and Tiller. We use Make to build our programs. The simplest way to get started is: -```console +```bash $ 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 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 ``` Or use the latest version: -```console +```bash 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 this by telling the Helm client to us a local instance. -```console +```bash $ make build $ bin/tiller ``` @@ -113,7 +113,7 @@ $ bin/tiller And to configure the Helm client, use the `--host` flag or export the `HELM_HOST` environment variable: -```console +```bash $ export HELM_HOST=localhost:44134 $ helm install foo ``` diff --git a/docs/install.md b/docs/install.md index b9626a43a..eab809fd2 100755 --- a/docs/install.md +++ b/docs/install.md @@ -98,7 +98,7 @@ go if you want to test the latest (pre-release) Helm version. You must have a working Go environment with [glide](https://github.com/Masterminds/glide) installed. -```console +```bash $ cd $GOPATH $ mkdir -p 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 `--canary-image` flag: -```console +```bash $ helm init --canary-image ``` @@ -179,7 +179,7 @@ The process of building Tiller is explained above. Once `tiller` has been built, simply start it: -```console +```bash $ bin/tiller 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 is to set the `$HELM_HOST` environment variable. -```console +```bash $ export HELM_HOST=localhost:44134 $ helm version # Should connect to localhost. 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 the Tiller image: -```console +```bash $ 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 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: -```console +```bash $ helm init ``` diff --git a/docs/install_faq.md b/docs/install_faq.md index d4840417f..dc554b650 100644 --- a/docs/install_faq.md +++ b/docs/install_faq.md @@ -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`: -```console +```bash export HELM_HOME=/some/path helm init --client-only ``` diff --git a/docs/plugins.md b/docs/plugins.md index 3087d1b39..ffd6999f6 100644 --- a/docs/plugins.md +++ b/docs/plugins.md @@ -33,7 +33,7 @@ plugins do the "detail work" of performing a desired action. Plugins are installed using the `$ helm plugin install ` 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 ``` diff --git a/docs/quickstart.md b/docs/quickstart.md index ef3cb460e..3e343a838 100644 --- a/docs/quickstart.md +++ b/docs/quickstart.md @@ -24,7 +24,7 @@ that `kubectl` uses. To find out which cluster Tiller would install to, you can run `kubectl config current-context` or `kubectl cluster-info`. -```console +```bash $ kubectl config current-context my-cluster ``` @@ -53,7 +53,7 @@ guide](install.md). Once you have Helm ready, you can initialize the local CLI and also install Tiller into your Kubernetes cluster in one step: -```console +```bash $ 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 of the official `stable` charts. -```console +```bash $ helm repo update # Make sure we get the latest list of charts $ helm install stable/mysql NAME: wintering-rodent @@ -154,7 +154,7 @@ Guide](using_helm.md) It's easy to see what has been released using Helm: -```console +```bash $ helm ls 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 @@ -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: -```console +```bash $ helm delete wintering-rodent release "wintering-rodent" deleted ``` @@ -174,7 +174,7 @@ release "wintering-rodent" deleted This will uninstall `wintering-rodent` from Kubernetes, but you will still be able to request information about that release: -```console +```bash $ helm status wintering-rodent LAST DEPLOYED: Thu Oct 18 14:21:18 2018 NAMESPACE: default @@ -220,6 +220,6 @@ rollback`). To learn more about the available Helm commands, use `helm help` or type a command followed by the `-h` flag: -```console +```bash $ helm get -h ``` diff --git a/docs/rbac.md b/docs/rbac.md index 4b39ecdc6..daf2a25dd 100644 --- a/docs/rbac.md +++ b/docs/rbac.md @@ -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._ -```console +```bash $ kubectl create -f rbac-config.yaml serviceaccount "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. -```console +```bash $ kubectl create namespace tiller-world namespace "tiller-world" created $ kubectl create serviceaccount tiller --namespace tiller-world @@ -71,7 +71,7 @@ rules: verbs: ["*"] ``` -```console +```bash $ kubectl create -f role-tiller.yaml role "tiller-manager" created ``` @@ -94,14 +94,14 @@ roleRef: apiGroup: rbac.authorization.k8s.io ``` -```console +```bash $ kubectl create -f rolebinding-tiller.yaml rolebinding "tiller-binding" created ``` 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_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`. -```console +```bash $ kubectl create namespace myorg-system namespace "myorg-system" created $ kubectl create serviceaccount tiller --namespace myorg-system @@ -147,7 +147,7 @@ rules: verbs: ["*"] ``` -```console +```bash $ kubectl create -f role-tiller.yaml role "tiller-manager" created ``` @@ -170,7 +170,7 @@ roleRef: apiGroup: rbac.authorization.k8s.io ``` -```console +```bash $ kubectl create -f rolebinding-tiller.yaml rolebinding "tiller-binding" created ``` @@ -189,7 +189,7 @@ rules: verbs: ["*"] ``` -```console +```bash $ kubectl create -f role-tiller-myorg-system.yaml role "tiller-manager" created ``` @@ -212,7 +212,7 @@ roleRef: apiGroup: rbac.authorization.k8s.io ``` -```console +```bash $ kubectl create -f rolebinding-tiller-myorg-system.yaml rolebinding "tiller-binding" created ``` @@ -268,7 +268,7 @@ subjects: namespace: helm-world ``` -```console +```bash $ kubectl create -f helm-user.yaml serviceaccount "helm" created role "tiller-user" created diff --git a/docs/tiller_ssl.md b/docs/tiller_ssl.md index 41e704653..4ce4ee8d3 100644 --- a/docs/tiller_ssl.md +++ b/docs/tiller_ssl.md @@ -46,7 +46,7 @@ consult other resources. The simplest way to generate a certificate authority is to run two commands: -```console +```bash $ 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 Enter pass phrase for ca.key.pem: @@ -88,7 +88,7 @@ same time. The names will indicate their target. First, the Tiller key: -```console +```bash $ openssl genrsa -out ./tiller.key.pem 4096 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: -```console +```bash $ openssl genrsa -out ./helm.key.pem 4096 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 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 Enter pass phrase for tiller.key.pem: 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: -```console +```bash $ openssl req -key helm.key.pem -new -sha256 -out helm.csr.pem # 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): -```console +```bash $ openssl x509 -req -CA ca.cert.pem -CAkey ca.key.pem -CAcreateserial -in tiller.csr.pem -out tiller.cert.pem -days 365 Signature ok 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: -```console +```bash $ 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: -```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 ``` @@ -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 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 ``` In a minute or two it should be ready. We can check Tiller like this: -```console +```bash $ kubectl -n kube-system get deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE ... other stuff @@ -227,7 +227,7 @@ cert and the key. At this point, you should get a _failure_ when you run basic Helm commands: -```console +```bash $ helm ls 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 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 ``` @@ -254,7 +254,7 @@ Tiller's identity. Typing a line that is cumbersome, though. The shortcut is to move the key, cert, and CA into `$HELM_HOME`: -```console +```bash $ cp ca.cert.pem $(helm home)/ca.pem $ cp helm.cert.pem $(helm home)/cert.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: -```console +```bash $ 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 ``` diff --git a/docs/using_helm.md b/docs/using_helm.md index 79b5aef6f..de10cb64c 100755 --- a/docs/using_helm.md +++ b/docs/using_helm.md @@ -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`: -```console +```bash $ helm search NAME VERSION DESCRIPTION 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 can narrow down your results by searching with a filter: -```console +```bash $ helm search mysql NAME VERSION DESCRIPTION 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 MySQL. We can use `helm inspect chart` to see this: -```console +```bash $ helm inspect stable/mariadb Fetched stable/mariadb to mariadb-0.5.1.tgz 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 simplest, it takes only one argument: The name of the chart. -```console +```bash $ helm install stable/mariadb Fetched stable/mariadb-0.3.0 to /Users/mattbutcher/Code/Go/src/k8s.io/helm/mariadb-0.3.0.tgz 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 information, you can use `helm status`: -```console +```bash $ helm status happy-panda Last Deployed: Wed Sep 28 12:32:28 2016 Namespace: default @@ -179,7 +179,7 @@ to use your preferred configuration. To see what options are configurable on a chart, use `helm inspect values`: -```console +```bash 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 ## 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, and then pass that file during installation. -```console +```bash $ cat << EOF > config.yaml mariadbUser: user0 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 update things that have changed since the last release. -```console +```bash $ 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 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 effect. -```console +```bash $ helm get values happy-panda 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 roll back to a previous release using `helm rollback [RELEASE] [REVISION]`. -```console +```bash $ 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 the `helm delete` command: -```console +```bash $ helm delete happy-panda ``` This will remove the release from the cluster. You can see all of your currently deployed releases with the `helm list` command: -```console +```bash $ helm list NAME VERSION UPDATED STATUS CHART 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, as well as releases that failed): -```console +```bash ⇒ helm list --all NAME VERSION UPDATED STATUS CHART 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`: -```console +```bash $ helm repo list NAME URL 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`: -```console +```bash $ 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` command: -```console +```bash $ helm create 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 `helm package` command: -```console +```bash $ helm package deis-workflow deis-workflow-0.1.0.tgz ``` And that chart can now easily be installed by `helm install`: -```console +```bash $ helm install ./deis-workflow-0.1.0.tgz ... ```