http://www.infoq.com/cn/articles/docker-source-code-analysis-part5

1.Docker Server簡介

Docker架構中，Docker Server是Docker Daemon的重要組成部分。Docker Server最主要的功能是：接受用戶通過Docker Client發送的請求，并按照相應的路由規則實現路由分發。

同時，Docker Server具備十分優秀的用戶友好性，多種通信協議的支持大大降低Docker用戶使用Docker的門檻。除此之外，Docker Server設計實現了詳盡清晰的API接口，以供Docker用戶選擇使用。通信安全方面，Docker Server可以提供安全傳輸層協議（TLS），保證數據的加密傳輸。并發處理方面，Docker Daemon大量使用了Golang中的goroutine，大大提高了服務端的并發處理能力。

本文為《Docker源碼分析》系列的第五篇——Docker Server的創建。

2. Docker Server源碼分析內容安排

本文將從源碼的角度分析Docker Server的創建，分析內容的安排主要如下：

(1) “serveapi”這個job的創建并執行流程，代表Docker Server的創建；

(2) “serveapi”這個job的執行流程深入分析；

(3) Docker Server創建Listener并服務API的流程分析。

3.Docker Server創建流程

《Docker源碼分析（三）：Docker Daemon啟動》主要分析了Docker Daemon的啟動，而在mainDaemon()運行的最后環節，實現了創建并運行名為”serveapi”的job。這一環節的作用是：讓Docker Daemon提供API訪問服務。實質上，這正是實現了Docker架構中Docker Server的創建與運行。

從流程的角度來說，Docker Server的創建并運行，代表了”serveapi”這個job的整個生命周期：創建Job實例job，配置job環境變量，以及最終執行該job。本章分三節具體分析這三個不同的階段。

3.1創建名為”serveapi”的job

Job是Docker架構中Engine內部最基本的任務執行單位，故創建Docker Server這一任務的執行也不例外，需要表示為一個可執行的Job。換言之，需要創建Docker Server，則必須創建一個相應的Job。具體的Job創建形式位于./docker/docker/daemon.go，如下：

job := eng.Job("serveapi", flHosts...)

以上代碼通過Engine實例eng創建一個Job類型的實例job，job名為”serveapi”，同時用flHost的值來初始化job.Args。flHost的作用是：配置Docker Server監聽的協議與監聽的地址。

需要注意的是，《Docker源碼分析（三）：Docker Daemon啟動》mainDaemon()具體實現過程中，在加載builtins環節已經向eng對象注冊了key為”serveapi”的Handler，而該Handler的value為api.ServeApi。因此，在運行名為”serveapi”的job時，會執行該job的Handler，即api.ServeApi。

3.2配置job環境變量

創建完Job實例job之后，Docker Daemon為job配置環境參數。在Job實現過程中，為Job配置參數有兩種方式：第一，創建Job實例時，用指定參數直接初始化Job的Args屬性；第二，創建完Job后，給Job添加指定的環境變量。以下代碼則實現了為創建的job配置環境變量：

job.SetenvBool("Logging", true) job.SetenvBool("EnableCors", *flEnableCors) job.Setenv("Version", dockerversion.VERSION) job.Setenv("SocketGroup", *flSocketGroup)job.SetenvBool("Tls", *flTls) job.SetenvBool("TlsVerify", *flTlsVerify) job.Setenv("TlsCa", *flCa) job.Setenv("TlsCert", *flCert) job.Setenv("TlsKey", *flKey) job.SetenvBool("BufferRequests", true)

對于以上配置，環境變量的歸納總結如下表：

環境變量名	flag參數	默認值	作用值
Logging	?	true	使用日志輸出
EnableCors	flEnableCors	false	在遠程API中提供CORS頭
Version	?	?	顯示Docker版本號
SocketGroup	flSocketGroup	“docker”	在daemon模式中unix domain socket分配用戶組名
Tls	flTls	false	使用TLS安全傳輸協議
TlsVerify	flTlsVerify	false	使用TLS并驗證遠程Client
TlsCa	flCa	?	指定CA文件路徑
TlsCert	flCert	?	TLS證書文件路徑
TlsKey	flKey	?	TLS密鑰文件路徑
BufferRequest	?	true	緩存Docker Client請求

