容器配置修改的方法的思考

最近，产品的服务都在容器化或者向容器化过渡，会涉及到容器配置修改的问题。

一般情况下，一个应用程序的配置可能存储在以下一些位置：

1. 配置文件
2. 数据库 （需要设置数据库地址和用户名密码）
3. 环境变量
4. 命令行参数 （其实也算环境变量）

在使用容器的情况下，这些配置可以通过以下方法来进行配置：

1. 配置文件

如果配置文件不需要修改，可以将配置文件直接放在容器里面。如果需要修改配置，考虑从宿主机挂载一个主机绝对路径来覆盖相关目录。

另外一种方式是，使用docker 创建一个volume，使用本地磁盘驱动的情况下本质上是一个在docker中指定了名字的本地路径，将相关配置放置在此，通过volume名字挂载到容器内部。

2. 数据库

数据库同样可以运行在容器中或者跑在其他服务器上，其本身就是一个基于网络的服务程序。需要提供的是数据库地址和相关的访问权限，这个参数还是需要通过文件或者环境变量的方式来进行配置。

3. 环境变量及命令行

这些参数都可以通过Docker Compose的参数或者Docker命令行传入。

因此，目前来看，这些机制用来存储一些非安全性的配置是够用的。但是，就目前我看到的资料，docker本身似乎没有提供对需要加密数据的存储机制。比如 “docker secret ”命令，是需要配合swarm来使用。而k8s中的的secret更是需要配合k8s使用。

在K8S中，使用ConfigMap对象来存储非安全敏感的配置数据。ConfigMap是K8S设计用来存储配置的键值对对象，可以用来配置容器的环境变量和命令行参数。配置文件同样可以被导成ConfigMap对象，键值是文件名，内容则是文件内容。

从这里看，非需保密的配置可以通过映射目录，docker volume挂载和K8S ConfigMap来完成。

目前处于过渡阶段的我们，可以考虑让产品使用外挂配置文件的方式来使用配置，在后期转到K8S平台上之后，采用将配置文件转换成ConfigMap的方式来进行适配。