基於drone的CI/CD,對接kubernetes實踐教程_Kubernetes中文社群
CI 概述
用一個可描述的配置定義整個工作流
程式設計師是很懶的動物,所以想各種辦法解決重複勞動的問題,如果你的工作流中還在重複一些事,那麼可能就得想想如何優化了
持續整合就是可以幫助我們解決重複的程式碼構建,自動化測試,釋出等重複勞動,通過簡單一個提交程式碼的動作,解決接下來要做的很多事。
容器技術使這一切變得更完美。
典型的一個場景:
我們寫一個前端的工程,假設是基於vue.js的框架開發的,提交程式碼之後希望跑一跑測試用例,然後build壓縮一個到dist目錄裡,再把這個目錄的靜態檔案用nginx代理一下。
最後打成docker映象放到映象倉庫。 甚至還可以增加一個在線上執行起來的流程。
現在告訴你,只需要一個git push動作,接下來所有的事CI工具會幫你解決!這樣的系統如果你還沒用上的話,那請問還在等什麼。接下來會系統的向大家介紹這一切。
程式碼倉庫管理
首先SVN這種渣渣軟體就該儘早淘汰,沒啥好說的,有git真的沒有SVN存在的必要了我覺得。
所以我們選一個git倉庫,git倉庫比較多,我這裡選用gogs,gitea gitlab都行,根據需求自行選擇
docker run -d --name gogs-time -v /etc/localtime:/etc/localtime -e TZ=Asia/Shanghai --publish 8022:22 \ --publish 3000:3000 --volume /data/gogs:/data gogs:latest
訪問3000埠,然後就沒有然後了
gogs功能沒有那麼強大,不過佔用資源少,速度快,我們穩定運行了幾年了。缺點就是API不夠全。
CI 工具
當你用過drone之後。。。
裝:
version: '2' services: drone-server: image: drone/drone:0.7 ports: - 80:8000 volumes: - /var/lib/drone:/var/lib/drone/ restart: always environment: - DRONE_OPEN=true - DOCKER_API_VERSION=1.24 - DRONE_HOST=10.1.86.206 - DRONE_GOGS=true - DRONE_GOGS_URL=http://10.1.86.207:3000/ # 程式碼倉庫地址 - DRONE_SECRET=ok drone-agent: image: drone/drone:0.7 command: agent restart: always depends_on: - drone-server volumes: - /var/run/docker.sock:/var/run/docker.sock environment: - DOCKER_API_VERSION=1.24 - DRONE_SERVER=ws://drone-server:8000/ws/broker - DRONE_SECRET=ok
docker-compose up -d 然後你懂的,也沒有然後了
用gogs賬戶登入drone即可
每個步驟就是個容器,每個外掛也是個容器,各種組合,簡直就是活字印刷術
怎麼使用這種初級膚淺的內容我就不贅述了,但是有很多坑的地方:
- 裝drone的機器能用aufs儘量用,device mapper有些外掛是跑不了的,如一些docker in docker的外掛,這不算是drone的毛病,只能說docker對 docker in docker支援不夠好
- 最推薦的是drone的機器核心升級到4.9以上,然後docker使用overlay2儲存驅動,高版本核心跑容器筆者也實踐過比較長的時間了,比低核心穩定很多
helm install stable/drone
使用篇
首先在你的程式碼倉庫主目錄下新建三個檔案:
- .drone.yml : 描述構建與部署的流程(狹義),流程配置檔案(廣義)CI/CD無本質區別
- Dockerfile : 告訴你的應用如何打包成映象,當然如果不是容器化交付可以不需要
- k8s yaml配置檔案 or docker-compose檔案 or chart包 :告訴你的應用如何部署
- 其他 :如kube-config等
用gogs賬戶密碼登入到drone頁面上之後同步下專案就可以看到專案列表,開啟開關就可以關聯到git倉庫,比較簡單,自行探索
官方事例
pipeline: backend: # 一個步驟的名稱,可以隨便全名 image: golang # 每個步驟的本質都是基於這個映象去啟動一個容器 commands: # 在這個容器中執行一些命令 - go get - go build - go test frontend: image: node:6 commands: - npm install - npm test publish: image: plugins/docker repo: octocat/hello-world tags: [ 1, 1.1, latest ] registry: index.docker.io notify: image: plugins/slack channel: developers username: drone
各步驟啟動的容器共享workdir這個卷, 這樣build步驟的結果產物就可以在publish這個容器中使用
結合Dockerfile看:
# docker build --rm -t drone/drone . FROM drone/ca-certs EXPOSE 8000 9000 80 443 ENV DATABASE_DRIVER=sqlite3 ENV DATABASE_CONFIG=/var/lib/drone/drone.sqlite ENV GODEBUG=netdns=go ENV XDG_CACHE_HOME /var/lib/drone ADD release/drone-server /bin/ # 因為工作目錄共享,所以就可以在publish時使用到 build時的產物,這樣構建和釋出就可以分離 ENTRYPOINT ["/bin/drone-server"]
上面說到構建與釋出分離,很有用,如構建golang程式碼時我們需要go環境,但是線上或者執行時其實只需要一個可執行檔案即可,
所以Dockerfile裡就可以不用FROM一個golang的基礎映象,讓你的映象更小。又比如java構建時需要maven,而線上執行時不需要,
所以也是可以分離。
用drone時要發揮想象,千萬不要用死了,上面每句話都需要仔細讀一遍,細細理解。再總結一下關鍵點:
drone自身是不管每個步驟是什麼功能的,只傻瓜式幫你起容器,跑完正常就執行下個步驟,失敗就終止。
編譯,提交到映象倉庫,部署,通知等功能都是由映象的功能,容器的功能決定的 drone裡叫外掛,外掛本質就是映象,有一丟丟小區別後面說
這意味著你想幹啥就弄啥映象,如編譯時需要maven,那去做個maven映象,部署時需要對接k8s,那麼搞個有kubectl客戶端的映象;要物理機部署那麼搞個
ansible的映象,等等,發揮想象,靈活使用。
drone環境變數
有時我們希望CI出來的docker映象tag與git的tag一致,這樣的好處就是知道執行的是哪個版本的程式碼,升級等等都很方便,不過每次都去修改pipeline
檔案顯然很煩,那麼drone就可以有很多環境變數來幫助我們解決這個問題:
pipeline: build: image: golang:1.9.2 commands: - go build -o test --ldflags '-linkmode external -extldflags "-static"' when: event: [push, tag, deployment] publish: image: plugins/docker repo: fanux/test tags: ${DRONE_TAG=latest} dockerfile: Dockerfile insecure: true when: event: [push, tag, deployment]
這個例子${DRONE_TAG=latest} 如果git tag事件觸發了pipeline那就把git tag當映象tag,否則就用latest,這樣我們自己研發過程中就
可以一直用latest迭代,覺得版本差不多了,打個tag,生成一個可以給測試人員測試的映象,非常優雅,不需要改什麼東西,不容易出錯
同理還有很多其它的環境變數可以用,如git的commitID 分支資訊等等, 這裡可以查
對接k8s實踐
首先得有個k8s叢集,那麼首選:kubernetes叢集三步安裝 廣告,無視就好。。。
有了上面的鋪墊,對接k8s就相當簡單了:搞個kubectl的映象嵌入流程中即可:
把專案的k8s yaml檔案放到程式碼中,然後pipelie裡直接apply
publish: image: plugins/docker # 映象倉庫,執行Dockerfile外掛 tags: - ${DRONE_TAG=latest} insecure: true # 照抄 deploy: image: kubectl:test # 這個映象自己去打即可 commands: - cat test.yaml - ls - rm -rf /root/.kube && cp -r .kube /root # k8s 的kubeconfig檔案,可以有多個,部署到哪個叢集就拷貝哪個kubeconfig檔案 - kubectl delete -f test.yaml || true - kubectl apply -f test.yaml
不過最佳實踐還有幾個細節:
- k8s 的kubeconfig檔案同樣放在了程式碼目錄(這個不×××全,不過倉庫私有還好,還可以利用drone的secret,不細展開)
- k8s 部署的yaml檔案裡的映象怎麼配置? 每次都修改test.yaml多不爽
- 如果多個叢集yaml配置有區別怎麼辦?寫多個yaml?造成混亂,非常不優雅
所以我們引入chart, 用helm進行部署:
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: test namespace: {{ .Values.namespace }} spec: replicas: {{ .Values.replicaCount }} template: metadata: labels: name: test spec: serviceAccountName: test containers: - name: test image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}" # deployment的yaml檔案是模板,建立時再傳參進來渲染 imagePullPolicy: {{ .Values.image.pullPolicy }} ....
注意,有了模板之後,我們部署v1版本和v2版本時就不需要改動yaml檔案,這樣降低出錯風險,pipeline執行時把環境變數傳進來,完美解決
這樣git tag 映象tag與yaml裡映象配置實現了完全的統一:
deploy_dev: # 部署到開發環境 image: helm:v2.8.1 commands: - mkdir -p /root/.kube && cp -r .kube/config-test101.194 /root/.kube - helm delete test --purge || true - helm install --name test --set image.tag=${DRONE_TAG=latest} Chart when: event: deployment environment: deploy_dev deploy_test: # 部署到測試環境 image: helm:v2.8.1 commands: - mkdir -p /root/.kube && cp -r .kube/config-test101.84 /root/.kube # 兩個環境使用不同的kubeconfig - helm delete test --purge || true - helm install --name test --set image.tag=${DRONE_TAG=latest} Chart # 把git tag傳給helm,這樣執行的映象就是publish時構建的映象,tag一致 when: event: deployment environment: deploy_test
以上,優雅的解決了上面問題
細節:event可以是git的事件也可以是手動處罰的事件,型別是deployment時就是手動觸發的,drone支援命令列觸發
我們進行了二次開發,讓drone可以在頁面上觸發對應的事件
原理篇
drone上開通一個倉庫時,會給倉庫設定一個webhook,在專案設定裡可以看到,這樣git的事件就可以通知到drone,drone根據事件去拉取程式碼走流程
pipeline基本原理
理解原理對使用這個系統非常重要,否則就會把一個東西用死。
pipeline就負責起容器而已,容器幹啥的系統不關心,使用者決定 這句話本文不止強調過一次,非常重要多讀幾遍
外掛原理
映象即外掛,也就是可能現有很多映象都能直接當作外掛嵌入到drone流程中。
有個小區別是,你會發現drone有些外掛還帶一些引數,這就是比普通的映象多做了一丟丟事,如publish時打docker的映象:
publish: image: plugins/docker repo: octocat/hello-world tags: [ 1, 1.1, latest ] registry: index.docker.io
你會發現它有 repo tags什麼的引數,其實drone處理時非常簡單,就是把這些引數轉化成環境變數傳給容器了,
然後容器去處理這些引數。
本質就是做了這個事情:
docker run --rm \ -e PLUGIN_TAG=latest \ -e PLUGIN_REPO=octocat/hello-world \ -e DRONE_COMMIT_SHA=d8dbe4d94f15fe89232e0402c6e8a0ddf21af3ab \ -v $(pwd):$(pwd) \ -w $(pwd) \ --privileged \ plugins/docker --dry-run
那我們自定義一個外掛就簡單了,只要寫個指令碼能處理特定環境變數即可,如一個curl的外掛:
pipeline: webhook: image: foo/webhook url: http://foo.com method: post body: | hello world
寫個指令碼
#!/bin/sh curl \ -X ${PLUGIN_METHOD} \ # 處理一個幾個環境變數 -d ${PLUGIN_BODY} \ ${PLUGIN_URL}
FROM alpine ADD script.sh /bin/ RUN chmod +x /bin/script.sh RUN apk -Uuv add curl ca-certificates ENTRYPOINT /bin/script.sh
docker build -t foo/webhook . docker push foo/webhook
打成docker映象,大功告成
所以大部分情況我們會很懶的什麼也不寫,直接在容器裡執行命令就是了,同樣是一個curl的需求,不寫外掛的話
pipeline: webhook: image: busybox # 直接用busybox command: - curl -X POST -d 123 http://foo.com 完事,外掛都懶得開發了
值得注意的是一些複雜功能還是需要開發外掛的,如publish映象時用的外掛。關於該外掛我想補充一句
它是docker裡面起了一個docker engine,用docker內的docker engine進行打映象的
所以devicemapper儲存驅動是支援不了的。請升級核心用overlay2,或者ubuntu用aufs
其它推薦
- 製品庫:nexus 做maven倉庫,yum倉庫放二進位制檔案等非常合適,強烈推薦
總結
要實現高效的自動化,everything as code很重要,很多人喜歡在介面上點點點 填很多引數上線,其實是一種很容易出錯的方式
不一定能提高效率。 你們專案如何構建,如何釋出,如何部署都應該是程式碼,沒有二義性,把人做的事讓程式做,最終人僅是觸發而已。
個人見解,探討可加QQ群:98488045