用Docker創建開發環境

本文講的是用Docker創建開發環境，【編者的話】鑒於還沒有用Docker創建本地開發環境的先例，Jeff Nickoloff開創了一個先例，相信大家也可以。

譯者解釋用Docker創建開發環境：作者在此處使用了Frankenstein一詞。Frankenstein，《弗蘭肯斯坦》原是英國詩人雪萊的妻子瑪麗·雪萊在1818年創作的小說，被認為是世界第一部真正意義上的科幻小說。弗蘭肯斯坦來自於此小說，可以理解為怪人;毀滅創造者自己之物

知道一個事物和實現這個事物是完全不同的事情。從Docker誕生那天開始，我們就夢想著諸如“15秒部署一個項目”，“版本可控開發環境”，以及時髦的運維用語，如“滾動開發”，“軟件定義架構”。處於浪尖的行業人士都在以前所未有的熱情參與到將很多名詞和工具，例如“編排”，“服務發現”等，定義，重新定義以及商品化大潮中。

我認為這股大潮的催化劑來自於Docker在應用和基礎架構之間帶來的美妙接口和抽象。開發者可以在不必知道底層架構情況下談論基礎架構，操作人員也不必花大量時間研究如何安裝和管理軟件。肯定有什麼力量隱藏在看似簡單的外表下使得大家生活簡化，更加高效。

現實世界時殘酷的，不要想當然認為采用一項新技術隻會帶來享受。過去幾年經過一些項目的磨練，經曆過奇怪的環境，我認為Docker也不例外。但是某一個經驗一般可以直接應用到項目的下一階段。要想從Docker獲得功力，必須浸淫到實際項目中去磨練。

過去一年中，我全身心投入去教授我的關於Dokcer基礎的書，Docker in Action。

我注意到幾乎所有人開始學習Docker技術時都會糾結於如何創建開發環境，然後才能了解生態係統之內大家的關係。每個人開始都會認為使用Docker會使環境搭建變的簡單，也不是完全不對，有很多“容器化”教程都涵蓋了創建一個image和如何將某個工具打包到容器（Container）內，但是如何將開發環境Docker化是一個完全不同的事情。

作為一個踏坑先驅者，我可以分享一下我的經驗。

我曾經是一個資深Java使用者，但這個分享的經驗不是關於Java的，而是圍繞著我使用Go和Node開發應用發生的。我有一定的Go開發經驗，主動提高在這一領域的能力。進入一個不熟悉領域迅速上手碰到的主要問題就是如何獲得正確的工作流，而且我還比較厭惡在筆記本上不斷安裝軟件，這些都驅使我嚐試用Docker做這些工作，或者有時候采用Vagrant。

我所參與的項目是用Go寫一個標準的REST服務，基於gin，依賴Redis和NSQ的某些庫和服務。也就是說需要import一些本地運行著的Redis和NSQ實例的庫，更有趣的是我還使用了一些服務於NGINX的靜態資源。

對門外漢來說，Go是一種編程語言，實際上還有一種命令行工具也叫“go”。從依賴型管理、編譯、測試用例到其它各種任務都使用它。對Go項目來說，除了Git和一個好用的編輯器，剩下就是跟它打交道了。然而還是有一個問題，我不想在筆記本上安裝Go，筆記本上我隻想安裝Git和Docker。這些問題限製了其他環境下的兼容性，並且對新手來說降低了門檻。

這個項目有運行時依賴，意味著此工具集需要為簡單環境定義和編排而包括Docker Compose。 很多人會為此感到不適應，那麼我們怎麼辦？開始創建一個Dockerfile或者docker-compose.yml？好吧，先讓我告訴大家我是怎麼辦的，然後解釋為什麼這麼做。

此案中，我希望我的本地包是完全自動的。我不喜歡手動逐條執行步驟，而且我的vim配置文件也很簡單。我隻想從“是否運行”層次控製運行環境。本地化開發環境目標被快速複製，不僅用於提高生產效率，而且用於共享Docker images。 我最終完成了Dockerfile，用來產生包含Go，Node，和我最經常使用的打包工具Gulp的images。 此Dockerfile沒有嵌入代碼，image也沒有嵌入Gulpfile。相反的，在一個建立了的GOPATH（Go workspace的根路徑）上定義了一個卷。

