江苏龙网

  1. 主页 > 生活百科 > >

DBA视角：把数据库放入Docker是一个馊主意( 三 )

docker


类似的问题包括一些故障检测工具与系统常用命令 ， 虽然理论上可以直接在宿主机上执行 ， 但谁能保证容器里的结果和裸机上的结果有着相同的涵义？更为棘手的是紧急故障处理时，一些需要临时安装使用的工具在容器里没有，外网不通，如果再走Dockerfile→Image→重启这种路径毫无疑问会让人抓狂 。
把Docker当成虚拟机来用的话，很多工具大抵上还是可以正常工作的，不过这样就丧失了使用的Docker的大部分意义，不过是把它当成了另一个包管理器用而已 。有人觉得Docker通过标准化的部署方式增加了系统的可靠性，因为环境更为标准化更为可控 。这一点不能否认 。私以为，标准化的部署方式虽然很不错，但如果运维管理数据库的人本身了解如何配置数据库环境，将环境初始化命令写在Shell脚本里和写在Dockerfile里并没有本质上的区别 。
可维护性
软件的大部分开销并不在最初的开发阶段 ， 而是在持续的维护阶段，包括修复漏洞、保持系统正常运行、处理故障、版本升级，偿还技术债、添加新的功能等等 。可维护性对于运维人员的工作生活质量非常重要 。
应该说可维护性是Docker最讨喜的地方：Infrastructure as code 。可以认为Docker的最大价值就在于它能够把软件的运维经验沉淀成可复用的代码，以一种简便的方式积累起来，而不再是散落在各个角落的install/setup文档 。
在这一点上Docker做的相当出色，尤其是对于逻辑经常变化的无状态应用而言 。Docker和K8s能让用户轻松部署，完成扩容，缩容，发布，滚动升级等工作，让Dev也能干Ops的活 ， 让Ops也能干DBA的活（迫真） 。
环境配置
如果说Docker最大的优点是什么，那也许就是环境配置的标准化了 。标准化的环境有助于交付变更，交流问题，复现Bug 。使用二进制镜像（本质是物化了的Dockerfile安装脚本）相比执行安装脚本而言更为快捷，管理更方便 。一些编译复杂 ， 依赖如山的扩展也不用每次都重新构建了，这些都是很不错的特性 。
不幸的是，数据库并不像通常的业务应用一样来来去去更新频繁，创建新实例或者交付环境本身是一个极低频的操作 。同时DBA们通常都会积累下各种安装配置维护脚本，一键配置环境也并不会比Docker慢多少 。因此在环境配置上Docker的优势就没有那么显著了，只能说是 Nice to have 。当然，在没有专职DBA时 ， 使用Docker镜像可能还是要比自己瞎折腾要好一些 ， 因为起码镜像中多少沉淀了一些运维经验 。
通常来说 ， 数据库初始化之后连续运行几个月几年也并不稀奇 。占据数据库管理工作主要内容的并不是创建新实例与交付环境，主要还是日常运维的部分 —— Day2 Operation 。不幸的是，在这一点上Docker并没有什么优势，反而会产生不少的额外麻烦 。
Day2 Operation
Docker确实能极大地简化无状态应用的日常维护工作，诸如创建销毁，版本升级 ， 扩容等，但同样的结论能延伸到数据库上吗？
数据库容器不可能像应用容器一样随意销毁创建，重启迁移 。因而Docker并不能对数据库的日常运维的体验有什么提升 ， 真正有帮助的倒是诸如 ansible 之类的工具 。而对于日常运维而言，很多操作都需要通过docker exec的方式将脚本透传至容器内执行 。底下跑的还是一样的脚本，只不过用docker-exec来执行又额外多了一层包装，这就有点脱裤子放屁的意味了 。
此外 ， 很多命令行工具在和Docker配合使用时都相当尴尬 。譬如docker exec会将stderr和stdout混在一起，让很多依赖管道的命令无法正常工作 。以PostgreSQL为例，在裸机部署模式下，某些日常ETL任务可以用一行bash轻松搞定：
psql <src-url> -c 'COPY tbl TO STDOUT' |
psql <dst-url> -c 'COPY tdb FROM STDIN'
但如果宿主机上没有合适的客户端二进制程序，那就只能这样用Docker容器中的二进制：
docker exec -it srcpg gosu postgres bash -c "psql -c "COPY tbl TO STDOUT" 2>/dev/null" | docker exec -i dstpg gosu postgres psql -c 'COPY tbl FROM STDIN;'
当用户想为容器里的数据库做一个物理备份时，原本很简单的一条命令现在需要很多额外的包装：docker套gosu套bash套pg_basebackup：
docker exec -i postgres_pg_1 gosu postgres bash -c 'pg_basebackup -Xf -Ft -c fast -D - 2>/dev/null' | tar -xC /tmp/backup/basebackup
如果说客户端应用psql|pg_basebackup|pg_dump还可以通过在宿主机上安装对应版本的客户端工具来绕开这个问题，那么服务端的应用就真的无解了 。总不能在不断升级容器内数据库软件的版本时每次都一并把宿主机上的服务器端二进制版本升级了吧？


推荐阅读


上一篇：Redis五大经典业务问题剖析及解决方法

下一篇：生成式人工智能潜力的释放：软件工程师的MLOps和LLM部署策略