軽量オープンソースツール Drone を使用して小規模チームに CI/CD を実装する

序文

継続的インテグレーションとビルドのためのツールは数多く存在します。Jenkins、Travis、CircleCIといった有名なツールに加え、最近人気のGitHub ActionsやGitLab CI/CDなども挙げられます。しかし、これらのツールは有料であったり、プライベートプロジェクトではサーバーリソースを大量に消費したりするため、個人開発者にとって使い勝手が悪いのが現状です。オープンソースで無料のDrone CIは、軽量ながらも高機能で、プライベートコードリポジトリを使用してサービスを自動的にコンパイル・ビルドできるため、わずか数行のスクリプトで自動デプロイを実現できます。この記事では、Giteaを例に、VPS上でGitea + Drone CIをベースとした継続的インテグレーションシステムをゼロから構築する方法を解説します。

Giteaの紹介

Giteaは、軽量でオープンソース、コミュニティ主導のコードホスティングソリューションです。バックエンドはGo言語で記述されており、MITライセンスの下で提供されています。Giteaの主な目標は、インストールが非常に簡単で、動作が高速で、スムーズなインストールとユーザーエクスペリエンスを提供するセルフホスト型のGitサービスを構築することです。バックエンド言語としてGoを使用しているため、実行ファイルを生成するだけで済みます。さらに、Linux、macOS、Windowsなどのクロスプラットフォーム対応に加え、x86、amd64、ARM、PowerPCなどの様々なアーキテクチャにも対応しています。

Giteaの機能

イベントタイムラインをサポート
SSHおよびHTTP/HTTPSプロトコルをサポート
SMTP、LDAP、リバースプロキシ経由のユーザー認証をサポートします。
リバースプロキシサブパスをサポート
ユーザー、組織、倉庫管理システムをサポートします。
リポジトリの共同作業者の追加と削除をサポートします
リポジトリおよび組織レベルの Web フック (Slack 統合を含む) をサポートします。
リポジトリの Git フックとデプロイメントキーをサポートします。
ウェアハウスの問題、プルリクエスト、Wiki をサポートします。
リポジトリとその wiki の移行とミラーリングをサポートします。
リポジトリファイルと wiki のオンライン編集をサポートします。
カスタムソースからの Gravatar および Federated Avatar をサポートします。
メールサービスをサポート
バックエンド管理パネルをサポート
MySQL、PostgreSQL、SQLite3、MSSQL、および TiDB (MySQL) データベースをサポートします。
多言語ローカリゼーションをサポート（21言語）

ドローン入門

Drone は Docker ベースの CI/CD ツールであり、すべてのコンパイル、テスト、およびデプロイメントプロセスが Docker コンテナ内で実行されます。

開発者はプロジェクトに .drone.yml ファイルを組み込み、コードを git リポジトリにプッシュするだけで、Drone が自動的にコードをコンパイル、テスト、デプロイします。

Drone を CI/CD ツールとして使用する理由は何ですか?

柔軟で強力な機能: ビルド、テスト、リリース、展開など、1 つのシステムで必要なことをすべて実行できます。
高い互換性: すべての SCM、すべてのプラットフォーム、すべての言語をサポートします。
環境のデプロイはシンプルです。Dockerコンテナをネイティブにサポートしており、2つのコンテナを起動するだけでデプロイが完了します。その他のビルド、テスト、デプロイツールは、必要に応じてDockerリポジトリから自動的にプルされます。
高いスケーラビリティ: 豊富な無料プラグインやカスタムプラグインを利用できる堅牢なプラグインシステム。
シンプルな構成: 公式の説明にあるように、「コードとしての構成」では、すべての機能、手順、ツール、コマンドが単一の YAML 構成ファイルで処理されます。
簡単なメンテナンス: ユーザーを登録したり権限を割り当てたりする必要がなく、SCM のアカウントシステムと権限管理を直接再利用できます。

インストール前の準備

Docker環境のインストール

1. まず、主要なパブリッククラウドプロバイダーが提供するクラウドプラットフォームから、対応するマシンを購入します。1コア2GBまたは2コア2GBの構成を選択できます。大規模な構成を購入する必要はありません。

2. マシンが起動したら、Docker環境をデプロイします。手動でデプロイするか、Ansibleスクリプトを使用するかを選択できます。今回はAnsibleを使用してデプロイします。デプロイスクリプトは以下のとおりです。(docker-install.yaml)

 ---

 - name : Dockerシステムを削除する