最終，我為此images設置了給gulp提供服務的entrypoint，設置默認命令來監控。輸出images肯定不是我稱為build artifact的東西，從這個意義上來講，此環境唯一做的就是提供了一個運行實例，幫助我們判斷是否代碼運行。對我的場景來說，運行的非常棒。而我將“artifacts”用於稱唿另外一個build。

下一步我用Compose定義本地開發環境。首先定義了在images中用到的所有Docker Hub 中定義的依賴服務，將他們連接到某一個“目標”服務。此服務引用了新Dockerfile從哪裏生成，將本地源目錄綁定到新image期望輸出的掛載點，暴露一些可以測試的端口。然後，添加了一個服務，可以不斷地向目標服務循環發起一係列集成測試。最終，我添加了NGINX服務，掛載了有很多配置文件和靜態assets的卷。使用卷的好處在於重複使用配置文件和assets而不用重建image。

$ cat ./service/local.df
FROM golang:alpine
RUN apk --update add --no-cache git nodejs
RUN npm install --global gulp
ENV GOPATH=/go PATH=$PATH:/go/bin
VOLUME ["/go/src/github.com/.../myproj", "/go/pkg","/go/bin"]
WORKDIR /go/src/github.com/.../myproj
# Bring in dependencies in the image
RUN go get github.com/bitly/go-nsq && \
go get github.com/codegangsta/cli && \
go get github.com/gin-gonic/gin
CMD ["gulp"]
$ cat ./service/gulpfile.js
var gulp  = require('gulp');
var child = require('child_process');
var server = null;
gulp.task('default', ['watch']);
gulp.task('watch', function() {
gulp.watch('./**/*.go', ['fmt','build','spawn']);
});
gulp.task('fmt', function() {
return child.spawnSync('go', ['fmt']);
});
gulp.task('build', function() {
return child.spawnSync('go', ['install']);
});
gulp.task('spawn', function() {
if (server)
server.kill();
server = child.spawn('myproj');
server.stderr.on('data', function(data) {
process.stdout.write(data.toString());
});
server.stdout.on('data', function(data) {
process.stdout.write(data.toString());
});
});
$ cat docker-compose.yml
web:
image: nginx
volumes:
- ./web/assets:/var/www
- ./web/config:/etc/nginx/conf.d
integtest:
build: ./integ
links:
- service
service:
build: ./service
dockerfile: local.df
volumes:
- ./service/src/:/go/src/github.com/.../myproj
links:
- nsqd
- redis
nsqd:
image: nsqio/nsq
...
redis:
image: redis
... 

所有代碼最終會在電腦上生成本地開發環境，當使用：

docker-compose up –d

時，會啟動git clone，然後循環運行；不需要重建image或者重啟容器。每當.go文件發生變化，Gulp就會重建，並且在運行的容器中重啟我的服務。就這麼簡單。

創建此環境很簡單嗎？不盡然，但是確實實現了。難道不用容器，而在本地直接安裝Go，Node，Gulp不是更簡單嗎？也許在這個場景是，但也隻限於用Docker運行此依賴服務。我不喜歡這樣。

我曾經要管理這些工具的不同版本，而產生了複雜的環境變量，到處生成artifacts。我不得不提醒同事們注意這些容易發生衝突的環境變量，他們太缺乏集中版本控製了。

也許你並不喜歡上麵描述的環境，或者對項目有不同的需求。很好，確實是這樣，本文並不是讓所有工具都運行在Docker中，如果這樣就說明並沒考慮過要解決什麼問題。

當我設計這個環境時，考慮過下麵幾個問題，顧慮，以及某些潛在答案。當開始Docker工作環境時，就會發現實際情況可能比自己的回答更糟糕。
當你考慮打包和環境時，最先考慮的因素是什麼？
這個確實是最重要的問題。在此場景中，有幾個選項。我可以使用go直接在容器內編程，看起來如下：