3.3 運行job

配置完畢job的環境變量，隨即執行job的運行函數，具體實現代碼如下：

if err := job.Run(); err != nil {log.Fatal(err) }

在eng對象中已經注冊過key為”serveapi”的Handler，故在運行job的時候，執行這個Handler的value值，相應Handler的value為api.ServeApi。至此，名為”serveapi”的job的生命周期已經完備。下文將深入分析job的Handler，api.ServeApi執行細節的具體實現。

4.ServeApi運行流程

本章將深入分析Docker Server提供API服務的部分，從源碼的角度剖析Docker Server的架構設計與實現。

作為一個監聽請求、處理請求的服務端，Docker Server首先明確自身需要為多少種通信協議提供服務，在Docker這個C/S模式的架構中，可以使用的協議無外乎三種:TCP協議，Unix Socket形式，以及fd的形式。隨后，Docker Server根據協議的不同，分別創建不同的服務端實例。最后，在不同的服務端實例中，創建相應的路由模塊，監聽模塊，以及處理請求的Handler，形成一個完備的server。

”serveapi”這個job在運行時，將執行api.ServeApi函數。ServeApi的功能是：循環檢查所有Docker Daemon當前支持的通信協議，并對于每一種協議都創建一個goroutine，在這個goroutine內部配置一個服務于HTTP請求的server端。ServeApi的代碼實現位于./docker/api/server/server.go#L1339：

第一，判斷job.Args的長度是否為0，由于通過flHosts來初始化job.Args，故job.Args的長度若為0的話，說明沒有Docker Server沒有監聽的協議與地址，參數有誤，返回錯誤信息。代碼如下：

if len(job.Args) == 0 {return job.Errorf("usage: %s PROTO://ADDR [PROTO://ADDR ...]", job.Name) }

第二，定義兩個變量，protoAddrs代表flHosts的內容；而chError定義了和protoAddrs長度一致的error類型channel管道，chError的作用在下文中會說明。同時還定義了activationLock，這是一個用來同步”serveapi”和”acceptconnections”這兩個job執行的channel。在serveapi運行時ServeFd和ListenAndServe的實現中，由于activationLock這個channel中沒有內容而阻塞，而當運行”acceptionconnections”這個job時，會首先通知init進程Docker Daemon已經啟動完畢，并關閉activationLock，同時也開啟了serveapi的繼續執行。正是由于activationLock的存在，保證了”acceptconnections”這個job的運行起到通知”serveapi”開啟正式服務于API的效果。代碼如下：

var (protoAddrs = job.ArgschErrors = make(chan error, len(protoAddrs)) ) activationLock = make(chan struct{})

第三，遍歷protoAddrs，即job.Args，將其中的每一項都按照字符串“://”進行分割，若分割后protoAddrParts的長度不為2，則說明協議加地址的書寫形式有誤，返回job錯誤；若不為2，則分割獲得每一項中的協議protoAddrPart[0]與地址protoAddrParts[1]。最后分別創建一個goroutine來執行ListenAndServe的操作。goroutine的運行主要依賴于ListenAndServe(protoAddrParts[0], protoAddrParts[1], job)的運行結果，若返回error，則chErrors中有error，當前goroutine執行完畢；若沒有返回error，則該goroutine持續運行，持續提供服務。其中最為重要的是ListenAndServe的實現，該函數具體實現了如何創建listener、router以及server，并協調三者進行工作，最終服務于API請求。代碼如下：

for _, protoAddr := range protoAddrs {protoAddrParts := strings.SplitN(protoAddr, "://", 2)if len(protoAddrParts) != 2 {return job.Errorf("usage: %s PROTO://ADDR [PROTO://ADDR ...]", job.Name)}go func() {log.Infof("Listening for HTTP on %s (%s)", protoAddrParts[0], protoAddrParts[1])chErrors <- ListenAndServe(protoAddrParts[0], protoAddrParts[1], job)}() }

