ベースの無人ビルドCI-CDシステム

kubernetesクラスタの三段階のインストール

CIの概要

構成全体のワークフローを定義を用いて記述することができます

プログラマは怠惰な動物ですので、私はあなたのワークフローにも何かを繰り返した場合、作業の重複の問題に対する解決策のすべての種類は、あなたが最適化する方法を考えなければならないかもしれませんしたいです

継続的インテグレーションは、あなたは、単に次の観光名所の多くを解決するために、コードのアクションを提出することにより、構築するために、重複コード、テストの自動化、出版、作業の重複を解決する私たちを助けることができるということです。

コンテナ技術は、それが以前よりもずっと完璧になります。

典型的なシナリオ：

我々は仮定は、フレームワークに基づいており、フロントエンドエンジニアリングを書いたテストコードの提出後にレースを実行し、それにディレクトリをDISTに圧縮し、このディレクトリの静的ファイルのnginxのプロキシを構築することを望んで、開発をvue.js。
最後に、倉庫にドッカー鏡像を結びました。あなたも、ライン上のフロー稼働を増やすことができます。

今、あなたは、単にGitのプッシュアクション、そしてすべてのCIツールは、あなたが解決するのに役立ちます教えて！あなたが費やすしていない場合、このようなシステムは、その後、あなたが待っているか尋ねます。次は、このすべてをご紹介するためのシステムとなります。

コード倉庫管理

すべてこのスラグスラグSVNソフトウェアの最初できるだけ早く尊敬のうち、何も言うこと、本当に私はSVNの存在を感じることはgitする必要はありません。

だから我々は、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ツール

あなたはドローンを使用する場合。。。

パッキング：

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アカウントを使用することができます

各ステップは、各プラグインは様々な組み合わせで、また、コンテナ容器である、単にタイポグラフィ

この主表面的なコンテンツを使用するためにどのように私は詳細には触れませんが、ピットの多くの場所があります。

• マシンはドッキングウィンドウプラグインでいくつかのドッキングウィンドウとして、これはドローンの問題ではない、唯一のドッキングウィンドウのサポートにドッキングウィンドウをドッキングウィンドウと言うことができドローンAUFSを使用しようと、いくつかのプラグインが実行されていないデバイスマッパーは、十分ではありませんインストールすることができます
• aufsのサポートのためのCentOSのは、ここであなたがCentOSのサポートAUFSを使用したい場合は、あなたが投げるトスする必要があり、十分ではない、とコミュニティプログラム：https://github.com/sealyun/kernel-ml-aufs
• 最も低いカーネルよりも、はるかに安定した機械カーネルのドローンが4.9にアップグレードされ、その後、ドッキングウィンドウの使用overlay2のストレージドライブ、コンテナを実行するために、カーネルの高いバージョンは、私はまた、長い時間の練習をお勧めします

インストール2 インストールK8S：

helm install stable/drone

記事を使用してください

まず、自分のホームディレクトリのコードリポジトリに3つのファイルを作成します。

• .drone.yml：なし本質的な違いは説明のビルドと展開プロセス（狭義）、プロセスの設定ファイル（一般）CI / CD
• Dockerfile：どのように鏡の中にパッケージアプリケーションを伝えるために、当然の、コンテナではない配信が必要とされない可能性がある場合
• K8S YAMLプロファイルまたはドッキングウィンドウ・コン文書やチャートパッケージ：どのようにあなたのアプリケーションの配備を指示します
• その他：その他KUBE-config設定

プロジェクトの下で、あなたはgogsとの同期を見ることができるアイテムのページリストの後ドローンにログオンするアカウントのパスワードを、スイッチ上のターンは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このボリューム・コンテナのそれぞれの開始は、生成物を得、このようなビルド手順は、この容器内で使用することができます

複合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環境として、ときに便利、分離リリースまたは、

あなたが基本イメージからgolangを持つことができないところDockerfileので、あなたの画像を小さくします。別の例は、必要性のJava Mavenのビルドで、オンラインで実行する必要はありません。

また、分離することができます。

、想像力と遊ぶドローンが死んで使用しない場合は、上記の必要性は、理解するように注意し、慎重になり、再びすべての単語を読み取ります。そして、重要なポイントを要約したものです。

どんな各ステップの機能を、あなただけの次のステップの実装に終了し、通常、コンテナからの助けをだますん自体をドローン、終了することができませんでした。

コンパイルは、ドローン倉庫、展開、通知が行われたミラー機能に提出ミラーリング機能、プラグインと呼ばれる容器の決定の機能は、プラグインは、本質的に鏡で、小さな違いがあり、Diudiuは、背後に言いました

これは、そのような必要性の達人として、あなたが鏡をやって欲しいものを手に入れることを意味し、時間をコンパイルし、ミラーリングMavenは、展開されたときにドッキングK8Sを必要とし、その後、クライアントのイメージが提唱しkubectlんが、物理マシンへの展開、その後、前方に置く
ansible鏡画像をなど、想像力、柔軟性。

ドローンの環境変数

