Kubernetes 1.2 新功能解析：ConfigMap (下)

Kubernetes 1.2版本添加了一个叫ConfigMap的新功能。这个功能提供给容器注入应用程序数据的方式。注入配置文件对于大部分应用程序来说很强大，但是新的ConfigMap功能不仅可以在容器开启时提供初始配置功能，还有在容器运行时更新自身配置的功能。在这篇帖子里，我将会给大家展示如何编写微服务来利用更新好的配置，并且在fly上面重构你的service。

让我们来看看监控配置文件变化的简单网页app是怎么样的。

这个app有趣部分是ConfigManager 和 WatchFile.

ConfigManager的工作就是提供访问我们的 Config{}的路径结构，这样的话当Kubernetes ConfigMap给我们一个新的配置文件版本或者我们更新 Config{} 对象时候，竞争冲突不存在。

WatchFile的工作就是为作出的修改查看我们的配置文件，并且运行读取配置文件的新版本回调函数，使用ConfigManager设置新的 Config{} 。

让我们看一下ConfigManager的安装启用。

这里是我们使用一个简单的Mutex用来避免竞争冲突的例子。通常你想要避免使用Mutex，然后使用建立在channel里面的golang。但是既然管理员的工作是保护配置对象的实例，那么使用Mutex也还是可以接受的。

怀着好奇心，我创建了一个这个对象的golang channel安装启用，然后运行一些基准点。你可以点击（点我）找到代码和基准点测试。

Mutex版本没有死锁的风险，很高效。而 FileWatcher的实施会较复杂一点。它的目标是使任意额外的fsnotify events成为一个单独更新的event，这样我们只要执行一次回调函数。查看完整代码请点击这里（点我）
有意思的部分是 run()函数执行在线程中，然后运行回调函数。

你可能会觉得代码应该寻找 fsnotify.Writeevents而不是fsnotify.Remove，然而……ConfigMap所呈现给应用程序的配置文件事实上是一个连接到我们配置文件的符号链接，而不是一个文件。当ConfigMap更新时，Kubernetes AtomicWriter()就可以实现强大的ConfigMap更新。

为了做到这样，AtomicWriter()创建了一个新的目录；编写更新好的ConfigMap内容到新的目录。一旦编写完成，那么它就会移动原始配置文件符号链接，然后用新的指向最新创建目录符号链接替换它。

我们的代码处理方式理论上应该是监控我们的配置文件符号链接，而不是为events的真实文件。然而，fsnotify.v1并不允许我们提交IN_DONT_FOLLOW标志到inotify，inotify允许我们为修改监控符号链接。但是fsnotify取消引用符号链接，然后为events监控真实文件。这不太可能作出修改，因为fsnotify是为跨平台设计的，而且不是所有的平台都支持符号链接。

我继续使用fsnotify函数库，因为对于我来说，用它在osx上开发，在容器上部署都比较方便。以Linux为中心的实施应该直接使用"golang.org/x/exp/inotify"数据库。
现在我们有了我们的代码，我们可以创建一个Docker镜像然后更新到Docker hub，为部署在我们Kubernetes集群做好准备。

假设你已经建立起了一个Kubernetes集群；让我们来创建一个ConfigMap配置，然后用我们的容器来使用它。

创建ConfigMap

首先，我们创建一个密钥清单文件

这个定义了一个新的叫做configmap-microservice-demo的ConfigMap，它包括了 data:配置文件名字叫做configmap-microservice-demo.yaml
它的内容是message: Hello World。
使用 kubectl来创建ConfigMap。

你可以检测到最新的创建好的ConfigMap

接下来我们来定义一个Replication Controller密钥清单来运行我们的应用程序容器。

有趣的地方就是volumes:和volumeMounts:，这两者告诉运行在节点上的kubelet哪里可以安装我们的配置文件。当我们的容器运行的时候；数据卷插件会在我们的容器中安装一个叫做/etc/config的目录，然后在这里面替换我们的配置文件configmap-microservice-demo.yaml。
从我们的容器观点角度看，我们的配置文件完整途径将会是：/etc/config/configmap-microservice-demo.yaml

现在让我们来创建Replication Controller。

我们现在可以检查我们正在运行的pods来寻找我们新pod的IP地址。

现在如果你登录到我们集群中的一个节点，我们在集群里可以用pod的IP地址从任何地方来访问应用程序。

如果这个部分让你很困惑，你可以点击这篇博客（点我），它对于Kubernetes网络是如何运行的有很深层次的指导意义。这个是官方文档（点我）。

更新ConfigMap

现在为了有趣的部分，让我们来更新我们的配置，部署修改到ConfigMap。
让我们打开原始的ConfigMap密钥清单文件，然后修改我们的message: Hello World到message:Hello Grandma。

用我们更新的版本替代目前的ConfigMap

我们可以验证到，通过在configmap资源上执行get，更新很成功。

我们的应用程序很快得到了更新后的配置，我们可以通过看日志就来验证。

现在我们可以在集群里面curl我们的应用程序，我们应该看到更新的配置反应在我们的应用程序里。

你可以登录到我们的容器正在运行的节点，然后检查直接检查配置文件。Kubernetes将目录安装在/var/lib/kubelet/pods/<pod-id>/volumes/kubernetes.io~configmap/config-volume。

查看完整代码点击这里：点我

（如果需要转载，请联系我们哦，尊重知识产权人人有责）