共计 2736 个字符，预计需要花费 7 分钟才能阅读完成。
作为 DBA 运维人员，数据库真的能够运行在容器外面吗？容器自身会不会存在安全隐患？会不会失落数据？那就是丢了饭碗了啊！！！
然而公司业务倒退的速度切实太快，来了一个厂商或者利用就要求咱们上线一个 RDS 实例，并且要求实例具备高可用、可扩大能力，随时上线或者下线，领导又要求进步物理硬件资源利用率。业务部门终日催着咱们疾速提供数据库服务，数据库实例多了后，运维难度和复杂度直线回升。公司 IT 倒退策略朝着微服务和互联网化全面革新，DevOps 建设又旨在买通运维和开发部门壁垒，作为 DBA 运维人员该如何适应这种转型？
传统 DBA 运维治理形式无奈满足以后需要
笔者同是 MySQL 运维 DBA 过来人，目前在做 RDS 相干产品工作。同甲方 DBA 运维或开发部门打交道过程中，十分可能感同身受在以后云计算、容器化、微服务等大浪中，DBA 运维人员的痛点和难点。
通常 DBA 运维人员，研发能力比拟弱，没有工程化我的项目教训。当然自动化运维、shell 或者 python 脚本辅助工具等，对于小规模的 RDS 集群（10～20）的运维治理曾经够用。然而随着公司规模的扩充利用场景的丰盛，企业通常不会只有一种数据库实例，可能并存着 MySQL、Oracle、SQL Server、PostgreSQL 等。
那么企业用人方要求 DBA 把握多种数据库的个性能力，或者招聘每种 DBA 从业人员。其实关系型数据库在横向应用场景上存在共性如：高可用、RDS 集群规模可扩大、计算 / 存储可变更、备份复原、监控告警等等。
不要让 RDS 服务质量成了最初的短板
研发和运维之间的确存在壁垒，咱们常常看到研发人员公布软件应用上线后，须要由运维人员提供硬件和网络环境进行部署，通常运维人员并不关怀你软件运行的“好坏”或者“快慢”，只关怀物理服务和网络等监控指标。
DBA 运维人员除了须要关怀这些指标外，还须要关怀数据库软件自身的“好坏”和“快慢”。比方利用的表是否创立了正当的索引、物理机存储空间大小、SQL 语句是否非法如应用了 select * From table1、table2… 等导致存储介质的 IO 被打满等等。当企业开始微服务和 DevOps 建设后，对服务麻利和疾速交付能力提出了要求。而关系型数据库又是一类比拟特地的利用场景，一些大规模的企业更是专门设置了 DBA 部门来负责数据库实例的运维和开发工作。随着企业业务对产品研发速度和疾速适应市场的要求，数据库实例交付速度和能力逐步成为瓶颈。
容器化是必经之道
研发人员为什么喜爱容器？因为容器技术打包了程序所需运行时的上下文并且领有优良的跨平台能力，通过定义简略的流程，能够帮助企业开发和运维人员疾速公布和部署利用。当然也有局部 DBA 运维人员对容器数据库不感冒，我认为是没有适合的场景。上文提到 DBA 运维人员能够通过自动化运维、shell 或者 python 脚本辅助工具等，对于小规模的 RDS 集群（10～20）的运维治理曾经足够。
那么什么场景是适合数据库运行在容器内？笔者接触到的客户场景，通常是企业开始建设本人的 DevOps 须要疾速交付 RDS 服务或是企业 DBA 人员 VS 负责数据库实例数量达到 1:50+ 以上的规模比例。
浅谈容器数据库价值
所谓容器只不过是一个一般过程，这个过程的非凡之处在于：1）它可能是位于不同命名空间（ns）的，应用 clone/unshare/setns 零碎调用将容器过程退出不同的命名空间 2）它对资源的应用（cpu,memory,diskio 等）可能受到 CGroup 资源管制的限度。
通过应用容器 graphdriver 的个性，DBA 在单机运行多个实例的场景下，同样版本的数据库实例自身须要运行的库文件共享了 base image，大大节俭了物理机器的存储空间。
容器内数据的“平安”问题
DBA 最关怀的根底问题是数据完整性和安全性，上文提到容器只不过是一般的一个过程，利用了 Linux kernel 的个性“假装”成一个虚构的 OS 运行环境，graphdriver 通过 CoW 机制，解决镜像文件共享问题。
运行关系型数据库容器，咱们须要通过另外的“接口”，不通过 graphdriver 来长久化数据。容器自身提供长久化数据的能力。例如：运行容器化 MySQL 实例，将 OS 的目录 /opt 挂载到容器的 /var/lib/mysql 目录，容器内 MySQL 实例所产生的数据都写到宿主机的 /opt 目录下。
docker run –name mysql -v /opt:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=somepassword -d mysql/mysql-server:5.7
咱们通过 docker inspect docker-id 命令，查看该容器数据库的运行 spec 信息。截取局部要害信息。
“Mounts”: [{ “Type”: “volume”, “Name”: “b13109e14d1fd5c2d9957689a2d509b90ca8eafd4080a92de636eeb97090c0fd”, “Source”:”/var/lib/docker/volumes/b13109e14d1fd5c2d9957689a2d509b90ca8eafd4080a92de636eeb97090c0fd/_data”, “Destination”: “/var/lib/mysql”,
咱们看到，docker 通过 type 为 volume 的形式，映射 OS 目录到容器内进行绑定，咱们齐全能够通过 OS 的文件系统如 ext4 和 XFS，或者利用分布式存储的卷来保障容器数据库的数据安全。
kubernetes 是容器化数据库集群最佳实际
以上十分浅显的谈到运维 DBA 通常对容器数据库的质疑，当然如果要大规模部署容器数据库集群，离不开好的架构设计。”kubernetes is eating the Container world” 这句话一点都不夸大，云原生，微服务，PaaS，IoT，DevOps 等等，以容器为技术栈的架构简直都将 k8s 做为首选。
笔者所负责的产品——沃趣 QFusion，同样将 k8s 作为容器数据库编排的框架提供多类 RDS 服务，目前单集群最大反对 RDS 规模达到 1000+。kubernets 架构能够让企业通过扩大自定义的资源类型来部署容器化数据库，当然还须要依据本身的业务场景来解决容器数据库的数据长久化问题，容器数据库的编排调度策略，网络计划及服务裸露形式等等。
当企业将 k8s 作为 IT 架构将数据库容器化后，给运维 DBA 带来的收益将是齐全匹配业务疾速倒退的须要以及对 RDS 服务质量的要求，但同时也对运维 DBA 带来了全新的挑战，运维 DBA 须要充沛了解 k8s 架构设计体系，可能通过 k8s 自带的 Cli 组件或者自定义 yaml 来治理资源工作。