おいしい:
 名前：
 - dockerクライアント
- docker-client-最新版
- docker-common
 - docker 最新版
- docker-latest-logrotate
 - docker-logrotate
 - docker-selinux
 - docker-engine-selinux
 - dockerエンジン
状態:不在
タグ:
 - cicd
 - docker_remove

 - name : Dockerファイルを削除する
シェル: |
 rm -rf /etc/systemd/system/docker.service.d
 rm -rf /var/lib/docker
 rm -rf /var/run/docke
 rm -rf /etc/docker タグ:
 - cicd
 - docker_remove

 - name : Docker yum をインストール
おいしい:
 名前：
 - yum-utils
 -デバイス-マッパー永続データ
- lvm2
 状態：現在
タグ:
 - cicd
 - docker_install

 - name : yum マネージャーをインストールする
シェル: |
 yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo タグ:
 - cicd
 - docker_install

 - name : Dockerをインストールする
おいしい:
 名前: docker-ce
 状態：現在
タグ:
 - cicd
 - docker_install

 - name :ファイル用にDockerを構成する
ファイル：
 パス: "{{ item }}"
 状態:ディレクトリ
アイテム付き:
 - /etc/docker
 - /etc/systemd/system/docker.service.d
 タグ:
 - cicd
 - docker_install

 - name : config 用の Docker を構成する
テンプレート：
 ソース: "{{ item.name }}"
 宛先: "{{ item.dest }}"
 ループ:
 - { 名前: "daemon.json.j2" 、 保存先: "/etc/docker/daemon.json" }
 - { 名前: "docker.service.j2" 、 保存先: "/usr/lib/systemd/system/docker.service" }
 タグ:
 - cicd
 - docker_install

 - name : Dockerを起動しました
システムド:
 名前: docker
 有効: はい
状態:開始済み
タグ:
 - cicd
 - docker_install

 - name : Docker-Compose をインストールする
環境：
 DOCKER_COMPOSE_バージョン: 1.25.0-rc2
 シェル: |
 curl -L https://get.daocloud.io/docker/compose/releases/download/$DOCKER_COMPOSE_VERSION/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose
 chmod +x /usr/local/bin/docker-compose タグ:
 - cicd
 - docker_install

 - name : Docker Swarm をインストール
シェル：
 docker swarm init --advertise-addr { { groups [ 'pankuibo' ] [ 0 ] } }
 タグ:
 - cicd
 - docker_install

3. Docker環境をインストールします。Ansibleはスクリプトベースの構成で使用するため、以下のコマンドを実行してDockerをインストールします。

 ansible-playbook --inventory -file = './../inventory/inventory.ini' ./deploy.yml -e target = 'test' --tags = 'docker_remove,docker_install,docker_compose' --forks = 5 --user = 'root'

説明は次のとおりです。
1. 異なる操作を実行するために異なるタグが定義されています。
2. デプロイメントファイル、ホストファイル、ロールファイルが分離されているため、柔軟性と利便性が向上します。

Giteaのインストールと設定

インストール

Giteaは、Docker Hub組織内で自動的に更新されるDockerイメージを提供します。常に最新の安定ラベルを使用することも、他のサービスを使用してDockerイメージを更新することもできます。インストール用の設定ファイルは次のとおりです（docker-compose-gitea.yaml）。

 バージョン: "3.8"

 サービス:
 ギテア：
 画像: gitea/gitea : 1.16.5
 環境：
 - USER_UID=1000
 - USER_GID=1000
 - DB_TYPE=mysql
 - DB_HOST=ローカルホスト:3306
 - DB_NAME=gitea
 - DB_USER=gitea
 - SSH_PORT=2224
 巻数:
 - /data/gitea:/data
 - /etc/localtime:/etc/localtime:ro
 ポート:
 - 「3000:3000」
 - 「2224:2224」
 ネットワーク:
 - "デフォルト"
 展開する：
 モード:複製
レプリカ： 1
 ラベル:
 - "traefik.enable=true"
 - "traefik.docker.network=デフォルト"
 - "traefik.http.services.gitea_gitea.loadbalancer.server.port=3000"
 # http 80
 - "traefik.http.routers.gitea.rule=ホスト(`gitea.localhost.com`)"
 - "traefik.http.routers.gitea.entrypoints=web"
 配置
制約: [ node.role == manager ]
 再起動ポリシー:
 条件:失敗時