第四，根據chErrors的值運行，若chErrors這個channel中有錯誤內容，則ServeApi該函數返回；若無錯誤內容，則循環被阻塞。代碼如下：

for i := 0; i < len(protoAddrs); i += 1 {err := <-chErrorsif err != nil {return job.Error(err)} }return engine.StatusOK

至此， ServeApi的運行流程已經詳細分析完畢，其中核心部分ListenAndServe的實現，下一章開始深入。

5.ListenAndServe實現

ListenAndServe的功能是：使Docker Server監聽某一指定地址，接受該地址上的請求，并對以上請求路由轉發至相應的處理函數Handler處。從實現的角度來看，ListenAndServe主要實現了設置一個服務于HTTP的server，該server將監聽指定地址上的請求，并對請求做特定的協議檢查，最終完成請求的路由與分發。代碼實現位于./docker/api/server/server.go。

ListenAndServe的實現可以分為以下4個部分：

(1) 創建router路由實例；

(2) 創建listener監聽實例；

(3) 創建http.Server；

(4) 啟動API服務。

ListenAndServe的執行流程如下圖：

圖5.1 ListenAndServer執行流程圖

下文將按照ListenAndServe執行流程圖一一深入分析各個部分。

?

5.1 創建router路由實例

首先，ListenAndServe的實現中通過createRouter創建了一個router路由實例。代碼實現如下：

rr, err := createRouter(job.Eng, job.GetenvBool("Logging"), job.GetenvBool("EnableCors"), job.Getenv("Version")) if err != nil {return err }

createRouter的實現位于./docker/api/server/server.go#L1094。

創建router路由實例是一個重要的環節，路由實例的作用是：負責Docker Server對請求進行路由以及分發。實現過程中，主要兩個步驟：第一，創建全新的router路由實例；第二，為router實例添加路由記錄。

5.1.1?創建空路由實例

?

?

實質上，createRouter通過包gorilla/mux實現了一個功能強大的路由器和分發器。如下：

r := mux.NewRouter()

NewRouter()函數返回了一個全新的router實例r。在創建Router實例時，給Router對象的兩個屬性進行賦值，這兩個屬性為nameRoutes和KeepContext。其中namedRoutes屬性為一個map類型，其中key為string類型，value為Route路由記錄類型；另外，KeepContext屬性為false，表示Docker Server在處理完請求之后，就清除請求的內容，不對請求做存儲操作。代碼位于./docker/vendor/src/github.com/gorilla/mux/mux.go#L16，如下：

func NewRouter() *Router {return &Router{namedRoutes: make(map[string]*Route), KeepContext: false} }

可見，以上代碼返回的類型為mux.Router。mux.Router會通過一系列已經注冊過的路由記錄，來為接受的請求做匹配，首先通過請求的URL或者其他條件，找到相應的路由記錄，并調用這條路由記錄中的執行Handler。mux.Router有以下這些特性：

• 請求可以基于URL 的主機名、路徑、路徑前綴、shemes、請求頭和請求值、HTTP請求方法類型或者使用自定義的匹配規則；
• URL主機名和路徑可以擁有一個正則表達式來表示；
• 注冊的URL可以被直接運用，也可以被保留，這樣可以保證維護資源的使用；
• 路由記錄可以被用以子路由器：如果父路由記錄匹配，則嵌套記錄只會被用來測試。當設計一個組內的路由記錄共享相同的匹配條件時，如主機名、路勁前綴或者其他重復的屬性，子路由的方式很有幫助；
• mux.Router實現了http.Handler接口，故和標準的http.ServeMux兼容。

5.1.2?添加路由記錄

Router路由實例r創建完畢，下一步工作是為Router實例r添加所需要的路由記錄。路由記錄存儲著用來匹配請求的信息，包括對請求的匹配規則，以及匹配之后的Handler執行入口。

