项目背景
为了节约成本，我的阿里云硬盘 只配了最低档 20GiB ，由于想在云服上再搭一些服务，所以需要降一些硬盘利用率，清理一下云服务器上的文件。
目标选择
在 / 目录下，用 du -sh * 扫描一遍各个文件夹的大小，对一些大小不符合预期的文件夹进行排查。
排查中发现两个问题：
- MySQL的安装文件夹（
/usr/local/mysql）过大，1.3GiB左右
上个月我刚用docker在自己的虚拟机里，创建了MariaDB的镜像，我清楚地记得MariaDB、MySQL的image大概都是400MiB左右，云服上的MySQL竟然有它的3倍！不行，我得换docker版的。 - MySQL的数据文件夹中发现了binlog
binlog的问题，我当初安装LNMP环境时，就按照一直以来的偷懒方法，使用 oneinstack 作为环境，一键安装，安装后只针对性能方面，简单调调线程、内存等配置，的确没一行一行地看默认的参数配置，也没考虑是不是要开binlog。对我目前来说，我没有binlog的使用场景，也不需要主从同步，我选择关掉binlog。
计划实施
因为这次是MySQL跨版本升级（相当于5.7->8.0）所以决定不使用原来的数据库文件了，直接创建一个新数据库，然后用mysqldump把表迁移过去。
遇到的问题
在迁移 Wordpress 的数据库连接时，在数据库中，我创建的用户是'wpDbUser'@'127.0.0.1'，Wordpress的连接设置为define("DB_HOST", "127.0.0.1:3306")，访问站点提示“数据库连接错误”，打开debug模式后，发现MariaDB返回错误'wpDbUser'@'172.20.0.1'不允许登录
后来我使用DataGrip，在我的笔记本上进行测试，我首先创建了一个SSH代理，然后通过localhost:3306登录用户'wpDbUser'@'127.0.0.1'、'wpDbUser'@'localhost'最终都会被指向'wpDbUser'@'172.20.0.1'，经过docker bridge network后，在容器内的应用看来，发起访问的IP是主机的docker IP，而不是用户的真实IP。
为了解决这个问题，我有几个方案：
- 方案一：将用户改为
'wpDbUser'@'172.20.0.1'
我使用的是docker的bridge网络，每次重启，容器的IP可能会发生变化，如果每次重启都需要改MySQL的用户的话，我觉得这种方案不能接受。 - 方案二：使用docker host网络
MariaDB作为一个我经常使用的基础组件，它需要一个灵活的网络环境，有必要直接访问我的网络资源。 - 方案三：将PHP环境容器化，并加入DBnetwork网络，通过容器名进行网络访问
这个方案我感觉行不通，如果PHP需要容器化，那Nginx是否也需要容器化？如果这两者都容器化了，那我以后再加一个服务，是不是还需要考虑是否需要用docker这些问题。综上，我觉得这个方案对我现在来说，成本有点高。
我最终使用了方案二，对于网络安全性，我决定让安全性为灵活性让路。
后记
在之前，我都是LNMP的拥护者，感觉LNMP安装后即用，非常简单；现在我更偏向于使用 docker 来创建各类环境。
LNMP提供了一个大多数人都可以用的一个系统环境，但是现在的我有能力，也更需要一个适合自己的定制化系统环境，这也许就是在不断进步中的思想观念的转变吧！
更新：
我又重新看了一下docker的bridge的架构分析，原来通过bridge的方法暴露端口，实际上是增加了一条iptables的规则，这条规则可以通过命令iptables -t nat -L -n查看。
target prot opt source destination
DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:3306 to:172.20.0.2:3306DNAT 是用来做目的网络地址转换的，通过重写包的目的IP地址实现。
这样我之前提到过的“在容器内的应用看来，发起访问的IP是主机的docker IP，而不是用户的真实IP”这个问题也迎刃而解了！
更新二：
MariaDB创建用户时，不要用localhost，要用127.0.0.1！
文章评论