遅延： 5秒
最大試行回数: 3
 ウィンドウ： 120秒
ネットワーク:
 デフォルト：
 外部の：
 名前: traefik_default

データベースに依存するため、まずMySQLを環境にインストールする必要があります。MySQLのインストール設定ファイルは以下の通りです（docker-compose-mysql.yaml）。

 バージョン: "3.8"

 サービス:
 MySQL :
 画像: MySQL : 5.7.37
 環境：
 - MYSQL_ROOT_PASSWORD=パスワード
コマンド: --default-authentication-plugin=mysql_native_password
 巻数:
 - /data/mysql:/var/lib/mysql
 - /etc/localtime:/etc/localtime:ro
 ポート:
 - 「3306:3306」
 ネットワーク:
 - "デフォルト"
 展開する：
 モード:複製
レプリカ： 1
 配置
制約: [ node.role == manager ]
 再起動ポリシー:
 条件:失敗時
遅延： 5秒
最大試行回数: 3
 ウィンドウ： 120秒
ネットワーク:
 デフォルト：
 外部の：
 名前: traefik_default

基づいて
docker-compose を使用して Gitea を起動するには、`docker-compose up -d` を実行して Gitea をバックグラウンドで起動します。`docker-compose ps` を使用して、Gitea が正しく起動しているかどうかを確認します。`docker-compose logs` でログを確認できます。

giteaを停止するには、`docker-compose down`を実行してください。これによりコンテナが停止し、強制終了します。ボリュームは引き続き存在します。

このチュートリアルでは、以下のコマンドを使用してGiteaをインストールします。私たちの環境ではDocker Swarmクラスターを使用しているため、以下のコマンドでインストールできます。Docker Swarmの使用方法については、Docker Swarmのユーザーマニュアルを参照してください。

 1. docker スタックデプロイ -c docker-compose-mysql.yaml mysql
 2. docker スタックデプロイ -c docker-compose-gitea.yaml gitea

上記の設定では
Giteaはポート3000を使用するため、ローカルブラウザでlocalhost:3000にアクセスするとページにアクセスできます。ドメイン名とNginxまたは…を設定することをお勧めします。
Caddyリバースプロキシアクセス。この例で使用されているプロキシコンポーネントはTraefikプロキシです。Traefikの使用方法の詳細については、Traefikユーザーマニュアルを参照してください。

上記の設定手順について

データベース

Gitea を MySQL データベースで使用するには、上記で作成した docker-compose-gitea.yaml ファイルにこれらの変更を適用します。

 バージョン: "3.8"

 サービス:
 ギテア：
 画像: gitea/gitea : 1.16.5
 環境：
 + - DB_TYPE=mysql
 + - DB_HOST=ローカルホスト:3306
 + - DB_NAME=gitea
 + - DB_USER=gitea

環境変数

APP_NAME: 「Gitea: お茶を飲みながら Git」: ページタイトルで使用されるアプリケーション名。
RUN_MODE: prod: パフォーマンスとデバッグに影響するアプリケーションのランタイムモード。「dev」、「prod」、または「test」。
DOMAIN: localhost: Gitea UI に表示される HTTP クローン URL に使用されるこのサーバーのドメイン名。
SSH_DOMAIN: localhost: このサーバーのドメイン名。Gitea UI に表示される SSH クローン URL に使用されます。インストールページが有効になっている場合、SSH ドメインサーバーは次の形式の DOMAIN 値を使用します（この設定は保存時に上書きされます）。
SSH_PORT: 22: クローン URL に表示される SSH ポート。
SSH_LISTEN_PORT: %(SSH_PORT)s: 組み込み SSH サーバーのポート。
DISABLE_SSH: false: SSHが利用できない場合は無効にします。SSHを無効にするには、Giteaのインストール時にSSHポートを0に設定する必要があります。
HTTP_PORT: 3000: HTTP リスニングポート。
ROOT_URL: "": 自動生成されたパブリックURLを上書きします。これは、内部URLと外部URLが一致しない場合（例：Docker）に便利です。
LFS_START_SERVER: false: git-lfs サポートを有効にします。
DB_TYPE: sqlite3: 使用されているデータベースの種類 [mysql、postgres、mssql、sqlite3]。
DB_HOST: localhost:3306: データベースホストのアドレスとポート。
DB_NAME: gitea: データベース名。
DB_USER: root: データベースのユーザー名。
DB_PASSWD: "": データベースユーザーのパスワード。パスワードに特殊文字を使用する場合は、「Your Password」のように引用符で囲んでください。
INSTALL_LOCK: false: インストールページへのアクセスは禁止されます。
SECRET_KEY: "": グローバルキー。これは変更する必要があります。値が設定され、INSTALL_LOCK が空の場合、INSTALL_LOCK は自動的に true に設定されます。
DISABLE_REGISTRATION: false: 登録を無効にします。その後は管理者のみがユーザーアカウントを作成できます。
REQUIRE_SIGNIN_VIEW: false: このオプションを有効にすると、ユーザーはページを表示する際にログインする必要が生じます。
USER_UID: 1000: コンテナ内でGiteaを実行しているユーザーのUID（UnixユーザーID）。ホストボリュームを使用している場合は、/dataボリュームの所有者のUIDと一致している必要があります（名前付きボリュームの場合は不要です）。
USER_GID: 1000: コンテナ内でGiteaを実行しているユーザーのGID（UnixグループID）。ホストボリュームを使用している場合は、/dataボリュームの所有者のGIDと一致している必要があります（名前付きボリュームの場合は不要です）。