回到createRouter實現代碼中，首先判斷Docker Daemon的啟動過程中有沒有開啟DEBUG模式。通過docker可執行文件啟動Docker Daemon，解析flag參數時，若flDebug的值為false，則說明不需要配置DEBUG環境；若flDebug的值為true，則說明需要為Docker Daemon添加DEBUG功能。具體的代碼實現如下：

if os.Getenv("DEBUG") != "" {AttachProfiler(r) }

AttachProiler(r)的功能是為路由實例r添加與DEBUG相關的路由記錄，具體實現位于./docker/api/server/server.go#L1083，如下：

func AttachProfiler(router *mux.Router) {router.HandleFunc("/debug/vars", expvarHandler)router.HandleFunc("/debug/pprof/", pprof.Index)router.HandleFunc("/debug/pprof/cmdline", pprof.Cmdline)router.HandleFunc("/debug/pprof/profile", pprof.Profile)router.HandleFunc("/debug/pprof/symbol", pprof.Symbol)router.HandleFunc("/debug/pprof/heap", pprof.Handler("heap").ServeHTTP)router.HandleFunc("/debug/pprof/goroutine", pprof.Handler("goroutine").ServeHTTP)router.HandleFunc("/debug/pprof/threadcreate", pprof.Handler("threadcreate").ServeHTTP) }

分析以上源碼，可以發現Docker Server使用兩個包來完成DEBUG相關的工作：expvar和pprof。包expvar為公有變量提供標準化的接口，使得這些公有變量可以通過HTTP的形式在”/debug/vars”這個URL下被訪問，傳輸時格式為JSON。包pprof將Docker Server運行時的分析數據通過”/debug/pprof/”這個URL向外暴露。這些運行時信息包括以下內容：可得的信息列表、正在運行的命令行信息、CPU信息、程序函數引用信息、ServeHTTP這個函數三部分信息使用情況（堆使用、goroutine使用和thread使用）。

回到createRouter函數實現中，完成DEBUG功能的所有工作之后，Docker Docker創建了一個map類型的對象m，用于初始化路由實例r的路由記錄。簡化的m對象，代碼如下：

m := map[string]map[string]HttpApiFunc{"GET": {……"/images/{name:.*}/get": getImagesGet,……},"POST": {……"/containers/{name:.*}/copy": postContainersCopy,},"DELETE": {"/containers/{name:.*}": deleteContainers,"/images/{name:.*}": deleteImages,},"OPTIONS": {"": optionsHandler,}, }

對象m的類型為map，其中key為string類型，代表HTTP的請求類型，如”GET”，”POST”，”DELETE”等，value為另一個map類型，該map代表的是URL與執行Handler的映射。在第二個map類型中，key為string類型，代表是的請求URL，value為HttpApiFunc類型，代表具體的執行Handler。其中HttpApiFunc類型的定義如下：

type HttpApiFunc func(eng *engine.Engine, version version.Version,w http.ResponseWriter, r *http.Request, vars map[string]string) error

完成對象m的定義，隨后Docker Server通過該對象m來添加路由實例r的路由記錄。對象m的請求方法，請求URL和請求處理Handler這三樣內容可以為對象r構建一條路由記錄。實現代碼。如下：

for method, routes := range m {for route, fct := range routes {log.Debugf("Registering %s, %s", method, route)localRoute := routelocalFct := fctlocalMethod := methodf := makeHttpHandler(eng, logging, localMethod, localRoute, localFct, enableCors, version.Version(dockerVersion))if localRoute == "" {r.Methods(localMethod).HandlerFunc(f)} else {r.Path("/v{version:[0-9.]+}" + localRoute). Methods(localMethod).HandlerFunc(f)r.Path(localRoute).Methods(localMethod).HandlerFunc(f)}} }

