自動化模式（Autopilot Pattern）是一種設計應用與基礎架構的方式，旨在推動應用系統中的各個組件自動化。組成應用的每個容器都有自己的生命周期，我們將這些生命周期的行為封裝到了應用的容器中，而沒有依賴外部架構。
　　下文將講述我們是如何借助這種模式，部署和運行其中一種常被認為難以在Docker容器中運行的復雜、有狀態的應用：MySQL。
　　運行MySQL
　　我們從常見的MySQL部署開始：從主節點到副本節點執行異步復制。客戶端查詢副本節點，或對主節點執行寫入操作。這個架構會引發一些關于服務發現和拓撲結構的問題：
　　副本節點如何知道在哪兒能找到主節點？主節點如何告知副本節點從哪兒開始執行復制？客戶端如何知道在哪兒找到節點，哪些節點接受寫入操作？
　　在執行部署后，我們還有一系列疑問：
　　我們怎樣進行備份？如何主節點出現故障，如何對副本節點進行升級來進行替換？在故障轉移期間，其他的副本節點怎樣知道在哪兒能找到新的主節點？客戶端如何知道我們執行了故障轉移？
　　當然，其中一些問題已經有了現成的答案。配置管理工具經常會負責應用中架構的配置工作，但如果運行時應用拓撲出現變更，配置管理工具是無法回應的。數據庫即服務（DBaaS）負責執行管理工作，不過如今大多的配置已不再控制范圍內，成本也更為高昂。
　　對應用來說，還有一個選擇就是執行自動化運行。在這種模式下，要對應用模式執行優化，代表著要讓應用知道如何適應整個系統：啟動、關閉、縮放、發現和恢復。最大限度地減少人為干涉，意味著錯誤更少，有更多的時間花在更重要的業務上。
　　很明顯我們沒打算重寫MySQL，因此需要找出辦法為現有的應用提供這個功能，而我們選擇了Containerbuddy。
　　架構
　　我們需要利用這些組件部署MySQL：
　　MySQL：我們使用了MySQL5.6（Percona Server），使用XtraBackup運行熱快照備份；
　　Consul：用來協調復制與故障轉移工作；
　　Manta：Joyent的對象存儲系統，為存儲MySQL快照備份提供安全經久的服務；
　　Containerbuddy：包含在我們的MySQL容器中，負責編配bootstrap behavior，通過onStart、health、onChange處理器，調用Consul中存儲的key和checks協調復制的工作。
　　triton-mysql.py：Containerbuddy在執行MySQL編配的繁重任務時會調用到的小型Python應用。
　　所有代碼與配置都能在GitHub中找到。
　　
　　架構圖
　　當開始新的MySQL節點時，Containerbuddy的onStart處理器會調用triton-mysql.py。Containerbuddy會fork Percona Server并等待，同時運行onStart、health、onChange處理器。結果就是類似這樣在MySQL容器中的進程樹：
　　root@993acf351cd9:/# ps axo uid，pid，ppid，stime，cmdUID PID PPID STIME CMD root 1019:02/bin/containerbuddy mysql 94119:02|_ mysqld --console --gtid-mode=ON.。.root 107119:04|_ python /bin/triton-mysql.py healthroot 109119:04| |_ /usr/bin/innobackupex --no-timestamp.。.root 120119:06|_ python /bin/triton-mysql.py healthroot 121119:06|_ mysql -u repl -p.。.
　　自組裝
　　由于我們只用了幾個Docker鏡像，無需使用單獨的調度器來管理發現與引導服務，簡單地使用下面的命令就可以運行堆棧：
　　docker-composeup -d
　　出現的第一個節點會登錄Consul發現服務，嘗試并查找主節點。如果第一個節點發現主節點還不存在，則將自身作為主節點，并初始化數據庫。使用Consul會話通過atomic鎖寫入密碼，這樣就會有一個且僅有一個節點成為主節點。