add Helm template values article

SUMMARY.md

@@ -7,6 +7,9 @@
 ### Docker 基础
 * [Docker 简介](docs/2.Docker 简介.md)
 * [镜像和容器的基本操作](docs/3.镜像和容器的基本操作.md)
+* [Dockerfile 定制镜像](docs/4.Dockerfile 定制镜像.md)
+* [私有镜像仓库](docs/5.私有镜像仓库.md)
+* [数据共享与持久化](docs/6.数据共享与持久化.md)
 
 ### kubeadm 搭建集群
 * [使用 kubeadm 搭建集群环境](docs/16.用 kubeadm 搭建集群环境.md)
@@ -49,3 +52,4 @@
 ### 包管理工具 Helm
 * [Helm 的安装使用](docs/42.Helm安装.md)
 * [Helm 的基本使用](docs/43.Helm基本使用.md)
+* [Helm 模板之内置函数和Values](docs/44.Helm模板之内置函数和Values.md)

docs/36.Jenkins Slave.md

 # 基于 Jenkins 的 CI/CD (一)
-前面的课程中我们学习了持久化数据存储在`Kubernetes`中的使用方法，其实接下来按照我们的课程进度来说应该是讲解服务发现这一部分的内容的，但是最近有很多同学要求我先讲解下 CI/CD 这块的内容，所以我们先把这块内容提前来讲解了。提到基于`Kubernete`的`CI/CD`，可以使用的工具有很多，比如`Jenkins`、`Gitlab CI`已经新兴的`drone`之类的，我们这里会使用大家最为熟悉的`Jenins`来做`CI/CD`的工具。
+前面的课程中我们学习了持久化数据存储在`Kubernetes`中的使用方法，其实接下来按照我们的课程进度来说应该是讲解服务发现这一部分的内容的，但是最近有很多同学要求我先讲解下 CI/CD 这块的内容，所以我们先把这块内容提前来讲解了。提到基于`Kubernete`的`CI/CD`，可以使用的工具有很多，比如`Jenkins`、`Gitlab CI`已经新兴的`drone`之类的，我们这里会使用大家最为熟悉的`Jenkins`来做`CI/CD`的工具。
 
 ## 安装
 听我们课程的大部分同学应该都或多或少的听说过`Jenkins`，我们这里就不再去详细讲述什么是 Jenkins 了，直接进入正题，后面我们会单独的关于 Jenkins 的学习课程，想更加深入学习的同学也可以关注下。既然要基于`Kubernetes`来做`CI/CD`，当然我们这里需要将 Jenkins 安装到 Kubernetes 集群当中，新建一个 Deployment：(jenkins2.yaml)

docs/4.Dockerfile 定制镜像.md

