container-as-a-service-0x01 -- 基於Docker的私有云&混合雲構建方案

時間 2019-11-10

標籤 container service 0x01 基於 docker 私有混合構建方案欄目 Docker 简体版

原文原文鏈接

container-as-a-service-0x01 -- 基於Docker的私有云&混合雲構建方案php

By 蘇依蜀黍 . 2016.06.07前端

what

Docker是一個開源的引擎，能夠輕鬆的爲任何應用建立一個輕量級的、可移植的、自給自足的容器。開發者在筆記本上編譯測試經過的容器能夠批量地在生產環境中部署，包括VMs（虛擬機）、bare metal、OpenStack 集羣和其餘的基礎應用平臺。node

DevOps近年大熱，Docker也被各大雲服務提供商普遍支持，他的應用場景以下且不止於此：python

web應用的自動化打包和發佈mysql
自動化測試和持續集成、發佈nginx
在服務型環境中部署和調整數據庫或其餘的後臺應用git
從頭編譯或者擴展示有的OpenShift或Cloud Foundry平臺來搭建本身的PaaS環境web

好比顯著的優勢有資源獨立&隔離、環境的一致性、輕量化、固然了，還有一個你們都想要的特性："Build Once, Run Everywhere"。redis

why

但是做爲一家初創公司，爲何咱們要構建所謂的"私有云&混合雲"？sql

做爲一個實用主義，上述的特性或者說應用場景，最可以吸引個人大概只有"Build Once, Run Everywhere"，而後這仍然不足以成爲要推進該方案落地的動力，why？

咱們可能以及將來要應對的需求主要有如下幾點：

快速擴容（應對可能出現的高併發需求）
快速減容（媒體相關的內容具備時效性，社交類信息存在訪問高峯與低谷）
動態遷移（不停機更新、實時遷移服務，備份，容災等）
統一入口（單一或者相對固定的入口，後端服務的遷移再也不影響前端業務）
持續集成（包含測試，上線，回滾等功能）

應對上述的需求，其實徹底能夠找到對應的替代方案：

動態擴容——使用Aliyun或者Amazon的AutoScale類服務，自動控制服務器數量
動態遷移——使用中間件如nginx，upstream不停機更新
統一入口——Route53或者ELB/SLB作端口轉發，負載均衡後端再次使用VPC內網轉發
持續集成——使用Jenkins&Webhook搭建自動化平臺、或者使用Webhook與應用中心，程序註冊爲應用中心應用，動態監測，自動更新

可是，看看上面的內容就能夠了解到，對初創公司而言，要作這些事情，並不簡單，沒有那麼多的人力物力去作，可是，業務在這裏，咱們不可能不作，怎麼辦？

how

這裏咱們開始今天的主題：

基於Docker的私有云&混合雲構建方案

基於該主題，咱們要先理清一些Docker相關的概念並就該方面會遇到的問題作一些解答

host/hode

Host/Node即物理服務器或者雲服務器，它是一切服務運行的基石，全部的應用&服務都運行其上，包含了：

Docker Engine （Docker引擎,運行容器）
App（容器應用，如Web服務）
Agent（*容器應用，特殊的容器應用，將該Host註冊到容易的管理平臺）
Proxy（*容器應用，特殊的容器應用，用來在內網進行轉發）

咱們的Host使用了Aliyun以及Amazon的雲服務器，動態伸縮包含：

服務器動態伸縮
應用動態伸縮（經過Docker管理服務進行管理）

服務器如何動態伸縮要實現的功能是：

調用API開通/銷燬Ecs
記錄Ecs信息如：ip/user/passwd/region/info(配置信息)
註冊Ecs到管理平臺

container

container即運行的服務或者應用，如nodejs的前端應用、php的後端服務、python的媒體處理等，固然還能夠包括mongodb/mysql/redis等數據服務

開發，採用ansible docker或者各自環境的官方repo對不一樣運行環境的應用進行容器化，其實比較簡單，針對不一樣的運行環境在項目里加入一個dockerfile便可，並不須要開發者作過多的配置
構建，這裏咱們有多種選擇（使用Aliyun或者Daocloud的自動構建，在內網配置機器自行構建也能夠，方案較多，省時省力的方式天然是使用第三方服務了）
測試，能夠選擇在dockerfile中執行test或者在推送到test分支，並部署到test服務器，人肉測試，按需選擇
CI，CI這裏咱們能夠註冊gitlab的runner或者是直接使用daocloud的CI，按需選擇

elb/slb

集羣處理上，咱們選擇在同一個region內，使用一個slb/elb作負載均衡，其餘服務器不開通外網服務，在內部針對一組應用配合一個nginx或者haproxy成爲一個服務/應用單元，多個這樣的單元成爲一個當前可用區的內部服務，經過負載均衡擁有統一的入口

slb/elb:
        80:80        {frontend service} -- 應用單元    
                    {frontend service} -- host_x0
                        nginx:80
                            host_x0_1
                            host_x0_2
                            ...        
        8080:8080    {backend  service} -- 服務單元    
                    {backend service} -- host_x1
                        nginx:80
                            host_x1_1
                            host_x2_1
                            ...

dns/cdn

基於region構建集羣，仍然不能完美解決跨區域的入口統一問題，因此這時候咱們有兩種方案可選：

基於dns的負載均衡，可以使用dnspod，添加多個記錄，對應到同一個域名的不一樣加速域名
基於cdn的方案，則是添加多個回源ip，可是注意一下，該ip，是slb/elb的ip

architect

practice

這裏咱們使用rancher做爲docker host的管理中心，在每個host上運行一個rancher-agent與rancher-server進行通信，並以此來完成基於應用的快速伸縮，固然，咱們的服務中不包含data-service，也不包含storage-service，咱們使用阿里雲的oss做爲存儲服務，使用rds做爲數據庫，將更多精力放在開發以及業務上

環境：

雲上主機：阿里雲Ecs/亞馬遜Ec2（Ubuntu14.10/Centos7.x）
負載均衡：阿里雲負載均衡器
容器管理：rancher-server

配置

Host都已經預裝了docker-engine，而且在杭州可用區B
Rancher-server安裝在該區域內的一臺獨立主機上，具備外網訪問ip，該機器暫時不使用負載均衡（後期會用）

運行

rancher-server

docker run -d --restart=always -p 8080:8080 rancher/server

rancher-agent(add hosts)

docker run -d --privileged -v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/rancher:/var/lib/rancher rancher/agent:v1.0.1 {Server_Domain}:{Server_Port}/v1/scripts/{registrationToken}