droneベースのCI/CDドッキングkubernetes、柔軟性と自由

kubernetesクラスタの3ステップインストール
CIの概要
説明可能な構成でワークフロー全体を定義する
プログラマーは怠け者なので、いろいろな方法で繰り返し労働の問題を解決したいと思っています.もしあなたのワークフローの中で何かを繰り返しているなら、どのように最適化するかを考えなければなりません.
継続的な統合は、重複するコード構築、テストの自動化、パブリケーションなどの重複作業を解決し、コードを提出する簡単な動作を通じて、次の多くのことを解決することができます.
容器技術はこのすべてをより完璧にした.
典型的なシーン:
vue.jsのフレームワークに基づいて開発されたと仮定して、コードを提出した後、テスト例を走って、buildをdistディレクトリに圧縮して、このディレクトリの静的ファイルをnginxでエージェントします.最後にdockerミラーとしてミラーウェアハウスに配置します.オンラインで実行されるプロセスを追加することもできます.
今あなたに教えて、ただ1つの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に対してサポートが足りないとしか言えません

centosはaufsのサポートが不十分で、centosでaufsをサポートしたいなら、あなたは振り回さなければなりません.コミュニティ案はここにあります.https://github.com/sealyun/kernel-ml-aufs

で最も推奨されているのはdroneのマシンカーネルを4.9以上にアップグレードし、dockerはoverlay 2ストレージ駆動を使用し、高バージョンのカーネル走容器筆者も比較的長い時間を実践し、低カーネルよりずっと安定している

インストール方式2、k 8 sにインストール:

helm install stable/drone

使用編
まず、コード・ウェアハウスのホーム・ディレクトリの下に3つのファイルを新規作成します.

.drone.yml:構築と導入のプロセス(狭義)を記述し、プロセスプロファイル(一般化)CI/CDに本質的な違いはない

Dockerfile:アプリケーションをミラー化する方法を教えてくれます.もちろん、コンテナ化されていなければ

は必要ありません.

k 8 s 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環境が必要ですが、オンラインまたは実行時に実行可能なファイルが1つだけ必要です.
だからDockerfileではFROMのgolangのベースミラーを使わずに、ミラーを小さくすることができます.例えばjava構築時にmavenが必要で、オンライン実行時には必要ありません.
だから分離することもできます.
droneを使うときは想像を発揮し、決して死なないでください.上の言葉はすべてよく読んで、よく理解しなければなりません.さらに重要なポイントをまとめます.
drone自体は各ステップがどんな機能であるかにかかわらず、馬鹿式に容器を持ち上げて、正常に走ったら次のステップを実行して、失敗したら終了します.
コンパイル、ミラーウェアハウスへの提出、配置、通知などの機能はすべてミラーの機能で、コンテナの機能によって決定されるdroneの中でプラグインと呼ばれて、プラグインの本質はミラーで、なくすと小さな違いがあります
これは、コンパイル時にmavenが必要な場合は、mavenミラーを作成し、配置時にk 8 sをドッキングする必要がある場合は、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ブランチ情報など、他にも多くの環境変数が使用できますが、ここでは調べることができます.
ドッキングk 8 s実践
まずk 8 sクラスタが必要ですが、第一選択:kubernetesクラスタ3ステップで広告をインストールし、無視すればいいです.の
上のマットがあれば、k 8 sをドッキングするのはかなり簡単です.kubectlのミラー埋め込みプロセスをすればいいです.
プロジェクトのk 8 s 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 

しかし、ベストプラクティスにはいくつかの詳細があります.

k 8 sのkubeconfigファイルもコードディレクトリに置かれています(これは×××全部ですが、倉庫の私有はまあまあですが、droneのsecretを利用して、細かく展開することはできません)

k 8 sが配備した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 }} 
....

テンプレートがあれば、v 1バージョンとv 2バージョンを配置するときに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ストレージドライバはサポートされていません.カーネル用overlay 2またはubuntu用aufsをアップグレードしてください
その他の推奨事項

ミラーウェアハウス:harbor

製品庫:nexusはmaven倉庫を作り、yum倉庫はバイナリファイルなどを置くのに非常に適しており、

を強くお勧めします.
まとめ
効率的な自動化を実現するにはeverything as codeが重要で、多くの人がインタフェースに多くのパラメータを点点してオンラインに記入するのが好きで、実は間違いやすい方法で効率を高めるとは限らない.あなたたちのプロジェクトはどのように構築して、どのように発表して、どのように配置してすべてコードで、二義性がなくて、人のしたことをプログラムにさせて、最終的に人はただ触発します.
個人見解、検討可加QQ群:98488045