新しいOAuth2アプリケーションを作成する

Gitea OAuth2アプリケーションを作成し、「クライアントID」と「クライアントキー」を使用してGiteaリソースへのアクセスを認証します。リダイレクトURIの設定は、以下の例に示す形式とパスに従い、有効なものにする必要があります。

アプリケーション名 - Drone CI
リダイレクトURI - ドローンのログインURIを指します
クライアントID
クライアントキー

ドローンの設置と設定

新しい共有キーを作成する

ランナーとドローンサーバー間の通信を承認するための新しい共有キーを作成します。

共有キーは openssl コマンドを使用して生成できます。

 openssl rand -hex 16
 61379d57490fe37822267e7984acc934

画像をダウンロード

Drone Server は、自己完結型で外部依存関係のない軽量 Docker イメージとして配布されます。

 docker pull ドローン/ドローン

構成

Droneサーバーは環境変数を使用して設定されます。この記事では、以下に定義する設定オプションの一部を参照しています。設定オプションの完全なリストについては、「設定」を参照してください。

ドローンサーバーセクション

DRONE_GITEA_CLIENT_ID に必要な文字列値は、Gitea OAuth クライアント ID を提供します。
DRONE_GITEA_CLIENT_SECRET に必要な文字列値は、Gieta OAuth クライアントのパスワードを提供します。
DRONE_GITEA_SERVER に必要な文字列値は、Gitea サーバーのアドレスです。例: https://gitea.company.com。http(s) の使用にご注意ください。そうしないと、Gitea から「サポートされていないプロトコルスキーム」というエラーが表示されます。
`DRONE_RPC_SECRET` に必要な文字列値は、前のステップで生成された共有シークレットです。これは、サーバーとランナー間のRPC接続を検証するために使用されます。サーバーとランナーの両方に同じシークレット値を指定する必要があります。
DRONE_SERVER_HOST の必須文字列値は、外部ホスト名またはIPアドレスです。IPアドレスを使用する場合は、ポート番号を含めることができます。例：drone.company.com
`DRONE_SERVER_PROTO` の必須文字列値は、外部プロトコルスキームを指定します。この値は `http` または `https` のいずれかに設定する必要があります。SSL または ACME を設定している場合、このフィールドのデフォルトは `https` です。
ドローンデータベースデータソース

 DRONE_DATABASE_DATASOURCE=root:password@tcp(1.2.3.4:3306)/drone?parseTime=true

オプションの文字列値。データベース接続文字列を設定します。デフォルト値は、埋め込みSQLiteデータベースファイルへのパスです。

DRONE_DATABASE_DRIVER オプションの文字列値。データベースドライバ名を設定します。デフォルト値はsqlite3ドライバです。代替ドライバとしてpostgresとmysqlがあります。
`DRONE_GITEA_SKIP_VERIFY` ブール値は、リモート Gitea サーバーへの接続を確立する際に TLS 認証を無効にします。デフォルト値は false です。
DRONE_RUNNER_CAPACITY （オプションの数値）。ランナーが同時実行できるパイプラインの数を制限します。これは、単一のリモートインスタンスで同時実行できるパイプラインの数を制限するものではありません。
ドローンユーザー作成

 $ openssl rand -hex 16
 55f24eb3d61ef6ac5e83d550178638dc
 DRONE_USER_CREATE=ユーザー名:octocat、マシン:false、管理者:true、トークン:55f24eb3d61ef6ac5e83d550178638dc

