作為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做為首選。筆者所負責的産品，同樣将k8s作為容器資料庫編排的架構提供多類RDS服務，目前單叢集最大支援RDS規模達到1000+。kubernets架構可以讓企業通過擴充自定義的資源類型來部署容器化資料庫，當然還需要根據自身的業務場景來解決容器資料庫的資料持久化問題，容器資料庫的編排排程政策，網絡方案及服務暴露方式等等。
當企業将k8s作為IT架構将資料庫容器化後，給運維DBA帶來的收益将是完全比對業務快速發展的需要以及對RDS服務品質的要求，但同時也對運維DBA帶來了全新的挑戰，運維DBA需要充分了解k8s架構設計體系，能夠通過k8s自帶的Cli元件或者自定義yaml來管理資源任務。