+# 4. Dockerfile 定制镜像
+从前面一节的`docker commit`的学习中，我们可以了解到，镜像的定制实际上就是定制每一层所添加的配置、文件等信息，但是命令毕竟只是命令，每次定制都得去重复执行这个命令，而且还不够直观，如果我们可以把每一层修改、安装、构建、操作的命令都写入一个脚本，用这个脚本来构建、定制镜像，那么这些问题不就都可以解决了吗？对的，这个脚本就是我们说的`Dockerfile`。
+
+## 介绍
+Dockerfile 是一个文本文件，其内包含了一条条的指令(Instruction)，每一条指令构建一层，因此每一条指令的内容，就是描述该层应当如何构建。
+
+还以之前定制 nginx 镜像为例，这次我们使用 Dockerfile 来定制。在一个空白目录中，建立一个文本文件，并命名为 Dockerfile：
+```shell
+$ mkdir mynginx
+$ cd mynginx
+$ touch Dockerfile
+```
+
+其内容为：
+```docker
+FROM nginxRUN echo '<h1>Hello, Docker!</h1>' > /usr/share/nginx/html/index.html
+```
+这个 Dockerfile 很简单，一共就两行。涉及到了两条指令，FROM 和 RUN。
+
+## FROM 指定基础镜像
+所谓定制镜像，那一定是以一个镜像为基础，在其上进行定制。就像我们之前运行了一个 nginx 镜像的容器，再进行修改一样，基础镜像是必须指定的。而`FROM`就是指定基础镜像，因此一个 Dockerfile 中 FROM 是必备的指令，并且必须是第一条指令。
+
+在[Docker Store](https://store.docker.com/)上有非常多的高质量的官方镜像，有可以直接拿来使用的服务类的镜像，如 nginx、redis、mongo、mysql、httpd、php、tomcat 等；也有一些方便开发、构建、运行各种语言应用的镜像，如 node、openjdk、python、ruby、golang 等。可以在其中寻找一个最符合我们最终目标的镜像为基础镜像进行定制。
+
+如果没有找到对应服务的镜像，官方镜像中还提供了一些更为基础的操作系统镜像，如 ubuntu、debian、centos、fedora、alpine 等，这些操作系统的软件库为我们提供了更广阔的扩展空间。
+
+除了选择现有镜像为基础镜像外，Docker 还存在一个特殊的镜像，名为`scratch`。这个镜像是虚拟的概念，并不实际存在，它表示一个空白的镜像。
+```docker
+FROM scratch
+...
+```
+
+如果你以`scratch`为基础镜像的话，意味着你不以任何镜像为基础，接下来所写的指令将作为镜像第一层开始存在。有的同学可能感觉很奇怪，没有任何基础镜像，我怎么去执行我的程序呢，其实对于 Linux 下静态编译的程序来说，并不需要有操作系统提供运行时支持，所需的一切库都已经在可执行文件里了，因此直接`FROM scratch`会让镜像体积更加小巧。使用 Go 语言 开发的应用很多会使用这种方式来制作镜像，这也是为什么有人认为 Go 是特别适合容器微服务架构的语言的原因之一。
+
+## RUN 执行命令
+`RUN`指令是用来执行命令行命令的。由于命令行的强大能力，`RUN`指令在定制镜像时是最常用的指令之一。其格式有两种：
+
+* shell 格式：RUN <命令>，就像直接在命令行中输入的命令一样。刚才写的 Dockerfile 中的 RUN 指令就是这种格式。
+```shell
+RUN echo '<h1>Hello, Docker!</h1>' > /usr/share/nginx/html/index.html
+```
+* exec 格式：RUN ["可执行文件", "参数1", "参数2"]，这更像是函数调用中的格式。
+既然 RUN 就像 Shell 脚本一样可以执行命令，那么我们是否就可以像 Shell 脚本一样把每个命令对应一个 RUN 呢？比如这样：
+```docker
+FROM debian:jessie
+RUN apt-get update
+RUN apt-get install -y gcc libc6-dev make
+RUN wget -O redis.tar.gz "http://download.redis.io/releases/redis-3.2.5.tar.gz"
+RUN mkdir -p /usr/src/redis
+RUN tar -xzf redis.tar.gz -C /usr/src/redis --strip-components=1
+RUN make -C /usr/src/redis
+RUN make -C /usr/src/redis install
+```
+
+之前说过，Dockerfile 中每一个指令都会建立一层，RUN 也不例外。每一个 RUN 的行为，就和刚才我们手工建立镜像的过程一样：新建立一层，在其上执行这些命令，执行结束后，commit 这一层的修改，构成新的镜像。
+
+而上面的这种写法，创建了 7 层镜像。这是完全没有意义的，而且很多运行时不需要的东西，都被装进了镜像里，比如编译环境、更新的软件包等等。结果就是产生非常臃肿、非常多层的镜像，不仅仅增加了构建部署的时间，也很容易出错。 这是很多初学 Docker 的人常犯的一个错误。
+
+> Union FS 是有最大层数限制的，比如 AUFS，曾经是最大不得超过 42 层，现在是不得超过 127 层。
+
+上面的 Dockerfile 正确的写法应该是这样：
+```docker
+FROM debian:jessie
+RUN buildDeps='gcc libc6-dev make' \
+    && apt-get update \
+    && apt-get install -y $buildDeps \
+    && wget -O redis.tar.gz "http://download.redis.io/releases/redis-3.2.5.tar.gz" \
+    && mkdir -p /usr/src/redis \
+    && tar -xzf redis.tar.gz -C /usr/src/redis --strip-components=1 \
+    && make -C /usr/src/redis \
+    && make -C /usr/src/redis install \
+    && rm -rf /var/lib/apt/lists/* \
+    && rm redis.tar.gz \
+    && rm -r /usr/src/redis \
+    && apt-get purge -y --auto-remove $buildDeps
+```
+
+首先，之前所有的命令只有一个目的，就是编译、安装 redis 可执行文件。因此没有必要建立很多层，这只是一层的事情。因此，这里没有使用很多个 RUN 对一一对应不同的命令，而是仅仅使用一个 RUN 指令，并使用`&&`将各个所需命令串联起来。将之前的 7 层，简化为了 1 层。在撰写 Dockerfile 的时候，要经常提醒自己，这并不是在写 Shell 脚本，而是在定义每一层该如何构建。
+
+并且，这里为了格式化还进行了换行。Dockerfile 支持 Shell 类的行尾添加`\`的命令换行方式，以及行首`#`进行注释的格式。良好的格式，比如换行、缩进、注释等，会让维护、排障更为容易，这是一个比较好的习惯。
+
+此外，还可以看到这一组命令的最后添加了清理工作的命令，删除了为了编译构建所需要的软件，清理了所有下载、展开的文件，并且还清理了 apt 缓存文件。这是很重要的一步，我们之前说过，镜像是多层存储，每一层的东西并不会在下一层被删除，会一直跟随着镜像。因此镜像构建时，一定要确保每一层只添加真正需要添加的东西，任何无关的东西都应该清理掉。
+很多人初学 Docker 制作出了很臃肿的镜像的原因之一，就是忘记了每一层构建的最后一定要清理掉无关文件。
+
+## 构建镜像
+好了，让我们再回到之前定制的 nginx 镜像的 Dockerfile 来。现在我们明白了这个 `Dockerfile`的内容，那么让我们来构建这个镜像吧。在 Dockerfile 文件所在目录执行：
+```shell
+$ docker build -t nginx:v3 .
+Sending build context to Docker daemon 2.048 kB
+Step 1 : FROM nginx
+ ---> e43d811ce2f4
+Step 2 : RUN echo '<h1>Hello, Docker!</h1>' > /usr/share/nginx/html/index.html
+ ---> Running in 9cdc27646c7b
+ ---> 44aa4490ce2c
+Removing intermediate container 9cdc27646c7b
+Successfully built 44aa4490ce2c
+```
+
+从命令的输出结果中，我们可以清晰的看到镜像的构建过程。在 Step 2 中，如同我们之前所说的那样，RUN 指令启动了一个容器 9cdc27646c7b，执行了所要求的命令，并最后提交了这一层 44aa4490ce2c，随后删除了所用到的这个容器 9cdc27646c7b。这里我们使用了 `docker build`命令进行镜像构建。其格式为：
+```shell
+$ docker build [选项] <上下文路径/URL/->
+```
+
+在这里我们指定了最终镜像的名称 -t nginx:v3，构建成功后，我们可以像之前运行 nginx:v2 那样来运行这个镜像，其结果会和 nginx:v2 一样。
+
+## 镜像构建上下文（Context）
+如果注意，会看到 docker build 命令最后有一个`.`。`.`表示当前目录，而 Dockerfile 就在当前目录，因此不少初学者以为这个路径是在指定 Dockerfile 所在路径，这么理解其实是不准确的。如果对应上面的命令格式，你可能会发现，这是在指定上下文路径。那么什么是上下文呢？
+
+首先我们要理解 docker build 的工作原理。Docker 在运行时分为 Docker 引擎（也就是服务端守护进程）和客户端工具。Docker 的引擎提供了一组 REST API，被称为 Docker Remote API，而如 docker 命令这样的客户端工具，则是通过这组 API 与 Docker 引擎交互，从而完成各种功能。因此，虽然表面上我们好像是在本机执行各种 docker 功能，但实际上，一切都是使用的远程调用形式在服务端（Docker 引擎）完成。也因为这种 C/S 设计，让我们操作远程服务器的 Docker 引擎变得轻而易举。
+
+当我们进行镜像构建的时候，并非所有定制都会通过 RUN 指令完成，经常会需要将一些本地文件复制进镜像，比如通过 COPY 指令、ADD 指令等。而 docker build 命令构建镜像，其实并非在本地构建，而是在服务端，也就是 Docker 引擎中构建的。那么在这种客户端/服务端的架构中，如何才能让服务端获得本地文件呢？
+
+这就引入了上下文的概念。当构建的时候，用户会指定构建镜像上下文的路径，docker build 命令得知这个路径后，会将路径下的所有内容打包，然后上传给 Docker 引擎。这样 Docker 引擎收到这个上下文包后，展开就会获得构建镜像所需的一切文件。如果在 Dockerfile 中这么写：
+```docker
+COPY ./package.json /app/
+```
+
+这并不是要复制执行 docker build 命令所在的目录下的 package.json，也不是复制 Dockerfile 所在目录下的 package.json，而是复制 上下文（context） 目录下的 package.json。
+
+因此，`COPY`这类指令中的源文件的路径都是相对路径。这也是初学者经常会问的为什么 COPY ../package.json /app 或者 COPY /opt/xxxx /app 无法工作的原因，因为这些路径已经超出了上下文的范围，Docker 引擎无法获得这些位置的文件。如果真的需要那些文件，应该将它们复制到上下文目录中去。
+
+现在就可以理解刚才的命令`docker build -t nginx:v3 .`中的这个`.`，实际上是在指定上下文的目录，docker build 命令会将该目录下的内容打包交给 Docker 引擎以帮助构建镜像。
+
+如果观察 docker build 输出，我们其实已经看到了这个发送上下文的过程：
+```shell
+$ docker build -t nginx:v3 .
+Sending build context to Docker daemon 2.048 kB
+...
+```
+
+理解构建上下文对于镜像构建是很重要的，可以避免犯一些不应该的错误。比如有些初学者在发现 COPY /opt/xxxx /app 不工作后，于是干脆将 Dockerfile 放到了硬盘根目录去构建，结果发现 docker build 执行后，在发送一个几十 GB 的东西，极为缓慢而且很容易构建失败。那是因为这种做法是在让 docker build 打包整个硬盘，这显然是使用错误。
+
+一般来说，应该会将 Dockerfile 置于一个空目录下，或者项目根目录下。如果该目录下没有所需文件，那么应该把所需文件复制一份过来。如果目录下有些东西确实不希望构建时传给 Docker 引擎，那么可以用 .gitignore 一样的语法写一个`.dockerignore`，该文件是用于剔除不需要作为上下文传递给 Docker 引擎的。
+
+那么为什么会有人误以为 **.** 是指定 Dockerfile 所在目录呢？这是因为在默认情况下，如果不额外指定 Dockerfile 的话，会将上下文目录下的名为 Dockerfile 的文件作为 Dockerfile。
+
+这只是默认行为，实际上 Dockerfile 的文件名并不要求必须为 Dockerfile，而且并不要求必须位于上下文目录中，比如可以用`-f ../Dockerfile.php`参数指定某个文件作为 Dockerfile。
+
+当然，一般大家习惯性的会使用默认的文件名 Dockerfile，以及会将其置于镜像构建上下文目录中。
+
+## 迁移镜像
+Docker 还提供了`docker load`和`docker save`命令，用以将镜像保存为一个 tar 文件，然后传输到另一个位置上，再加载进来。这是在没有 Docker Registry 时的做法，现在已经不推荐，镜像迁移应该直接使用 Docker Registry，无论是直接使用 Docker Hub 还是使用内网私有 Registry 都可以。
+
+使用`docker save`命令可以将镜像保存为归档文件。比如我们希望保存这个 alpine 镜像。
+```shell
+$ docker image ls alpine
+REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
+alpine              latest              baa5d63471ea        5 weeks ago         4.803 MB
+```
+
+保存镜像的命令为：
+```shell
+$ docker save alpine | gzip > alpine-latest.tar.gz
+```
+
+然后我们将 alpine-latest.tar.gz 文件复制到了到了另一个机器上，可以用下面这个命令加载镜像：
+```shell
+$ docker load -i alpine-latest.tar.gz
+Loaded image: alpine:latest
+```
+
+如果我们结合这两个命令以及 ssh 甚至 pv 的话，利用 Linux 强大的管道，我们可以写一个命令完成从一个机器将镜像迁移到另一个机器，并且带进度条的功能：
+```shell
+docker save <镜像名> | bzip2 | pv | ssh <用户名>@<主机名> 'cat | docker load'
+```

docs/44.Helm模板之内置函数和Values.md

+# 44. Helm 模板之内置函数和Values
+上节课和大家一起学习了`Helm`的一些常用操作方法，这节课来和大家一起定义一个`chart`包，了解 Helm 中模板的一些使用方法。
+
+
+## 定义 chart
+Helm 的 github 上面有一个比较[完整的文档](https://github.com/kubernetes/helm/blob/master/docs/charts.md)，建议大家好好阅读下该文档，这里我们来一起创建一个`chart`包。
+
+一个 chart 包就是一个文件夹的集合，文件夹名称就是 chart 包的名称，比如创建一个 mychart 的 chart 包：
+```shell
+$ helm create mychart
+Creating mychart
+$ tree mychart/
+mychart/
+├── charts
+├── Chart.yaml
+├── templates
+│   ├── deployment.yaml
+│   ├── _helpers.tpl
+│   ├── ingress.yaml
+│   ├── NOTES.txt
+│   └── service.yaml
+└── values.yaml
+
+2 directories, 7 files
+```
+
+chart 包的目录上节课我们就已经学习过了，这里我们再来仔细看看 templates 目录下面的文件:
+
+* NOTES.txt：chart 的 “帮助文本”。这会在用户运行 helm install 时显示给用户。
+* deployment.yaml：创建 Kubernetes deployment 的基本 manifest
+* service.yaml：为 deployment 创建 service 的基本 manifest
+* ingress.yaml: 创建 ingress 对象的资源清单文件
+* _helpers.tpl：放置模板助手的地方，可以在整个 chart 中重复使用
+
+这里我们明白每一个文件是干嘛的就行，然后我们把 templates 目录下面所有文件全部删除掉，这里我们自己来创建模板文件：
+```shell
+$ rm -rf mychart/templates/*.*
+```
+
+## 创建模板
+这里我们来创建一个非常简单的模板 ConfigMap，在 templates 目录下面新建一个`configmap.yaml`文件：
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: mychart-configmap
+data:
+  myvalue: "Hello World"
+```
+
+实际上现在我们就有一个可安装的 chart 包了，通过`helm install`命令来进行安装：
+```shell
+$ helm install ./mychart/
+NAME:   ringed-lynx
+LAST DEPLOYED: Fri Sep  7 22:59:22 2018
+NAMESPACE: default
+STATUS: DEPLOYED
+
+RESOURCES:
+==> v1/ConfigMap
+NAME               DATA  AGE
+mychart-configmap  1     0s
+```
+
+在上面的输出中，我们可以看到我们的 ConfigMap 资源对象已经创建了。然后使用如下命令我们可以看到实际的模板被渲染过后的资源文件：
+```shell
+$ helm get manifest ringed-lynx
+
+---
+# Source: mychart/templates/configmap.yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: mychart-configmap
+data:
+  myvalue: "Hello World"
+```
+
+现在我们看到上面的 ConfigMap 文件是不是正是我们前面在模板文件中设计的，现在我们删除当前的`release`:
+```shell
+$ helm delete ringed-lynx
+release "ringed-lynx" deleted
+```
+
+## 添加一个简单的模板
+我们可以看到上面我们定义的 ConfigMap 的名字是固定的，但往往这并不是一种很好的做法，我们可以通过插入 release 的名称来生成资源的名称，比如这里 ConfigMap 的名称我们希望是：ringed-lynx-configmap，这就需要用到 Chart 的模板定义方法了。
+
+Helm Chart 模板使用的是[`Go`语言模板](https://golang.org/pkg/text/template/)编写而成，并添加了[`Sprig`库](https://github.com/Masterminds/sprig)中的50多个附件模板函数以及一些其他[特殊的函](https://github.com/kubernetes/helm/blob/master/docs/charts_tips_and_tricks.md)。
+
+> 需要注意的是`kubernetes`资源对象的 labels 和 name 定义被[限制 63个字符](http://kubernetes.io/docs/user-guide/labels/#syntax-and-character-set)，所以需要注意名称的定义。
+
+现在我们来重新定义下上面的 configmap.yaml 文件：
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: {{ .Release.Name }}-configmap
+data:
+  myvalue: "Hello World"
+```
+
+我们将名称替换成了`{{ .Release.Name }}-configmap`，其中包含在`{{`和`}}`之中的就是模板指令，`{{ .Release.Name }}` 将 release 的名称注入到模板中来，这样最终生成的 ConfigMap 名称就是以 release 的名称开头的了。这里的 Release 模板对象属于 Helm 内置的一种对象，还有其他很多内置的对象，稍后我们将接触到。
+
+现在我们来重新安装我们的 Chart 包，注意观察 ConfigMap 资源对象的名称：
+```shell
+$ helm install ./mychart
+helm install ./mychart/
+NAME:   quoting-zebra
+LAST DEPLOYED: Fri Sep  7 23:20:12 2018
+NAMESPACE: default
+STATUS: DEPLOYED
+
+RESOURCES:
+==> v1/ConfigMap
+NAME                     DATA  AGE
+quoting-zebra-configmap  1     0s
+
+```
+
+可以看到现在生成的名称变成了**quoting-zebra-configmap**，证明已经生效了，当然我们也可以使用命令`helm get manifest quoting-zebra`查看最终生成的清单文件的样子。
+
+## 调试
+我们用模板来生成资源文件的清单，但是如果我们想要调试就非常不方便了，不可能我们每次都去部署一个`release`实例来校验模板是否正确，所幸的时 Helm 为我们提供了`--dry-run --debug`这个可选参数，在执行`helm install`的时候带上这两个参数就可以把对应的 values 值和生成的最终的资源清单文件打印出来，而不会真正的去部署一个`release`实例，比如我们来调试上面创建的 chart 包：
+```shell
+$ helm install . --dry-run --debug ./mychart
+[debug] Created tunnel using local port: '35286'
+
+[debug] SERVER: "127.0.0.1:35286"
+
+[debug] Original chart version: ""
+[debug] CHART PATH: /root/course/kubeadm/helm/mychart
+
+NAME:   wrapping-bunny
+REVISION: 1
+RELEASED: Fri Sep  7 23:23:09 2018
+CHART: mychart-0.1.0
+USER-SUPPLIED VALUES:
+{}
+
+COMPUTED VALUES:
+...
+HOOKS:
+MANIFEST:
+
+---
+# Source: mychart/templates/configmap.yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: wrapping-bunny-configmap
+data:
+  myvalue: "Hello World"
+```
+
+现在我们使用`--dry-run`就可以很容易地测试代码了，不需要每次都去安装一个 release 实例了，但是要注意的是这不能确保 Kubernetes 本身就一定会接受生成的模板，在调试完成后，还是需要去安装一个实际的 release 实例来进行验证的。
+
+## 内置对象
+刚刚我们使用`{{.Release.Name}}`将 release 的名称插入到模板中。这里的 Release 就是 Helm 的内置对象，下面是一些常用的内置对象，在需要的时候直接使用就可以：
+
+* **Release**：这个对象描述了 release 本身。它里面有几个对象：
+    * Release.Name：release 名称
+    * Release.Time：release 的时间
+    * Release.Namespace：release 的 namespace（如果清单未覆盖）
+    * Release.Service：release 服务的名称（始终是 Tiller）。
+    * Release.Revision：此 release 的修订版本号，从1开始累加。
+    * Release.IsUpgrade：如果当前操作是升级或回滚，则将其设置为 true。
+    * Release.IsInstall：如果当前操作是安装，则设置为 true。
+
+* **Values**：从`values.yaml`文件和用户提供的文件传入模板的值。默认情况下，Values 是空的。
+* Chart：`Chart.yaml`文件的内容。所有的 Chart 对象都将从该文件中获取。chart 指南中[Charts Guide](https://github.com/kubernetes/helm/blob/master/docs/charts.md#the-chartyaml-file)列出了可用字段，可以前往查看。
+
+* Files：这提供对 chart 中所有非特殊文件的访问。虽然无法使用它来访问模板，但可以使用它来访问 chart 中的其他文件。请参阅 "访问文件" 部分。
+    * Files.Get 是一个按名称获取文件的函数（.Files.Get config.ini）
+    * Files.GetBytes 是将文件内容作为字节数组而不是字符串获取的函数。这对于像图片这样的东西很有用。
+
+* Capabilities：这提供了关于 Kubernetes 集群支持的功能的信息。
+    * Capabilities.APIVersions 是一组版本信息。
+    * Capabilities.APIVersions.Has $version 指示是否在群集上启用版本（batch/v1）。
+    * Capabilities.KubeVersion 提供了查找 Kubernetes 版本的方法。它具有以下值：Major，Minor，GitVersion，GitCommit，GitTreeState，BuildDate，GoVersion，Compiler，和 Platform。
+    * Capabilities.TillerVersion 提供了查找 Tiller 版本的方法。它具有以下值：SemVer，GitCommit，和 GitTreeState。
+
+* Template：包含有关正在执行的当前模板的信息
+
+* Name：到当前模板的文件路径（例如 mychart/templates/mytemplate.yaml）
+
+* BasePath：当前 chart 模板目录的路径（例如 mychart/templates）。
+
+上面这些值可用于任何顶级模板，要注意内置值始终以大写字母开头。这也符合`Go`的命名约定。当你创建自己的名字时，你可以自由地使用适合你的团队的惯例。
+
+## values 文件
+上面的内置对象中有一个对象就是 Values，该对象提供对传入 chart 的值的访问，Values 对象的值有4个来源：
+
+* chart 包中的 values.yaml 文件
+* 父 chart 包的 values.yaml 文件
+* 通过 helm install 或者 helm upgrade 的`-f`或者`--values`参数传入的自定义的 yaml 文件(上节课我们已经学习过)
+* 通过`--set` 参数传入的值
+
+chart 的 values.yaml 提供的值可以被用户提供的 values 文件覆盖，而该文件同样可以被`--set`提供的参数所覆盖。
+
+这里我们来重新编辑 mychart/values.yaml 文件，将默认的值全部清空，添加一个新的数据：(values.yaml)
+```yaml
+course: k8s
+```
+
+然后我们在上面的 templates/configmap.yaml 模板文件中就可以使用这个值了：(configmap.yaml)
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: {{ .Release.Name }}-configmap
+data:
+  myvalue: "Hello World"
+  course: {{ .Values.course }}
+```
+
+可以看到最后一行我们是通过`{{ .Values.course }}`来获取 course 的值的。现在我们用 debug 模式来查看下我们的模板会被如何渲染：
+```shell
+$ helm install --dry-run --debug ./mychart
+helm install --dry-run --debug .
+[debug] Created tunnel using local port: '33509'
+
+[debug] SERVER: "127.0.0.1:33509"
+
+[debug] Original chart version: ""
+[debug] CHART PATH: /root/course/kubeadm/helm/mychart
+
+NAME:   nasal-anaconda
+REVISION: 1
+RELEASED: Sun Sep  9 17:37:52 2018
+CHART: mychart-0.1.0
+USER-SUPPLIED VALUES:
+{}
+
+COMPUTED VALUES:
+course: k8s
+
+HOOKS:
+MANIFEST:
+
+---
+# Source: mychart/templates/configmap.yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: nasal-anaconda-configmap
+data:
+  myvalue: "Hello World"
+  course: k8s
+```
+
+我们可以看到 ConfigMap 中 course 的值被渲染成了 k8s，这是因为在默认的 values.yaml 文件中该参数值为 k8s，同样的我们可以通过`--set`参数来轻松的覆盖 course 的值：
+```shell
+$ helm install --dry-run --debug --set course=python ./mychart
+[debug] Created tunnel using local port: '44571'
+
+......
+
+---
+# Source: mychart/templates/configmap.yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: named-scorpion-configmap
+data:
+  myvalue: "Hello World"
+  course: python
+```
+
+由于`--set` 比默认 values.yaml 文件具有更高的优先级，所以我们的模板生成为 course: python。
+
+values 文件也可以包含更多结构化内容，例如，我们在 values.yaml 文件中可以创建 course  部分，然后在其中添加几个键：
+```yaml
+course:
+  k8s: devops
+  python: django
+```
+
+现在我们稍微修改模板：
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: {{ .Release.Name }}-configmap
+data:
+  myvalue: "Hello World"
+  k8s: {{ .Values.course.k8s }}
+  python: {{ .Values.course.python }}
+```
+
+同样可以使用 debug 模式查看渲染结果：
+```shell
+$ helm install --dry-run --debug ./mychart
+[debug] Created tunnel using local port: '33801'
+......
+---
+# Source: mychart/templates/configmap.yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: exhaling-turtle-configmap
+data:
+  myvalue: "Hello World"
+  k8s: devops
+  python: django
+```
+
+可以看到模板中的参数已经被 values.yaml 文件中的值给替换掉了。虽然以这种方式构建数据是可以的，但我们还是建议保持 value 树浅一些，平一些，这样维护起来要简单一点。
+
+到这里，我们已经看到了几个内置对象的使用方法，并用它们将信息注入到了模板之中。下节课我们来看看模板引擎中的其他用法，比如**函数、管道、控制结构**等等的用法。

docs/5.私有镜像仓库.md

+# 5. 私有镜像仓库
+这节课给大家讲讲私有镜像仓库的使用。
+
+## Docker Hub
+目前 Docker 官方维护了一个公共仓库`Docker Hub`，大部分需求都可以通过在 Docker Hub 中直接下载镜像来实现。如果你觉得拉取 Docker Hub 的镜像比较慢的话，我们可以配置一个镜像加速器：[http://docker-cn.com/](http://docker-cn.com/)，当然国内大部分云厂商都提供了相应的加速器，简单配置即可。
+
+### 注册
+你可以在 [https://cloud.docker.com](https://cloud.docker.com) 免费注册一个 Docker 账号。
+
+### 登录
+通过执行`docker login`命令交互式的输入用户名及密码来完成在命令行界面登录 Docker Hub。
+
+
+### 注销
+你可以通过`docker logout`退出登录。
+拉取镜像
+
+### 拉取镜像
+你可以通过`docker search`命令来查找官方仓库中的镜像，并利用`docker pull`命令来将它下载到本地。
+
+例如以 centos 为关键词进行搜索：
+```shell
+$ docker search centos
+NAME                                            DESCRIPTION                                     STARS     OFFICIAL   AUTOMATED
+centos                                          The official build of CentOS.                   465       [OK]
+tianon/centos                                   CentOS 5 and 6, created using rinse instea...   28
+blalor/centos                                   Bare-bones base CentOS 6.5 image                6                    [OK]
+saltstack/centos-6-minimal                                                                      6                    [OK]
+tutum/centos-6.4                                DEPRECATED. Use tutum/centos:6.4 instead. ...   5                    [OK]
+```
+
+可以看到返回了很多包含关键字的镜像，其中包括镜像名字、描述、收藏数（表示该镜像的受关注程度）、是否官方创建、是否自动创建。
+
+官方的镜像说明是官方项目组创建和维护的，`automated`资源允许用户验证镜像的来源和内容。
+
+根据是否是官方提供，可将镜像资源分为两类。
+
+* 一种是类似 centos 这样的镜像，被称为基础镜像或根镜像。这些基础镜像由 Docker 公司创建、验证、支持、提供。这样的镜像往往使用单个单词作为名字。
+* 还有一种类型，比如 tianon/centos 镜像，它是由 Docker 的用户创建并维护的，往往带有用户名称前缀。可以通过前缀`username/`来指定使用某个用户提供的镜像，比如 tianon 用户。
+
+另外，在查找的时候通过`--filter=stars=N`参数可以指定仅显示收藏数量为 N 以上的镜像。下载官方 centos 镜像到本地。
+```shell
+$ docker pull centos
+Pulling repository centos
+0b443ba03958: Download complete
+539c0211cd76: Download complete
+511136ea3c5a: Download complete
+7064731afe90: Download complete
+```
+
+### 推送镜像
+用户也可以在登录后通过`docker push`命令来将自己的镜像推送到 Docker Hub。以下命令中的 username 请替换为你的 Docker 账号用户名。
+```shell
+$ docker tag ubuntu:17.10 username/ubuntu:17.10
+$ docker image ls
+
+REPOSITORY                                               TAG                    IMAGE ID            CREATED             SIZE
+ubuntu                                                   17.10                  275d79972a86        6 days ago          94.6MB
+username/ubuntu                                          17.10                  275d79972a86        6 days ago          94.6MB
+$ docker push username/ubuntu:17.10
+$ docker search username
+
+NAME                      DESCRIPTION                                     STARS               OFFICIAL            AUTOMATED
+username/ubuntu
+```
+
+## 私有仓库
+有时候使用 Docker Hub 这样的公共仓库可能不方便，用户可以创建一个本地仓库供私人使用。
+
+`docker-registry`是官方提供的工具，可以用于构建私有的镜像仓库。本文内容基于 docker-registry v2.x 版本。你可以通过获取官方 registry 镜像来运行。
+```shell
+$ docker run -d -p 5000:5000 --restart=always --name registry registry
+```
+
+这将使用官方的`registry`镜像来启动私有仓库。默认情况下，仓库会被创建在容器的`/var/lib/registry`目录下。你可以通过 -v 参数来将镜像文件存放在本地的指定路径。例如下面的例子将上传的镜像放到本地的 /opt/data/registry 目录。
+```shell
+$ docker run -d \
+    -p 5000:5000 \
+    -v /opt/data/registry:/var/lib/registry \
+    registry
+```
+
+### 在私有仓库上传、搜索、下载镜像
+创建好私有仓库之后，就可以使用`docker tag`来标记一个镜像，然后推送它到仓库。例如私有仓库地址为 127.0.0.1:5000。先在本机查看已有的镜像。
+```shell
+$ docker image ls
+REPOSITORY                        TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
+ubuntu                            latest              ba5877dc9bec        6 weeks ago         192.7 MB
+```
+
+使用`docker tag`将 ubuntu:latest 这个镜像标记为 127.0.0.1:5000/ubuntu:latest。
+格式为 docker tag IMAGE[:TAG] [REGISTRY_HOST[:REGISTRY_PORT]/]REPOSITORY[:TAG]
+```shell
+$ docker tag ubuntu:latest 127.0.0.1:5000/ubuntu:latest
+$ docker image ls
+REPOSITORY                        TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
+ubuntu                            latest              ba5877dc9bec        6 weeks ago         192.7 MB
+127.0.0.1:5000/ubuntu:latest      latest              ba5877dc9bec        6 weeks ago         192.7 MB
+```
+
+使用`docker push`上传标记的镜像。
+```shell
+$ docker push 127.0.0.1:5000/ubuntu:latest
+The push refers to repository [127.0.0.1:5000/ubuntu]
+373a30c24545: Pushed
+a9148f5200b0: Pushed
+cdd3de0940ab: Pushedfc56279bbb33: Pushed
+b38367233d37: Pushed
+2aebd096e0e2: Pushed
+latest: digest: sha256:fe4277621f10b5026266932ddf760f5a756d2facd505a94d2da12f4f52f71f5a size: 1568
+```
+
+用`curl`查看仓库中的镜像。
+```shell
+$ curl 127.0.0.1:5000/v2/_catalog
+{"repositories":["ubuntu"]}
+```
+
+这里可以看到 {"repositories":["ubuntu"]}，表明镜像已经被成功上传了。
+
+先删除已有镜像，再尝试从私有仓库中下载这个镜像。
+```shell
+$ docker image rm 127.0.0.1:5000/ubuntu:latest
+
+$ docker pull 127.0.0.1:5000/ubuntu:latest
+Pulling repository 127.0.0.1:5000/ubuntu:latest
+ba5877dc9bec: Download complete
+511136ea3c5a: Download complete
+9bad880da3d2: Download complete
+25f11f5fb0cb: Download complete
+ebc34468f71d: Download complete
+2318d26665ef: Download complete
+
+$ docker image ls
+REPOSITORY                         TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
+127.0.0.1:5000/ubuntu:latest       latest              ba5877dc9bec        6 weeks ago         192.7 MB
+```
+
+## 注意事项
+如果你不想使用 127.0.0.1:5000 作为仓库地址，比如想让本网段的其他主机也能把镜像推送到私有仓库。你就得把例如 192.168.199.100:5000 这样的内网地址作为私有仓库地址，这时你会发现无法成功推送镜像。
+
+这是因为 Docker 默认不允许非 HTTPS 方式推送镜像。我们可以通过 Docker 的配置选项来取消这个限制。
+
+### Ubuntu 14.04, Debian 7 Wheezy
+对于使用 upstart 的系统而言，编辑`/etc/default/docker`文件，在其中的`DOCKER_OPTS`中增加如下内容：
+```shell
+DOCKER_OPTS="--registry-mirror=https://registry.docker-cn.com --insecure-registries=192.168.199.100:5000"
+```
+
+重新启动服务:
+```shell
+$ sudo service docker restart
+```
+
+### Ubuntu 16.04+, Debian 8+, centos 7
+对于使用 systemd 的系统，请在`/etc/docker/daemon.json`中写入如下内容（如果文件不存在请新建该文件）
+```shell
+{
+  "registry-mirror": [
+    "https://registry.docker-cn.com"
+  ],
+  "insecure-registries": [
+    "192.168.199.100:5000"
+  ]
+}
+```
+
+> 注意：该文件必须符合`json`规范，否则 Docker 将不能启动。
+
+### 其他
+对于 Docker for Windows、Docker for Mac 在设置中编辑`daemon.json`增加和上边一样的字符串即可。
+

docs/6.数据共享与持久化.md

+# 6. 数据共享与持久化
+这一节介绍如何在 Docker 内部以及容器之间管理数据，在容器中管理数据主要有两种方式：
+
+* 数据卷（Data Volumes）
+* 挂载主机目录 (Bind mounts)
+
+## 数据卷
+`数据卷`是一个可供一个或多个容器使用的特殊目录，它绕过`UFS`，可以提供很多有用的特性：
+
+* 数据卷 可以在容器之间共享和重用
+* 对 数据卷 的修改会立马生效
+* 对 数据卷 的更新，不会影响镜像
+* 数据卷 默认会一直存在，即使容器被删除
+
+> 注意：数据卷 的使用，类似于 Linux 下对目录或文件进行 mount，镜像中的被指定为挂载点的目录中的文件会隐藏掉，能显示看的是挂载的 数据卷。
+
+选择 -v 还是 -–mount 参数：
+Docker 新用户应该选择`--mount`参数，经验丰富的 Docker 使用者对`-v`或者 `--volume`已经很熟悉了，但是推荐使用`--mount`参数。
+
+创建一个数据卷：
+```shell
+$ docker volume create my-vol
+```
+
+查看所有的 数据卷：
+```shell
+$ docker volume ls
+local               my-vol
+```
+
+在主机里使用以下命令可以查看指定 数据卷 的信息
+```shell
+$ docker volume inspect my-vol
+[
+    {
+        "Driver": "local",
+        "Labels": {},
+        "Mountpoint": "/var/lib/docker/volumes/my-vol/_data",
+        "Name": "my-vol",
+        "Options": {},
+        "Scope": "local"
+    }
+]
+```
+
+启动一个挂载数据卷的容器：在用`docker run`命令的时候，使用`--mount`标记来将 数据卷 挂载到容器里。在一次`docker run`中可以挂载多个 数据卷。下面创建一个名为 web 的容器，并加载一个 数据卷 到容器的 /webapp 目录。
+```shell
+$ docker run -d -P \
+    --name web \
+    # -v my-vol:/wepapp \
+    --mount source=my-vol,target=/webapp \
+    training/webapp \
+    python app.py
+```
+
+查看数据卷的具体信息：在主机里使用以下命令可以查看 web 容器的信息
+```shell
+$ docker inspect web
+...
+"Mounts": [
+    {
+        "Type": "volume",
+        "Name": "my-vol",
+        "Source": "/var/lib/docker/volumes/my-vol/_data",
+        "Destination": "/app",
+        "Driver": "local",
+        "Mode": "",
+        "RW": true,
+        "Propagation": ""
+    }
+],
+...
+```
+
+删除数据卷：
+```
+$ docker volume rm my-vol
+```
+
+数据卷 是被设计用来持久化数据的，它的生命周期独立于容器，Docker 不会在容器被删除后自动删除 数据卷，并且也不存在垃圾回收这样的机制来处理没有任何容器引用的 数据卷。如果需要在删除容器的同时移除数据卷。可以在删除容器的时候使用`docker rm -v`这个命令。
+无主的数据卷可能会占据很多空间，要清理请使用以下命令
+```
+$ docker volume prune
+```
+
+## 挂载主机目录
+选择 -v 还是 -–mount 参数：
+Docker 新用户应该选择 --mount 参数，经验丰富的 Docker 使用者对 -v 或者 --volume 已经很熟悉了，但是推荐使用 --mount 参数。
+
+挂载一个主机目录作为数据卷：使用 `--mount` 标记可以指定挂载一个本地主机的目录到容器中去。
+```shell
+$ docker run -d -P \
+    --name web \
+    # -v /src/webapp:/opt/webapp \
+    --mount type=bind,source=/src/webapp,target=/opt/webapp \
+    training/webapp \
+    python app.py
+```
+上面的命令加载主机的 /src/webapp 目录到容器的 /opt/webapp目录。这个功能在进行测试的时候十分方便，比如用户可以放置一些程序到本地目录中，来查看容器是否正常工作。本地目录的路径必须是绝对路径，以前使用 -v 参数时如果本地目录不存在 Docker 会自动为你创建一个文件夹，现在使用 --mount 参数时如果本地目录不存在，Docker 会报错。
+
+Docker 挂载主机目录的默认权限是 读写，用户也可以通过增加`readonly`指定为 只读。
+```shell
+$ docker run -d -P \
+    --name web \
+    # -v /src/webapp:/opt/webapp:ro \
+    --mount type=bind,source=/src/webapp,target=/opt/webapp,readonly \
+    training/webapp \
+    python app.py
+```
+
+加了`readonly`之后，就挂载为 只读 了。如果你在容器内 /opt/webapp 目录新建文件，会显示如下错误:
+```shell
+/opt/webapp # touch new.txt
+touch: new.txt: Read-only file system
+```
+
+查看数据卷的具体信息：在主机里使用以下命令可以查看 web 容器的信息
+```shell
+$ docker inspect web
+...
+"Mounts": [
+    {
+        "Type": "bind",
+        "Source": "/src/webapp",
+        "Destination": "/opt/webapp",
+        "Mode": "",
+        "RW": true,
+        "Propagation": "rprivate"
+    }
+],
+```
+
+挂载一个本地主机文件作为数据卷：`--mount`标记也可以从主机挂载单个文件到容器中
+```shell
+$ docker run --rm -it \
+   # -v $HOME/.bash_history:/root/.bash_history \
+   --mount type=bind,source=$HOME/.bash_history,target=/root/.bash_history \
+   ubuntu:17.10 \
+   bash
+
+root@2affd44b4667:/# history
+1  ls
+2  diskutil list
+```
+
+这样就可以记录在容器输入过的命令了。
+

docs/test.md

+# 44. Helm 模板使用
+上节课和大家一起学习了`Helm`的一些常用操作方法，这节课来和大家一起定义一个`chart`包，了解 Helm 中模板的使用方法。
+
+
+## 定义 chart
+Helm 的 github 上面有一个比较[完整的文档](https://github.com/kubernetes/helm/blob/master/docs/charts.md)，建议大家好好阅读下该文档，这里我们来一起创建一个`chart`包。
+
+一个 chart 包就是一个文件夹的集合，文件夹名称就是 chart 包的名称，比如创建一个 hello-world 的 chart 包：
+```shell
+$ mkdir ./hello-world
+$ cd hello-world
+```
+
+chart 必须包含定义文件`Chart.yaml`文件，定义文件必须定义两个属性：`name`和`version`(Semantic Versioning 2):
+```shell
+$ cat <<'EOF' > ./Chart.yaml
+name: hello-world
+version: 1.0.0
+EOF
+```
+
+一个 chart 包必须定义用来生成`kubernetes`资源对象的模板文件，这些模板文件定义在 templates 目录下面，这里我们来尝试使用 helm 自定义一个 nginx 服务：
+```shell
+$ mkdir ./templates
+$ cat <<'EOF' > ./templates/deployment.yaml
+apiVersion: extensions/v1beta1
+kind: Deployment
+metadata:
+  name: hello-world
+spec:
+  replicas: 1
+  template:
+    metadata:
+      labels:
+        app: hello-world
+    spec:
+      containers:
+        - name: hello-world
+          image: nginx:1.7.9
+          ports:
+            - containerPort: 80
+              protocol: TCP
+EOF
+$ cat <<'EOF' > ./templates/service.yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: hello-world
+spec:
+  type: NodePort
+  ports:
+  - port: 80
+    targetPort: 80
+    protocol: TCP
+  selector:
+    app: hello-world
+EOF
+```
+
+上面我们定义的模板是最终一个`release`实例需要运行的资源对象，一个`Deployment`对象，一个`Service`对象，也是以前我们运行一个 nginx 服务需要的两个资源对象。
+
+## 配置 release
+上节课我们学习了管理一个 release 整个生命周期的一些方法，install、rollback、upgrade 以及 delete 等等操作，但是仅仅这些命令还不够，我们还需要一些工具来管理`release`。
+
+Helm Chart 模板使用的是[`Go`语言模板](https://golang.org/pkg/text/template/)编写而成，并添加了[`Sprig`库](https://github.com/Masterminds/sprig)中的50多个附件模板函数以及一些其他[特殊的函](https://github.com/kubernetes/helm/blob/master/docs/charts_tips_and_tricks.md)。
+
+模板的值通过`values.yaml`文件提供，现在我们来定义一个`values.yaml`文件，提供 image 镜像的仓库配置：
+```shell
+$ cat <<'EOF' > ./values.yaml
+image:
+  repository: nginx
+  tag: 1.7.9
+EOF
+```
+
+现在我们就可以通过模板中的`.Values`对象来访问`values.yaml`文件提供的值。比如我们将上面的`templates/deployment.yaml`文件中的`image`镜像地址通过`values.yaml`中的`image`对象来替换掉：
+```shell
+$ cat <<'EOF' > ./templates/deployment.yaml
+apiVersion: extensions/v1beta1
+kind: Deployment
+metadata:
+  name: hello-world
+spec:
+  replicas: 1
+  template:
+    metadata:
+      labels:
+        app: hello-world
+    spec:
+      containers:
+        - name: hello-world
+          image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
+          ports:
+            - containerPort: 80
+              protocol: TCP
+EOF
+```
+
+## 调试
+现在我们的模板文件已经定义好了，但是如果我们想要调试还是非常不方便的，不可能我们每次都去部署一个`release`实例来校验模板是否正确，为此 Helm 为我们提供了`--dry-run --debug`这个可选参数，在执行`helm install`的时候带上这两个参数就可以把对应的 values 值和生成的最终的资源清单文件打印出来，而不会真正的去部署一个`release`实例，比如我们来调试上面创建的 chart 包：
+```shell
+$ helm install . --dry-run --debug --set image.tag=latest
+[debug] Created tunnel using local port: '38359'
+
+[debug] SERVER: "127.0.0.1:38359"
+
+[debug] Original chart version: ""
+[debug] CHART PATH: /root/course/kubeadm/helm/hello-world
+
+NAME:   calling-turkey
+REVISION: 1
+RELEASED: Fri Sep  7 23:57:45 2018
+CHART: hello-world-1.0.0
+USER-SUPPLIED VALUES:
+image:
+  tag: latest
+
+COMPUTED VALUES:
+image:
+  repository: nginx
+  tag: latest
+
+HOOKS:
+MANIFEST:
+
+---
+# Source: hello-world/templates/service.yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: hello-world
+spec:
+  type: NodePort
+  ports:
+  - port: 80
+    targetPort: 80
+    protocol: TCP
+  selector:
+    app: hello-world
+---
+# Source: hello-world/templates/deployment.yaml
+apiVersion: extensions/v1beta1
+kind: Deployment
+metadata:
+  name: hello-world
+spec:
+  replicas: 1
+  template:
+    metadata:
+      labels:
+        app: hello-world
+    spec:
+      containers:
+        - name: hello-world
+          image: nginx:latest
+          ports:
+            - containerPort: 80
+              protocol: TCP
+```
+
+注意看上面的镜像地址已经被替换成了**nginx:latest**了，这是因为我们用`--set`参数把镜像的 tag 给覆盖掉了，而镜像名称已经被 values.yaml 中的内容替换掉了。
+
+现在我们使用`--dry-run`就可以很容易地测试代码了，不需要每次都去安装一个 release 实例了，但是要注意的是这不能确保 Kubernetes 本身就一定会接受生成的模板，在调试完成后，还是需要去安装一个实际的 release 实例来进行验证的。
+
+
+## 预定义值
+除了使用用户定义的值外，Helm 还内置了许多预定义的值，我们可以在 [Helm 的文档中进行查看]((https://github.com/kubernetes/helm/blob/master/docs/charts.md#predefined-values)，比如chang'y常用的有：
+
+* .Release，这个对象描述了 release 本身，提供了比如：.Release.Name(release 名称)、.Release.Time(release 的时间)
+* .Chart，表示`Chart.yaml`文件的内容。所有的 Chart 对象都将从该文件中访问。chart 指南中[Charts Guide](https://github.com/kubernetes/helm/blob/master/docs/charts.md#the-chartyaml-file)列出了可用字段，可以前往查看。
+* Files：用于引用 Chart 目录中的其他文件。
+
+现在我们来使用预定义的值给上面的资源文件定义一些标签，让我们可以很方便的识别出资源：
+```shell
+$ cat <<'EOF' > ./templates/deployment.yaml
+apiVersion: extensions/v1beta1
+kind: Deployment
+metadata:
+  name: {{ printf "%s-%s" .Release.Name .Chart.Name | trunc 63 }}
+  labels:
+    app: {{ printf "%s-%s" .Release.Name .Chart.Name | trunc 63 }}
+    version: {{ .Chart.Version }}
+    release: {{ .Release.Name }}
+spec:
+  replicas: 1
+  template:
+    metadata:
+      labels:
+        app: {{ printf "%s-%s" .Release.Name .Chart.Name | trunc 63 }}
+        version: {{ .Chart.Version }}
+        release: {{ .Release.Name }}
+    spec:
+      containers:
+        - name: hello-world
+          image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
+          ports:
+            - containerPort: 80
+              protocol: TCP
+EOF
+$ cat <<'EOF' > ./templates/service.yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: {{ printf "%s-%s" .Release.Name .Chart.Name | trunc 63 }}
+  labels:
+    app: {{ printf "%s-%s" .Release.Name .Chart.Name | trunc 63 }}
+    version: {{ .Chart.Version }}
+    release: {{ .Release.Name }}
+spec:
+  type: NodePort
+  ports:
+  - port: 80
+    targetPort: 80
+    protocol: TCP
+  selector:
+    app: {{ printf "%s-%s" .Release.Name .Chart.Name | trunc 63 }}
+EOF
+```
+
+我们这里使用`.Release.Name`并上`.Chart.Name`来做为资源的名称：
+```
+{{ printf "%s-%s" .Release.Name .Chart.Name | trunc 63 }}
+```
+
+这里我们加上了一个63个字符的截断，这是因为`kubernetes`资源对象的 labels 和 name 定义被[限制为 63个字符](http://kubernetes.io/docs/user-guide/labels/#syntax-and-character-set)，所以需要注意名称的定义长度。
+
+
+## 模板引用
+我们上面定义的模板文件中，可能有的人已经发现了，我们的 labels 定义以及资源名称的定义很多都是重复的：
+```yaml
+app: {{ printf "%s-%s" .Release.Name .Chart.Name | trunc 63 }}
+version: {{ .Chart.Version }}
+release: {{ .Release.Name }}
+```
+
+我们在 Deployment、Pod、Service 资源对象中都定义了3个相同的 label 标签，而资源名称都是一个比较长的表达式：
+```yaml
+{{ printf "%s-%s" .Release.Name .Chart.Name | trunc 63 }}
+```
+
+如果应用程序非常复杂的话，这种重复的属性就更多了，这显然不是一种很好的方式，如果我们去掉这些 label 标签呢？当然可以，但是这对于资源对象的辨别就会显得困难了。这里我们可以定义一些模板文件来进行引用，就可以很好的解决这个问题。
+
+创建一个`_helpers.tpl`文件用来声明模板中的一部分内容：
+
+> 主意：./templates 目录中已`_`开头的文件不会被看做 kubernetes 的资源清单文件，这些文件不会被发送到 kubernetes 中去。
+
+```shell
+$ cat <<'EOF'> ./templates/_helpers.tpl
+{{- define "hello-world.release_labels" }}
+app: {{ printf "%s-%s" .Release.Name .Chart.Name | trunc 63 }}
+version: {{ .Chart.Version }}
+release: {{ .Release.Name }}
+{{- end }}
+
+{{- define "hello-world.full_name" -}}
+{{- printf "%s-%s" .Release.Name .Chart.Name | trunc 63 -}}
+{{- end -}}
+EOF
+```
+
+上面的文件中我们就定义了两个模块：**hello-world.release_labels**和**hello-world.full_name**，这两个模块都可以在模板中进行使用：
+
+> 模板名称都是全局的。由于子 chart 中的模板与顶级模板一起编译，所以需要注意 chart 的命名，这也是为什么
+
+```shell
+$ cat <<'EOF' > ./templates/deployment.yaml
+apiVersion: extensions/v1beta1
+kind: Deployment
+metadata:
+  name: {{ template "hello-world.full_name" . }}
+  labels:
+    {{- include "hello-world.release_labels" . | indent 4 }}
+spec:
+  replicas: 1
+  template:
+    metadata:
+      labels:
+        {{- include "hello-world.release_labels" . | indent 8 }}
+    spec:
+      containers:
+        - name: hello-world
+          image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
+          ports:
+            - containerPort: 80
+              protocol: TCP
+EOF
+$ cat <<'EOF' > ./templates/service.yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: {{ template "hello-world.full_name" . }}
+  labels:
+    {{- include "hello-world.release_labels" . | indent 4 }}
+spec:
+  type: NodePort
+  ports:
+  - port: 80
+    targetPort: 80
+    protocol: TCP
+  selector:
+    app: {{ template "hello-world.full_name" . }}
+EOF
+```
\ No newline at end of file