起動時に作成されるオプションのユーザーアカウント。管理者アカウントを使用してシステムをシードするために使用します。実アカウント（つまり、実際のGitHubユーザー）またはマシンアカウントを使用できます。

DRONE_USER_FILTER カンマ区切りのアカウントリスト（オプション）。登録は、このリストに登録されているユーザー、またはここにリストされている組織のメンバーであるユーザーに限定されます。

ドローンランナー部門

DRONE_RPC_HOST は、ドローンサーバーのネットワークアドレス（ポート番号を含む場合があります）を提供します。ドローンランナーは、このアドレスに基づいてドローンサーバーに接続し、サーバーからパイプラインタスクを受信します。
DRONE_RPC_SECRET は、前のステップで生成された共有キーを提供します。これは、サーバーとランナー間のRPC接続を検証するために使用されます。サーバーとランナーの両方に同じシークレット値を提供する必要があります。
DRONE_RPC_PROTOにはhttpまたはhttpsのいずれかを入力します。これは、Drone ServerにアクセスするアドレスがHTTPSを使用しているかどうかによって異なります。
DRONE_RUNNER_CAPACITY は、一度に実行できるジョブの数を指定します。0 にすることはできません。
DRONE_RUNNER_NAME オプションの文字列値。ランナーの名前を設定します。ランナー名はサーバーに保存され、ビルドを特定のランナーまで遡って追跡するために使用できます。
DRONE_RUNNER_LABELS オプションの文字列マッピング。パイプラインを特定のマシンまたはマシンのグループにルーティングするためのラベルのセットを提供します。
DRONE_LOGS_DEBUG はデバッグログを有効にします。この設定パラメータはブール値であり、オプションです。
DRONE_LOGS_PRETTY は、デフォルトの JSON 形式の代わりにログ出力を有効にします。この設定パラメータはブール値であり、オプションです。
DRONE_LOGS_NOCOLOR はログの色分けを有効にします。これは、より見やすいログ出力を生成するために使用します。この設定パラメータはブール値であり、オプションです。

ドローンサーバーとドローンランナーをインストールする

ドローンランナーの説明

Drone サービスが起動したら、ランナーをインストールしてビルドパイプラインを実行できます。

ドローンランナーは、実行するジョブを見つけるためにサーバーをポーリングします。ここでは、様々なユーザーシナリオとランタイム環境に合わせて最適化された複数のランナーが用意されています。状況に応じて、1つまたは複数、あるいは複数をインストールできます。

 1. Dockerランナー
2. Kubernetesランナー
3. エグゼクティブランナー
4. SSHランナー
5. デジタルオーシャンランナー
6. マクスタジアムランナー

Dockerランナーは、短命コンテナ内でタスクのパイプラインを実行するデーモンです。単一のDockerランナーをインストールすることも、複数のマシンにインストールしてビルドクラスターを作成することもできます。

Docker ランナーは、ステートレスコンテナーでテストを実行し、コードをコンパイルできるプロジェクト向けに最適化された汎用ランナーです。

Docker ランナーは、macOS など Docker でサポートされていないオペレーティングシステムやアーキテクチャを対象とするプロジェクトなど、コンテナー内でテストを実行したりコードをコンパイルしたりできないプロジェクトには適していません。

ドローンサーバーとドローンランナーを起動する

インストール用の構成ファイルは次のとおりです (docker-compose-drone.yaml)。

 バージョン: "3.8"

 サービス:
 ドローン：
 イメージ: drone/drone : 2.0.0 #最新版は安定したバージョンではないので、最新版は使用しないでください。
 ポート:
 - 「7000:80」
 ネットワーク
- 「ドローン」
 巻数:
  - /data/drone/:/var/lib/drone/:rw
 - /var/run/docker.sock:/var/run/docker.sock:rw
 環境：
 #- "DB_PASSWD_FILE=/run/secrets/db_passwd"
 - DRONE_DEBUG=true
 - DRONE_DATABASE_DATASOURCE=drone:123456@tcp(localhost:3306)/drone?parseTime=true #MySQL 構成。上記の MySQL コンテナ内の構成と一致している必要があります。
 -DRONE_DATABASE_DRIVER =mysql
 - DRONE_GITEA_SKIP_VERIFY=偽