# get dependencies
$ docker run --rm -v "$(pwd)"/go/src/app golang:1.5 go get -d -v
# start the other services
# build and link
$ docker run --rm -v "$(pwd)":/go/src/app golang:1.5 go install \
github.com/allingeek/myproj
# run the program stand alone
$ docker run --rm -v "$(pwd)"/bin/myproj:/bin/myproj alpine myproj
# to iterate, make changes and repeat the last two steps 

其實這個示例中大部分bolierplate可以通過shell別名或者函數隱藏，感覺Go是安裝在自己的設備中似的，還可以跟Go工作流聯係，創建artifacts。這些特性對非服務項目有益處，但是對庫和軟件項目就不一定了。

假設你已經在使用Gulp、make、ant或者其他腳本，那麼可以繼續，並且使用Dokcer作為這些工具的目標。

另外一種方法，我可以通過使用Dockerbuild來定義和控製我的build，獲得更多麵向Docker的經驗。代碼如下：

$ cat Dockerfile
FROM golang:1.5-onbuild
# start the other services
# install dependencies, build, and link
$ docker build -t local/myproj .
# run the program
$ docker run --rm local/myprog
# to iterate, make changes and repeat the last two steps

使用Dokcer來控製build有若幹好處。可以使用以前編譯好的image，Dockerfilebuilds使用緩存方法，使得編譯工作隻重複最小的步驟（假設有一個很棒的Dockerfile）。最後，這些builds生成的images也可以跟其他開發者共享。

這個案例中，我使用golang資源庫中的onbuildimage作為基礎。其中包括一些很棒的下載依賴包邏輯。這個方法會生成可以方便用於其他非生產環境的Dockerimage。這個方法對於生產級別的image的問題在於，必須有步驟避免大image並且包括某些初始化腳本，用於啟動和監控服務前驗證狀態。

有意思的是，Docker使用一係列腳本，Makefiles和Dockerfiles。build係統相對很健壯了，負責各種測試，linting等，以及各種操作係統和架構的artifacts。本場景中，容器是用來產生二進製的工具，然而是從一個本地build image中實現的。

擴充Docker build的選項，可以使用Compose來定義一整套開發環境。

$ cat Dockerfile
FROM golang:1.5-onbuild
$ cat docker-compose.yml
service:
build: .
links:
- redis
- nsq
redis:
image: redis
nsq:
image: nsqio/nsq
# install dependencies, build, link, launch dependency services, run
$ docker-compose up -d
# to iterate, make changes and then
$ docker-compose build && docker-compose up -d

Compose負責環境管理。如果覺得係統非常幹淨並不奇怪，Compose把所有事情都聯係起來，優化卷管理，當images缺失時自動build，匯總日誌輸出。我之所以選這些開關是為了簡化服務依賴，也因為它能生成我需要的artifacts。

這個示例是一個運行時容器，Compose或者Docker都有合適的工具做到這點。此場景中，也可能更需要一個分布式image，或者可能希望build可以為本機產生一個二進製文件。

如果期望獲得想要的image，必須確保源碼或者預編譯庫在build時候嵌入image中。build時候沒有掛載卷，也即需要每次重複時都要重建image。

如果希望在容器內部產生某些artifacts，則需要引入掛載卷。使用Docker命令行或者Compose環境可以很容易實現。但是要注意，除非容器在運行，否則build並不工作，也就意味著不能隻用dockerbuild。

匯總

目前沒有Docker方式創建開發環境。Docker是一個可編排工具，不隻是聖書。與其使用別人已有的dockerbuild係統，不如花一定時間學習此工具，明確自己的需求，然後創建適合自己的Docker環境。

記住，如果需要比Docker Fundamentals進階書籍，那麼Docker in Action很快就會出版。大家可以留意。


原文鏈接：Development Environments with Docker（翻譯：楊峰）

原文發布時間為：2016-01-18

本文作者：hokingyang

本文來自雲棲社區合作夥伴DockerOne，了解相關信息可以關注DockerOne。

原文標題：用Docker創建開發環境