ランニングの利点は、コード、アップグレード、およびので簡単ですが、パイプライン修正するたびに、どのバージョンの知っているように、時には我々は、タグとのドッキングウィンドウのミラーgitのタグのうち、一貫性のあるCIを望んで
明らかに退屈ファイルを上のドローン、その後、私たちはこの問題を解決するための多くの環境変数があることができます：

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タグイベントは私たち自身の開発プロセスがするようにそうでない場合は、最新のを使用して、パイプラインはミラータグとしてgitのタグになりトリガ場合は
、常に最新の繰り返しを使用することができますバージョンはそれについて考える、タグを作り、あなたが与えられたテストを生成することができますミラーをテストするために、非常にエレガントな、あなたはエラーになりやすい、何も変更しない必要はありません

同様の変数は、このようなcommitID Gitのブランチ情報など、として、使用することができ、他の多くの環境があるかをチェックすることができます

ドッキングK8S練習

：その後、K8Sクラスタで選択開始Kubernetesクラスタの三段階のインストールなどを無視して、広告を。。。

上記寝具、ドッキングK8Sは非常にシンプル：前方に置くkubectlミラーするプロセスに埋め込むことができます。

このプロジェクトは、コードにYAMLファイルをK8S、その後、直接pipelieに適用されます

  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 

しかし、いくつかの詳細は、ベストプラクティスは、次のとおりです。

• 同じコードディレクトリにkubeconfigファイルのK8S（これは安全ではありませんが、幸いな民間の倉庫は、あなたも秘密ドローンを利用することができ、罰金が展開されません）
• YAMLファイルK8Sはどのように設定鏡で展開しますか？すべての変更test.yaml、より正確な
• 複数のクラスタは、YAML行う方法を別々に設定した場合は？複数のYAMLを書きますか？混乱、非常にエレガント

だから我々は、実権を握って展開図を、ご紹介します：

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ファイルを、変更する必要はありません、完璧なソリューション

完全な統一を達成するために、ミラー構成でYAMLとそれほどgitのタグ画像タグ：

    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

上記の問題にもっとエレガントなソリューション

詳細：展開が手動で入力するときにイベントは、gitのイベントは、手動でイベント処罰することができかもしれがトリガされ、ドローンサポートコマンド・ライン・トリガ

ドローンは、ページ上の対応するイベントをトリガすることができるように私たちは、二次開発を行い、

原則記事

ドローンに倉庫を開くと、倉庫のウェブフックを設定します、あなたがドローンにイベント通知をgitのことができますので、あなたは、プロジェクト設定で見ることができ、ドローンはイベントに基づいてコードのプロセスを引っ張って行くために行ってきました

パイプラインの基本原理

理解の原理は、それ以外の場合は死との事を置く、システムを使用することは非常に重要です。

コンテナからのパイプラインがそれを担当し、システムはコンテナをやって気にしない、ユーザーが文の記事が複数回強調決定し、それを数回読むことが重要です

プラグ原理

既存の多くを反映する可能性があることプラグインミラーは、直接プラグインプロセスとして無人機に埋め込むことができます。

小さな違いは、あなたがそのような時間がドッキングウィンドウの画像を公開演奏として、平均Diudiuよりもミラーイメージをより多くの事を行うことですパラメータの数、ともドローンにいくつかのプラグインを見つけることですがあります：

  publish:
    image: plugins/docker
    repo: octocat/hello-world
    tags: [ 1, 1.1, latest ]
    registry: index.docker.io

あなたはそれがドローンの治療、これらのパラメータは、コンテナに渡された環境変数に変換するときに実際には非常に簡単であるかのパラメータ、タグをレポ見つけるでしょう、
とコンテナは、これらのパラメータに対処します。
自然はこの事を行うことです。

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

その後、我々はプラグインがシンプルでカスタマイズ、単に特定の環境変数を処理するためのスクリプトを書くことができ、そのようなプラグインのカールのように：

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

標識ドッキングウィンドウミラー、それが行われています

だから、ほとんどの場合、私たちは、怠惰な何も書かないだろう、それは望んでいる容器に直接コマンドを実行し、また、カールのニーズである、そしてプラグインを書いていません

pipeline:
  webhook:
    image: busybox  # 直接用busybox
    command: 
    - curl -X POST -d 123 http://foo.com  完事，插件都懒得开发了

複雑な機能のいくつかは、まだ、このようなミラーを公開プラグインの使用などのプラグインを開発する必要があることは注目に値します。プラグインIについて追加したいと思い
、それがドッキングウィンドウドッキングウィンドウエンジン内部で再生され、ドッキングウィンドウのドッキングウィンドウエンジンで鏡に遊んでいた
ストレージドライブがサポートされていませんdevicemapperので。AUFSでoverlay2、またはUbuntuのでカーネルをアップグレードしてください

その他の推奨

• ミラー倉庫：ハーバー
• 製品ギャラリー：ネクサスは、 Mavenのリポジトリを行い、yumのリポジトリが非常に適切なバイナリファイルを入れて、それを強くお勧めします

概要

効率的な自動化を実現するために、コードなどすべてがインターフェイス少しポイントのように非常に重要な、多くの人々がライン上で多くのパラメータを記入することで、実際には、それは非常にエラーが発生しやすい方法です
必ずしも効率を改善しません。プロジェクトをビルドするにはどうすればよい、公開する方法、コードを展開する方法の人々が、最終的には人々がそれをトリガーしないプログラムを聞かせてください、あいまいあってはなりません。

スキャンコード懸念sealyun

探索するための個人的な意見は、QQグループを追加することができます：98488045