作为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来治理资源工作。