-DRONE_GITEA_CLIENT_ID =xxxxxx
 -DRONE_GITEA_CLIENT_SECRET =xxxxxx
 - DRONE_GITEA_SERVER=http://localhost:3000/
 - DRONE_TLS_AUTOCERT=偽
-ドローンランナー容量=2
 - DRONE_RPC_SECRET=48f11fe546a25099cde4a05ce35a4815 #RPCキー
- DRONE_SERVER_PROTO=http # この構成は、リポジトリ内の webhook をアクティブ化するときにその proto アドレスを決定します。
 - DRONE_SERVER_HOST = ローカルホスト:7000
 - DRONE_USER_CREATE=username:root,admin:true #管理者アカウント。管理者になる Gita ユーザー名です。
 - DRONE_USER_FILTER=ルート
- DRONE_DATADOG_ENABLE=偽
展開する：
 モード:複製
レプリカ： 1
 配置
制約: [ node.role == manager ]
 再起動ポリシー:
 条件:失敗時
遅延： 5秒
最大試行回数: 3
 ウィンドウ： 120秒
ドローンランナー:
 イメージ: drone/drone-runner-docker : 1.6.3
 ネットワーク
- 「ドローン」
 依存:
 -ドローン
巻数:
 - /var/run/docker.sock:/var/run/docker.sock:rw
 環境：
 - DRONE_RPC_HOST=localhost:7000
 -ドローン_RPC_SECRET=48f11fe546a25099cde4a05ce35a4815
 - DRONE_RPC_PROTO=http
 -ドローンランナー容量=4
 - DRONE_RUNNER_NAME=ランナー
- DRONE_RUNNER_LABELS=マシン1:ランナー1
 - DRONE_DEBUG=true
 - DRONE_LOGS_DEBUG=true
 - DRONE_LOGS_PRETTY=true
 - DRONE_LOGS_NOCOLOR=偽
展開する：
 モード:複製
レプリカ： 1
 配置
制約: [ node.role == manager ]
 再起動ポリシー:
 条件:失敗時
遅延： 5秒
最大試行回数: 3
 ウィンドウ： 120秒
ネットワーク:
 ドローン：
 外部: true
 名前: traefik_default

