❶ Docker映射配置文件到宿主机
最近在做mysql中间件的docker，搞了mycat、mysql route都拉不起来容器，最后试试proxysql可以，proxysql官方发布了镜像，感觉比较可靠。但是遇到一个小问题，笔者以前写过一篇文章-Docker MySQL数据持久化，用数据卷挂载的方式将mysql的数据（映射数据目录）持久化到宿主机。那么配置文件也是有必要来映射的，注意就可以避免在容器内安装编辑器。
容器内有apt 和ap-get工具，安装前要apt update（或者apt-get update，较慢）更新软件列表，然后apt install（或者apt-get install），这样会增大容器空间，是没有必要的。笔者以前就是这样操作的，但是比较麻烦，而且容器如果是内部网络的话来安装的话就更加不方便了。笔者在映射数据目录时使用-v /home/mysql/data:/var/lib/mysql 。但是使用同样的分发，今天在映射proxysql的配置文件proxysql.cnf时遇到一个麻烦。
先看看笔者挂载时遇到的问题： Are you trying to mount a directory onto a file。
都是文件，那里来的目录呢。映射的意思是将可以将宿主机目录挂载到容器中，那么可能就是将/home/mycentos/proxysql.cnf设别为一个目录了，因为容器内/etc/proxysql.cnf的是真实存在的文件。在/home/mycentos/目录下ls -l查看一下。
果然是目录！辗转反侧找到原因是 docker启动容器进行挂载的时候,如果路径不存在,那么docker会自动创建一个目录。
笔者的home/mycentos/目录下没有proxysql.cnf文件，挂载时docker就新建了一个proxysql.cnf的目录，但是这个对于挂载数据目录时是十分有用的，对于配置文件来说是不行的。于是笔者在目录home/mycentos/下新建了一个proxysql.cnf文件，再次运行docker run成功（前面运行失败的容器需要删除，不然名称冲突）。
docker run -itd --name proxysql -p 16032:6032 -p 16033:6033 -p 16070:6070 -v /home/mycentos/proxysql.cnf:/etc/proxysql.cnf proxysql/proxysql
挂载后，容器内的/etc/proxysql.cnf配置文件是空的，不挂载的情况下是保持默认配置文件内容的，使用徐需要在编辑/home/mycentos/proxysql.cnf文件，然后进入容器后/etc/proxysql.cnf配置文件会跟随改变的。但是配置文件为空，那么就要从头开始配置，这对于配置文件很多的话是不方便的，保留原来的配置配置文件，再在里面修改会更加方便。这里笔者只能想到先运行一个容器，然后docker cp拷贝容器内的文件或者文件夹，在删除这个容器，另外开一个配置文件映射的容器。
映射配置文件避免在容器内进行apt操作，使得容器膨胀过大。比如你要安装编辑器vi，首先要apt update更新，然后apt install ，相比于在容器外对其进行操作来说，更加麻烦没必要。
❷ docker常用文件映射方式-bind vs volume
Docker中，数据持久化是常见需求。官方推荐的文件映射方式是通过volume（数据卷）。volume是一种独立于容器生命周期的存储，它可以跨容器复用，提供了更好的数据管理和隔离性。然而，在实际操作中，许多人更倾向于使用bind（-v挂载）方式，直接将本地磁盘挂载到容器中。
bind挂载允许你直接映射容器的文件系统到主机的目录，优点在于操作简便，适合临时数据或开发环境，因为数据更改会立即反映到宿主机。然而，bind方式存在数据丢失风险，因为容器的生命周期结束后，映射的本地文件可能会被删除。
相比之下，volume的优势在于它创建了一个独立的存储空间，容器重启或删除后，volume中的数据仍会保留。这对于需要长期存储或需要数据持久化的场景更为合适。此外，volume还可以在多个容器间共享，提高了资源利用率。
总结来说，选择bind还是volume取决于你的具体需求。如果追求便捷性和开发环境的实时反馈，bind可能是首选；而对数据持久性、复用性和安全性有更高要求的生产环境，volume则更为理想。官方推荐volume，是基于其在大规模部署和数据管理上的优势。