以上代碼，在第一層循環中，按HTTP請求方法劃分，獲得請求方法各自的路由記錄，第二層循環，按匹配請求的URL進行劃分，獲得與URL相對應的執行Handler。在嵌套循環中，通過makeHttpHandler返回一個執行的函數f。在返回的這個函數中，涉及了logging信息，CORS信息（跨域資源共享協議），以及版本信息。以下舉例說明makeHttpHandler的實現，從對象m可以看到，對于”GET”請求，請求URL為”/info”，則請求Handler為”getInfo”。執行makeHttpHandler的具體代碼實現如下：

func makeHttpHandler(eng *engine.Engine, logging bool, localMethod string, localRoute string, handlerFunc HttpApiFunc, enableCors bool, dockerVersion version.Version) http.HandlerFunc {return func(w http.ResponseWriter, r *http.Request) {// log the requestlog.Debugf("Calling %s %s", localMethod, localRoute)if logging {log.Infof("%s %s", r.Method, r.RequestURI)}if strings.Contains(r.Header.Get("User-Agent"), "Docker-Client/") {userAgent := strings.Split(r.Header.Get("User-Agent"), "/")if len(userAgent) == 2 && !dockerVersion.Equal(version.Version(userAgent[1])) {log.Debugf("Warning: client and server don't have the same version (client: %s, server: %s)", userAgent[1], dockerVersion)}}version := version.Version(mux.Vars(r)["version"])if version == "" {version = api.APIVERSION}if enableCors {writeCorsHeaders(w, r)}if version.GreaterThan(api.APIVERSION) {http.Error(w, fmt.Errorf("client and server don't have same version (client : %s, server: %s)", version, api.APIVERSION).Error(), http.StatusNotFound)return}if err := handlerFunc(eng, version, w, r, mux.Vars(r)); err != nil {log.Errorf("Handler for %s %s returned error: %s", localMethod, localRoute, err)httpError(w, err)}} }

可見makeHttpHandler的執行直接返回一個函數func(w http.ResponseWriter, r *http.Request) 。在這個func函數的實現中，判斷makeHttpHandler傳入的logging參數，若為true，則將該Handler的執行通過日志顯示，另外通過makeHttpHandler傳入的enableCors參數判斷是否在HTTP請求的頭文件中添加跨域資源共享信息，若為true，則通過writeCorsHeaders函數向response中添加有關CORS的HTTP Header，代碼實現位于./docker/api/server/server.go#L1022，如下：

func writeCorsHeaders(w http.ResponseWriter, r *http.Request) {w.Header().Add("Access-Control-Allow-Origin", "*")w.Header().Add("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept")w.Header().Add("Access-Control-Allow-Methods", "GET, POST, DELETE, PUT, OPTIONS") }

最為重要的執行部分位于handlerFunc(eng, version, w, r, mux.Vars(r))，如以下代碼：

if err := handlerFunc(eng, version, w, r, mux.Vars(r)); err != nil {log.Errorf("Handler for %s %s returned error: %s", localMethod, localRoute, err)httpError(w, err) }

對于”GET”請求類型，”/info”請求URL的請求，由于Handler名為getInfo，也就是說handlerFunc這個形參的值為getInfo，故執行部分直接運行getInfo(eng, version, w, r, mux.Vars(r))，而getInfo的具體實現位于./docker/api/server/serve.go#L269，如下：

func getInfo(eng *engine.Engine, version version.Version, w http.ResponseWriter, r *http.Request, vars map[string]string) error {w.Header().Set("Content-Type", "application/json")eng.ServeHTTP(w, r)return nil }

以上makeHttpHandler的執行已經完畢，返回func函數，作為指定URL對應的執行Handler。

創建完處理函數Handler，需要向路由實例中添加新的路由記錄。如果URL信息為空，則直接為該HTTP請求方法類型添加路由記錄；若URL不為空，則為請求URL路徑添加新的路由記錄。需要額外注意的是，在URL不為空，為路由實例r添加路由記錄時，考慮了API版本的問題，通過r.Path("/v{version:[0-9.]+}" + localRoute).Methods(localMethod).HandlerFunc(f)來實現。

至此，mux.Router實例r的兩部分工作工作已經全部完成：創建空的路由實例r，為r添加相應的路由記錄，最后返回路由實例r。

現I時er路由記錄。需要額外的利次循環中，都有不同的組合1083lla/mux/mux.go,

5.2 創建listener監聽實例

路由模塊，完成了請求的路由與分發這一重要部分，屬于ListenAndServe實現中的第一個重要工作。對于請求的監聽功能，同樣需要模塊來完成。而在ListenAndServe實現中，第二個重要的工作就是創建Listener。Listener是一種面向流協議的通用網絡監聽模塊。

在創建Listener之前，先判斷Docker Server允許的協議，若協議為fd形式，則直接通過ServeFd來服務請求；若協議不為fd形式，則繼續往下執行。

在程序執行過程中，需要判斷”serveapi”這個job的環境中”BufferRequests”的值，是否為真，若為真，則通過包listenbuffer創建一個Listener的實例l，否則的話直接通過包net創建Listener實例l。具體的代碼位于./docker/api/server/server.go#L1269，如下：

if job.GetenvBool("BufferRequests") {l, err = listenbuffer.NewListenBuffer(proto, addr, activationLock) } else {l, err = net.Listen(proto, addr) }

由于在mainDaemon()中創建”serveapi”這個job之后，給job添加環境變量時，已經給”BufferRequets”賦值為true，故使用包listenbuffer創建listener實例。

Listenbuffer的作用是：讓Docker Server可以立即監聽指定協議地址上的請求，但是將這些請求暫時先緩存下來，等Docker Daemon全部啟動完畢之后，才讓Docker Server開始接受這些請求。這樣設計有一個很大的好處，那就是可以保證在Docker Daemon還沒有完全啟動完畢之前，接收并緩存盡可能多的用戶請求。

若協議的類型為TCP，另外job中環境變量Tls或者TlsVerify有一個為真，則說明Docker Server需要支持HTTPS服務，需要為Docker Server配置安全傳輸層協議（TLS）的支持。為實現TLS協議，首先需要建立一個tls.Config類型實例tlsConfig，然后在tlsConfig中加載證書，認證信息等，最終通過包tls中的NewListener函數，創建出適應于接收HTTPS協議請求的Listener實例l，代碼如下：

l = tls.NewListener(l, tlsConfig)

至此，創建網絡監聽的Listener部分已經全部完成。

5.3 創建http.Server

Docker Server同樣需要創建一個Server對象來運行HTTP服務端。在ListenAndServe實現中第三個重要的工作就是創建http.Server：

httpSrv := http.Server{Addr: addr, Handler: r}

其中addr為需要監聽的地址，r為mux.Router路由實例。

5.4 啟動API服務

創建http.Server實例之后，Docker Server立即啟動API服務，使Docker Server開始在Listener監聽實例l上接受請求，并對于每一個請求都生成一個新的goroutine來做專屬服務。對于每一個請求，goroutine會讀取請求，查詢路由表中的路由記錄項，找到匹配的路由記錄，最終調用路由記錄中的執行Handler，執行完畢后，goroutine對請求返回響應信息。代碼如下：

return httpSrv.Serve(l)

至此，ListenAndServer的所有流程已經分析完畢，Docker Server已經開始針對不同的協議，服務API請求。

6.總結

Docker Server作為Docker Daemon架構中請求的入口，接管了所有Docker Daemon對外的通信。通信API的規范性，通信過程的安全性，服務請求的并發能力，往往都是Docker用戶最為關心的內容。本文基于源碼，分析了Docker Server大部分的細節實現。希望Docker用戶可以初探Docker Server的設計理念，并且可以更好的利用Docker Server創造更大的價值。

轉載于:https://www.cnblogs.com/davidwang456/articles/9579723.html

總結

以上是生活随笔為你收集整理的Docker源码分析（五）：Docker Server的创建的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。