docker-compose を使用してサービスを開始する場合は、`docker-compose-drone.yaml` を含むディレクトリでdocker-compose up -dと入力するだけです。この例では、以下のコマンドで Drone サービスを起動します。コンテナは環境変数で設定されます。詳細な設定パラメータについては、設定リファレンス (https://docs.drone.io/server/reference) を参照してください。

 docker スタックデプロイ -c docker-compose-drone.yaml ドローン

上記の設定では、サーバーのポート番号は7000です。そのため、ローカルブラウザでlocalhost:7000にアクセスすると管理ページにアクセスできます。アクセスにはドメイン名とNginxまたはAddyのリバースプロキシを設定することをお勧めします。この例で使用しているプロキシコンポーネントはTraefik proxyです。Traefikの使用方法の詳細については、Traefikユーザーマニュアルを参照してください。DroneのログインアカウントはデフォルトでGiteaアカウントに紐付けられているため、GiteaにログインしていればDroneも自動的にログインします。

Droneを開いてログインすると、リポジトリは空になっているはずです。これは、GietaのコードリポジトリがDrone CIに同期されていないためです。ホームページの右上にある「SYNC」ボタンをクリックするだけで、Droneは自動的にGietaとの同期を開始します。
コードリポジトリ。同期後、リポジトリを有効化する必要があります。設定後、対応するプライベートリポジトリにWebhookビルドフックが自動的に作成されます。

Steps がホストマシンからフォルダをマウントする必要がある場合、対応する Drone プロジェクトのプロジェクト設定で「信頼済み」にチェックを入れてください。これは、コンテナがホストマシンからフォルダをマウントするための特権モードを有効にすることを意味します。この設定を有効にするユーザーは管理者権限を持っている必要があります。他のユーザーには有効にする権限がありません。

Drone CI 自動デプロイメントインスタンス

プロジェクトコードのルートディレクトリに.drone.ymlファイルを作成します。コードがコードリポジトリ（github、gitlab、giteaなど）にアップロードされると、gitリポジトリは事前に埋め込まれたwebhootを介してDroneにイベントリクエストを送信します。イベントリクエストを受信すると、Droneはリポジトリプロジェクトのルートディレクトリにある.drone.ymlファイルを検索し、解析して、ファイル内の記述に従ってタスクを実行します。

Drone CI の各ステップでは、イメージに基づいて Docker コンテナが構築され、コンテナ内で指定されたタスクが実行されます。

まず、すべてのパイプラインにあるヘッダー説明セクションがあります。

 kind: pipeline # パイプラインのタイプ。他には secret や signature などがあります。
 type: docker # 実行するタスクのタイプを定義します。ここでは Docker が使用されます。
 name: web # パイプラインの名前を定義します。.drone.yml ファイルには、異なる名前を持つ複数のパイプラインを含めることができます。

次に、タスクの各ステップの説明を示します。steps 属性は、このステップの名前とイメージを記述します。各ステップではイメージを使用します。タスクの実行中は、指定されたイメージ名に従ってイメージがプルされ、タスクの指示を実行するための一時的なDockerコンテナが生成されます。コンテナはステップの完了後に自動的に削除されます。

手順:
 - name: build-imaeg # ステップ名
image: docker # これらの手順に必要なイメージ

以下は、Vue フロントエンドアプリケーションを Docker イメージにパッケージ化し、サーバーにデプロイする例です。この記事で紹介する例は、よくある落とし穴を主に網羅することを目的としており、初心者にとっては非常に複雑かもしれません。もし理解できなくても大丈夫です。このセクションを飛ばして、Drone CI を自分でインストールしてみてから、戻って詳細を学習してください。

.drone.yml ファイル

 種類:パイプライン
type : docker # Docker Runnerで実行
名前:ウェブ

# セットアップを定義します。各セットアップには独自の名前があり、最終的にはDrone CI管理ページのサイドバーに表示されます。
 手順:
 - name : restore-cache # 以前にキャッシュされたデータを取得する
画像: drillster/drone-volume-cache
 設定：
 復元: true
 マウント: # キャッシュマウントフォルダ
- ./.npm-cache
 - ./node_modules
 巻数:
 - 名前:キャッシュ
パス: /cache

 - 名前:コンパイル#コンパイル
画像:ノード: 12
 コマンド:
 - yarn config レジストリを設定します https://registry.npm.taobao.org -g
 - yarn config でキャッシュを設定します ./.npm-cache --global
 -糸のインストール
-ヤーンランビルド

- name :ビルドイメージ#Dockerイメージにビルドする
画像: docker
 失敗:無視
巻数:
 - 名前：靴下
パス: /var/run/docker.sock
 コマンド:
 - docker build -t localhost:v1.0 -f Dockerfile 。
 - docker image prune -f --filter "dangling=true" # 未使用のイメージをクリーンアップする

- name : rebuild-cache # キャッシュ内の依存関係と npm サービスをキャッシュします
画像: drillster/drone-volume-cache
 設定：
 再構築: true
 マウント:
 - ./.npm-cache
 - ./node_modules
 巻数:
 - 名前:キャッシュ
パス: /cache

 - name : deploy # サーバーにデプロイする
画像: docker
 失敗:無視
巻数:
 - 名前：靴下
パス: /var/run/docker.sock
 コマンド:
 - docker service ls|grep test || export SERVICE=down # 最初にサービスが存在するかどうかを確認します。存在する場合は更新し、存在しない場合は作成します。
 - |
 if [ "$SERVICE" != "ダウン" ]
それから
docker サービスアップデート --image test:v1.0 test_test
それ以外
docker スタックデプロイ -c deploy.yaml autocd-web
 fi # ループ検出サービスが正常に開始されたかどうかを確認します
- |
真実である
する
docker service ps test_test|awk '{print $6}' |awk 'NR==2' |grep '実行中' || export SERVICE=down
 if [ "$SERVICE" == "ダウン" ]
それから
echo -e "\033[5;35;40m 起動中です。お待ちください... \033[0m"
エクスポート SERVICE=up
続く
それ以外
docker サービスログ -n 200 test_test
睡眠3
壊す
フィ
終わり
# ホストマシンのファイルをDockerコンテナにマウントする
巻数:
 - 名前：靴下
ホスト：
 パス: /var/run/docker.sock
 - 名前:キャッシュ
ホスト：
 パス: /tmp/cache

 # トリガーを作成し、それをブランチとイベントにバインドして、最後の成功した実行時にのみ実行されるように設定します。
 トリガー:
 支店：
 -マスター
イベント：
 -プルリクエスト
-押す
状態：
 -成功
-失敗

ノード:
マシン1:ランナー1

Dockerファイル

 # ベースイメージを設定します。ローカルにイメージが存在しない場合は、Docker.io サーバーから取得されます。
 # これにより、ホスト マシンのキーが直接使用され、プライベート リポジトリにログインします。
 nginx:1.19.2-alpine から

# プロジェクトをコンパイルし、npm を使用してすべての依存関係をインストールし、Taobao の npm インストール サービスを活用し、静的ファイルにパッケージ化してコンパイルします。
 # これらの2つのステップはドローンですでに完了しています
# すべての静的ファイルを /usr/share/nginx/html にコピーします。
 # 設定ファイルをnginxの設定ディレクトリにコピーします
dist/ /usr/share/nginx/html/ をコピーする
nginx.conf を追加します/etc/nginx/nginx.conf
 default.conf を /etc/nginx/conf.d/default.conf に追加します。


 # コンテナのポートを公開する
エクスポーズ80

 # コマンドを実行
CMD [ "nginx" 、 "-g" 、 "デーモンオフ;" ]

組立ラインの説明

上記の例には 5 つのステップがあります。

キャッシュを復元する
コンパイル
ビルドイメージ
キャッシュの再構築
展開する

各ステップの簡単な概要は次のとおりです (詳細な説明は上記のコメントに記載されています)。

1. clone: プライベートリポジトリのコードを複製します（デフォルトで自動的に追加されます）。

2. restore-cache ステップでは、以前にキャッシュされたファイルをホストマシンから取得します。

3. コンパイル手順中に、yarn または npm はすでにインストールされている依存関係をスキップできます。

4. ビルドステップでは、リポジトリ内のDockerfileに基づいてローカルイメージパッケージをビルドします。Dockerプライベートイメージリポジトリにプッシュする必要がないため、plugins/dockerプラグインは使用されません。

5. 再構築キャッシュ手順では、マウントファイルを介してキャッシュをホストマシンに配置します。

6. デプロイステップは、アプリケーションをコンテナーにデプロイするために使用されます。

最適化

各ビルドはステップごとに新しいコンテナを作成し、そのコンテナ内でビルドを実行するため、サンドボックス環境にはキャッシュデータが存在しません。`restore-cache` および `rebuild-cache` ステップは、ホストマシンとコンテナの間にキャッシュを確立します。Vue の依存関係 `node_modules` ディレクトリと YARN キャッシュをボリューム経由でホストマシンにマッピングすることで、YARN は次回のビルドおよび依存関係のインストール時に変更されていない依存関係パッケージを自動的にスキップし、ビルドプロセスを高速化します。

実際には、Drone CIはデフォルトですべてのセットアップの最初にコードクローンのセットアップ（clone）を追加します。イントラネットフェッチに独自に構築したGiteaサービスを使用すると、ビルドプロセスを大幅に高速化できます。事前定義されたセットアップは、コードクローンの完了後にのみ実行を開始します。途中でエラーが発生した場合、パイプライン全体がエラーメッセージとともに終了します。
組立ラインのプロセス。

マルチノード操作

docker-compose-drone.yaml ファイルでランナーの DRONE_RUNNER_LABELS 環境変数を定義すると、ランナーにタグが追加されます。.drone.yml ファイルでこのタグを定義すると、パイプラインはタスクを異なるランナーにルーティングできるようになります。

例えば、異なる場所に配置された2台のマシンがあり、それぞれのマシンでランナーを実行し、DRONE_RUNNER_LABELS環境変数を使用して2台のランナーのタグを定義しているとします。例えば、1台目のランナーでは DRONE_RUNNER_LABELS=nodeA:runnerA 、もう1台では DRONE_RUNNER_LABELS=nodeB:runnerB と定義します。そして、.drone.yml ファイルで以下のように定義します。

 種類:パイプライン
タイプ: docker
 名前:デフォルト

手順:
 - 名前:ビルド
画像: Golang
 コマンド:
 -ビルドする
-テストに行く

ノード:
 ノードA :ランナーA

このタスクは、タグ nodeA:runnerA を持つランナーでのみ実行されます。

両方のノードで実行する場合は、両方のタグを追加できます。例:

ノード：
ノードA: ランナーA
ノードB: ランナーB

ランナーはハートビートを介してサーバーにアクティブに接続し、サーバー上に自身を登録するため、固定ネットワークアドレスを必要とせず、軽量であるため、このランナーノードは PC、ラップトップ、さらには Raspberry Pi でも使用できます。

DUICUO