关于 Docker 容器配置信息的渐进式思考

作为一名软件工程师，不，或许应该叫做 YAML 工程师、Markdown 工程师、Dockerfile 工程师……等等，这绝非自谦，更多的是一种自嘲。毕竟，从入行的那一天开始，追求配置上的动态灵活，就如同思想一般刻进每个程序员的 DNA 里。可当你意识到，在这个世界上，提出主张的人和解决问题的人，并不是同一群人时，你或许会心头一紧，接着便是直呼上当，我甚至不能理解，为什么程序员提交完代码，还要像运维一样折腾各种配置文件。特别是在 DevOps 的理念流行开以后，程序员们简直就是在通过各种配置文件互相折磨对方。如果程序员不能通过程序变得懒惰，那是不是说明，我们早已忘记了当初学习编程时的初心？我们都以为代码可以不用修改，可有哪一次代码能逃过面目全非的结局？每当这个时候，我就特别想怼那些主张配置文件的人，要不您来？言归正传，今天我想聊聊容器、配置文件和环境变量，为什么称为渐进式思考呢？因为它更像是一种不同人生阶段的回顾。

从何说起

故老相传，鸿蒙初开，天地混沌。上帝说，要有光。于是，盘古抄起那把传说中的开天神斧，对着虚空世界就是一通输出。那一刻，这位创世神周围就像发生了奇点大爆炸一样迅速扩张。最终，它的身体化作了世间万物，推动这个世界从无到有的进化历程。屏幕前的你，无需纠结这段融合了东/西方神话、现代物理学的表述是否严谨，因为我想说的是，在一个事物发展的初期，一定是朴素而且原始的。相信大家开始写 Dockerfile 的时候，一定没少写过下面这样的脚本：

COPY /config/nginx.conf /etc/nginx/nginx.conf
1

如你所见，该命令会复制主机上的配置文件到容器的指定目录，而这其实是符合我们一开始对容器的预期的，即：我们只需要将程序打包到镜像里，就可以快速地完成程序的部署。可是，我们显然忽略了一个问题，当程序部署到不同的环境中时，它需要的配置文件自然是不同的。此时，你可能会采用下面的做法：

docker exec -it <容器Id> sh
vim /etc/nginx/nginx.conf
1
2

环境变量

果然，大道至简，没有任何技巧，简直真诚到极致。常言道：智者不入爱河，这个做法辛不辛苦姑且不论，关键是容器一旦重启，你连慨叹镜花水月的时间都没有啦。所以，这个方案可谓是劳心劳力，为我所不取也！再后来，你发现容器里可以使用环境变量，于是你就灵机一动，为什么不能让这个配置文件支持动态配置呢？于是，你尝试使用下面的做法：

server {
    listen      ${NGINX_PORT};
    listen      [::]:${NGINX_PORT};
    server_name ${NGINX_HOST};

    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }
}
1
2
3
4
5
6
7
8
9
10

此时，我们只需要在 .env 文件或者 docker-compose.yml 文件里指定这些环境变量即可。对于这个思路，我们可以使用 envsubst 这个工具来实现：

export NGINX_PORT=80
export NGINX_HOST=xyz.com
apt-get update && apt-get install -y gettext-base
envsubst < /config/nginx.conf > /etc/nginx/nginx.conf
1
2
3
4

此时，我们会发现，它可以实现环境变量的“注入”：

当然，如果这段脚本是写在 RUN 指令后面，那么，这个改进是非常有限的。因为如果你希望更新配置，你必须要重新构建一个镜像，一个更好的做法是，将这段脚本放到 CMD 或者 ENTRYPOINT 指令里。这样，我们更新配置时只需要重启容器即可，这是不是就符合配置上的动态灵活了呢？事实上，这正是博主公司一直采用的做法。不过，运维同事大概率是没听说过 envsubst 这个工具，他使用的是更朴素的