基於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倉庫,比較簡單，自行探索
基於drone的CI/CD對接kubernetes，靈活與自由

官方事例

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

基於drone的CI/CD，對接kubernetes實踐教程_Kubernetes中文社群

CI 概述

用一個可描述的配置定義整個工作流

程式碼倉庫管理

CI 工具

使用篇

官方事例

drone環境變數

對接k8s實踐

原理篇

pipeline基本原理

外掛原理

其它推薦

總結

基於drone的CI/CD，對接kubernetes實踐教程_Kubernetes中文社群

Kubernetes成立StackPoint.io與GitLab合作，推出Kubernetes解決方案_Kubernetes中文社群

藉助 Calico，管窺 Kubernetes 網路策略_Kubernetes中文社群

kubeadm原始碼分析（內含kubernetes離線包，三步安裝）_Kubernetes中文社群

Kubernetes 1.8.x 全手動安裝教程_Kubernetes中文社群

Kubernetes教程/入門教程_Kubernetes中文社群

Docker EE 2.0版本釋出，完美支援Kubernetes容器編排_Kubernetes中文社群

Helm 成功逆襲，脫離Kubernetes，被CNCF納入麾下_Kubernetes中文社群

Kubernetes 網路改進的三項實踐分享_Kubernetes中文社群

Prometheus監控實踐：Kubernetes叢集監控_Kubernetes中文社群

Kubernetes在企業級架構中的實踐分享_Kubernetes中文社群

不止軟體廠商，網路廠商思科也來分割 Kubernetes 市場蛋糕_Kubernetes中文社群

Google Kubernetes引擎1.10版正式上線，支援虛擬私有云_Kubernetes中文社群

Kubernetes另一位創辦人自創的容器新創公司Heptio，選擇與AWS結盟_Kubernetes中文社群

說說Kubernetes是怎麼來的，又是怎麼沒的_Kubernetes中文社群

微軟開源容器開發工具Draft，加快應用程式在Kubernetes環境部署_Kubernetes中文社群

Google與思科合作推廣混合雲架構,支援Kubernetes;Azure容器服務ACS改名AKS，以K8S服務為主_Kubernetes中文社群

Kubernetes Ingress解析_Kubernetes中文社群

使用traefik作為ingress controller透出叢集中的https後端（如kubernetes dashboard）_Kubernetes中文社群

多容器POD及Kubernetes容器通訊_Kubernetes中文社群

基於drone的CI/CD，對接kubernetes實踐教程_Kubernetes中文社群

CI 概述

用一個可描述的配置定義整個工作流

程式碼倉庫管理

CI 工具

使用篇

官方事例

drone環境變數

對接k8s實踐

原理篇

pipeline基本原理

外掛原理

其它推薦

總結

相關推薦