♋️ 🕰️ 🕵🏾 Drone CI、Docker、Ansibleとの継続的な統合 👩🏾‍🤝‍👩🏻 👶 🈁

継続的インテグレーションサーバーに依存関係をインストールして手動で構成する必要がもう二度とないことを想像できますか？ビルドのすべてのステップを真に分離し、Dockerコンテナーでのみ動作させることができると思いますか？結局のところ、Golangで書かれたすべてのオープンソースプロジェクトのトップ20にあり、Githubに9k以上のスターを付けたツールを試してみませんか？

この記事では、継続的インテグレーションの簡素化と改善にすでに役立っている優れたドローンCIについてお話したいと思います。ドローンCIインストールの詳細を共有し、小規模プロジェクトの例で使用のすべての詳細を示します。あまり読みたくないのですぐに試してみたい場合は、記事の最後に、クイックスタートに役立つGithubリポジトリへのリンクがあります。

メイントピックに移る前に、 docker -composeに関する記事の多数の良いレビューと、もちろん、この記事が存在しないドローンCIの著者であるBrad Rydzewskiに感謝します。これは私たちがさらに書くための大きな動機です！

ちょっとした歴史

「継続的インテグレーション」（CI）という用語にすでに精通しており、さらに詳しく知りたい場合は、 Martin Fowlerによるすばらしい記事から始めてください。継続的インテグレーションは、問題を特定し、アプリケーション展開プロセスを完全に自動化すると同時に、チーム全体の時間を大幅に節約できるという点で、私たちにとって長い間馴染みのあるものになりました。

私は7年間CIサーバーを使用してきましたが、私たちの多くがそうであるように、 Jenkinsを始め、後にTeamCityを始め、 Travis CIに夢中になりました。これらの各製品は、継続的な統合プラクティスを開発するために多くのことを行ってきました。ツールを時々変更するアイデアの1つは、プロセスを完全に自動化する機能です。 JenkinsとTeamCityには非常に開発されたユーザーインターフェイスがあり、任意のプロジェクトの継続的な統合を構成できますが、自動化するのは非常に困難です。 Travisは非常に優れたツールであり、 「オープンソースプロジェクトのテストは10000％無料」であるため、私のすべてのオープンソースの取り組みにおいて依然としてナンバーワンの選択肢です。 Travisは、単一の.travis.yml

ファイルとの継続的な統合を可能にする最初のツールでした。

コードとしてのパイプライン

「コードとしてのパイプライン」は、実行中のCIサービスを手動で構成する代わりに、コードを使用して「展開パイプライン」を構成できる比較的新しいアプローチです。今日、この概念は非常に人気があり、このセグメントでは少なくとも5人のプレーヤー、つまりLambdaCD 、 Concourse 、 Drone 、 GoCD 、 Travis CIを知っています。このアプローチにより、継続的な統合と継続的な展開の自動化が容易になるだけでなく、展開のためのインフラストラクチャをテストすることもできます。この概念により、私たちは世界を異なって見るようになりましたが、最も重要なことは、CIをより効率的かつエレガントに使用できることです。

継続的に統合する方法

現在、6人がチームで働いており、継続的な統合と展開に対するアプローチは非常に簡単です。 Github、プルリクエスト、コードレビューを積極的に使用しています。 継続的デリバリの詳細については、Jez HumbleとDavid Farleyによる継続的デリバリ：ビルド、テスト、展開の自動化による信頼性の高いソフトウェアリリースをご覧ください。

継続的な統合と継続的な展開の主な手順：

各チームメンバーは別々のブランチで作業し、タスクが完了するとすぐにプルリクエストを作成します。
プルリクエストの各コミットは、CIサーバーによってチェックされます。ユニット、統合、UIテスト、リンティングが開始されます。起動ステータスはGithubに表示されます。
各プルリクエストは、2人のチームメンバーが閲覧する必要があります。それらの1つは、コードをローカルで実行し、ユーザーインターフェイスのすべての変更をチェックします。テストの開始に成功し、レビューに合格すると、コードがメインブランチ（マスター）にマージされ、運用前環境への自動展開プロセスが開始されます。
展開は2つのステップで構成されます。まず、すべてのDockerコンテナをDockerHubで公開し、次にサーバーにアプリケーションを展開する小さなAnsibleスクリプトを実行します。
少しの手動テストの後、すべての変更が「実稼働」ブランチにアップロードされ、「実稼働」環境で自動展開のプロセスがすでに開始されます。

このプロセスにはいくつかの欠点があり、チームが大きくなると変更が必要になります。しかし、今日、それは私たちに完全に合っており、私たちの意見では、10人までの小さなチームに理想的です。主な欠点は次のとおりです。

多数のテストにもかかわらず、マスターに陥るいくつかの変更には欠陥が含まれています。これにより、欠陥が修正されるまで、他のプル要求の展開がブロックされます。
マスターブランチが「プロダクションレディ」状態にない場合、プロセスから逸脱し、クライアントが「プロダクション」ブランチで直接抱えている問題を修正する必要があります。これにより、これらの変更をマスターブランチに戻す必要があります。
何かがうまくいかなかった場合、ロールバックの変更プロセスを完全に解決していません。これは、ブランチの「プロダクション」を展開前の状態にロールバックすることで構成されています。データベースへの変更が必要な場合、この段階でそれらを手動で実行します。

チームが成長するにつれて、これらの欠点に対処します。今日、私たちはすでに1日に数回プロジェクトをほぼ無痛で展開できます。 Githubのようなアプリケーションはまだデプロイしていませんが、最初のステップはすでに実行されています:)

ドローンci

さまざまなツールを比較した後、私たちの選択はドローンCIで決まり、過去3か月で完全に切り替えました。ドローンCIには、Githubに9003個の星があります（2017年3月15日）。ドローンCIは、GithubのGoで作成された上位20のアプリケーションに含まれています。 Gitter のチャンネルは決して眠りません-そこにある質問に対する答えを得ることができます。

設置

ドローンCIは、単一の8メガバイト Dockerコンテナーです。このコンテナには2つのサービスが含まれます。

ドローンUIは、エージェントを調整し、ビルドステータスを表示するシンプルなユーザーインターフェイスおよびサーバーです。
ドローンエージェントは、プロジェクトのアセンブリを開始する別のサービスです。

過去および現在のビルドに関するすべてのデータはデータベースに保存されます。 Sqliteはデフォルトで使用されますが、PostgreSQLやMySQLなどの他のリレーショナルデータベースを使用することもできます。この記事のために、 Githubリポジトリを用意しました。これは、数分でDrone CIをローカル環境または実稼働環境にインストールするのに役立ちます。

はじめに

まず、ドローンCIの原理を簡単に紹介したいと思います。 Githubアカウントを使用してDrone CIをインストールしてログインすると、Droneはすべてのリポジトリを自動的に表示します。最初のステップは、継続的インテグレーションを設定するリポジトリを有効にすることです：

ユーザーインターフェイスの操作はほぼ終わりました。さらに、ビルドのステータスを確認するためにのみ必要です。

展開手順のすべての設定は、1つのファイルdrone.yml

で実行されます。このファイルは通常、リポジトリのルートにあり、CIサーバーで発生するすべてを完全に記述します。本質的に、 .drone.yml

は任意のステップのセットであり、各ステップは個別の分離されたDockerコンテナで実行されます。各コミットで、 .drone.yml

からステップを実行する前に、Droneはリポジトリを自動的に複製し、各ステップのDockerボリュームとして追加します。

より明確にするために、テストを実行し、Dockerイメージを収集し、Dockerhubに公開し、ビルドが完了したらSlackに簡単な通知を送信する簡単な構成を見てみましょう。

 pipeline: run-tests: image: node:6.3.0 commands: - cd ./api && npm i --quiet - npm test publish-api-docker: image: plugins/docker:1.12 username: ${DOCKER_USERNAME} password: ${DOCKER_PASSWORD} email: ${DOCKER_EMAIL} repo: anorsich/ds-api tags: - latest dockerfile: ./api/Dockerfile context: ./api/ slack-notification: image: plugins/slack webhook: https://hooks.slack.com/services/... username: drone-ci channel: andrew icon_emoji: ":rocket:"

以上です！これで、リポジトリへの各コミットで、テストを実行し、コンテナを収集し、Slackで通知を受け取ります。

サードパーティの依存関係とアセンブリ手順の分離

Droneの各ステップは個別のDockerコンテナーで実行されるため、サーバーエージェントへの依存関係のインストールや更新について心配する必要はありません。重要な違いは、各ステップの依存関係が完全に異なる場合があることです。 1つのステップでNode.JSのテストを実行し、次のステップでGoで記述されたアプリケーションの作成を静かに開始できます。プラットフォームの新しいバージョンへの移行は、コンテナのバージョンを変更するだけで実行されます。たとえば、テストを実行し、Node.JSの最新バージョンでプロジェクトをビルドする新しいステップを簡単に追加できます。

  run-tests-on-latest-node: image: node:7.7 commands: - cd ./api && npm i --quiet - npm test

実際、CIサーバーを構成する必要があるのは1つの場合のみです-CIサーバー自体の新しいバージョンがリリースされた場合。他のすべては、シングルクリックなしで、 .drone.yml

のリポジトリで直接設定されます。インストール済み-忘れてしまった:)

各ステップは別のコンテナで実行されるため、他のステップから完全に分離されていることに注意することが重要です。バージョンの競合はもうありません！

まだ使用していないが、言及したい別の可能性は、マトリックスアセンブリのサポートです。これにより、プラットフォーム、データベースなどのさまざまなバージョンでコードをすぐにテストできます。

条件によるトリガー

特定の条件下でのみビルドのステップを実行する必要がある場合があります。デフォルトでは、すべてのステップが順番に開始され、ステップの1つが中断しても、後続のステップは開始されません。使用する主な制限は次のとおりです。

ブランチ名（マスター、プロダクション）
ビルドステータス（成功、失敗）
Githubイベント（pull_request、push、tag、deployment）

たとえば、ビルドが成功したときと壊れたときに、Slackに通知を送信します。これを行うには、 when

セクションを使用してstatus

を追加しstatus

。

  slack-notification: image: plugins/slack ... when: status: [ success, failure ] event: [ push, tag, deployment, pull_request ]

制限について詳しくは、こちらをご覧ください。

言及する価値のある別の興味深い機能は、メッセージにコミットを追加することでビルドを実行しない機能です： [ci skip]

。

プラグイン

プラグインは、Amazon S3、Dockerhub、Slackなどのサードパーティサービスと統合するためのDrone CIアプローチです。すべてのプラグインの完全なリストはここにあります。各プラグインは、事前定義されたタスクを実行する個別のDockerコンテナーです。上記の例では、2つのプラグインを使用しました。

Dockerプラグイン（ plugins/docker

docker）-DockerhubでDockerイメージを構築および公開するため。
Slackプラグイン（ plugins/slack

）-Slackに通知を送信します。

これまでのところ、プラグインはすべてではありませんがほとんどの典型的なタスクを解決します。プロジェクト固有のタスクを開始するには、このタスクをDockerイメージでラップするだけで済みます。DroneCIで使用を開始できます。 Dockerで実行できるプログラミング言語はすべて利用可能です。 Droneを使用して、特別な手順の継続的な統合を再度調整できます。

コンソールユーティリティ

コンソールユーティリティDroneを使用すると、リモートサーバーと通信し、さまざまな管理タスクを実行できます。インストール後、リモートサーバーに接続する必要があります。これを行うには、ターミナルで2つの変数をエクスポートする必要があります。

export DRONE_SERVER=http://MY_DRONE_URL

ドローンサーバーのURL。
export DRONE_TOKEN=

-ドローンUIにログインした後に作成される個人トークン。次のページで見つけることができます： https://MY_DRONE_URL/account

SHOW TOKEN

を押してコピーします。

コンソールユーティリティを設定する必要があります。

秘密

ドローンには、パスワードやsshキー（つまり、秘密）などの個人情報を安全に扱うための非常に便利なツールがあります。上記の例では、Dockerプラグインを使用してDockerイメージをDockerhubに公開していますが、これにはパスワードとユーザー名が必要です。

Droneを使用したNode.JSアプリケーションの継続的統合の例があるGithubリポジトリでは、 Ansibleも使用します。これを使用して、リモートサーバーでDockerコンテナを実行します。リモートサーバーと通信するには、別のキーが必要です。ご存知のように、Githubリポジトリに秘密情報を保持することは、アプリケーションを危険にさらすためにハッカーが使用できる悪い習慣と見なされます。ドローンCIはこの問題を解決します。

始めるために、Dockerhubのパスワードとユーザー名を追加する方法を考えてみましょう（ plugins/docker

dockerで使用）：

 drone global secret add DOCKER_USERNAME andrew drone global secret add DOCKER_PASSWORD password drone global secret add DOCKER_EMAIL email

global

を使用して、特定のリポジトリにのみ、またはDrone CI内のすべてのリポジトリにシークレットを追加できます。特定のリポジトリのみにシークレットを追加する場合は、その名前を指定し、 global

使用する必要はありません：

 drone secret add maqpie/drone-starter DOCKER_USERNAME andrew

秘密が追加されると、単純な構文${DOCKER_USERNAME}

で.drone.yml

直接使用できます。以下に小さな例を示します。

 publish-api-docker: image: plugins/docker:1.12 username: ${DOCKER_USERNAME} password: ${DOCKER_PASSWORD} email: ${DOCKER_EMAIL}

前に述べたように、リモートサーバーを操作するにはsshキーも必要です。キーは次のように追加できます。

 drone global secret add SSH_KEY @/Users/andrew/.ssh/id_rsa-drone-demo

秘密の保護と署名

あなたの秘密を守るために、ドローンは.drone.yml

シンプルな署名メカニズムを使用します。 .drone.yml

を変更する.drone.yml

、再署名する必要があります。ドローンはビルドを実行する前に毎回署名をチェックします。署名が一致しない場合、シークレットは公開されず、利用できません。

署名には、ドローンコンソールユーティリティのセットアップ時に追加した個人認証キーが使用されます。

 drone sign maqpie/drone-starter

署名するときは、 .drone.yml

が配置されているリポジトリの名前を指定する必要があります。このコマンドの結果、 .drone.yml.sig

ファイルが表示され、リポジトリにコミットされます。

重要：リポジトリの.drone.yml

に署名する前に、このリポジトリがDrone UIに含まれていることを確認してください-それ以外の場合、署名ファイルは作成されません。

Droneには優れた秘密保護メカニズムがありますが、ハッカーにはまだアクセスできるいくつかのオプションがあります。たとえば、いずれかの手順でbashスクリプトを使用すると、ハッカーはcurl

または別のツールを使用してパスワードまたはsshキーにアクセスできます。常に一般的な安全原則を適用してください。

サービス

Drone UIのサービスを使用すると、ビルドプロセスの実行中に任意のコンテナーを起動できます。すべてのサービスは、プロセスビルドコンテナと同じサブネット上にあります。この機能は、さまざまなタイプの統合テストに非常に役立ちます。通常、サービスは.drone.yml

の最後で宣言されます。 MySQLデータベースを起動する例は次のとおりです。

 services: database: image: mysql environment: - MYSQL_DATABASE=test - MYSQL_ALLOW_EMPTY_PASSWORD=yes

現在の段階では、サービスを使用せず、代わりにdocker-composeを使用したより単純なアプローチを使用します。

docker-composeを使用してテストを実行する

前の記事で、 docker-composeに対する愛を共有しました。ドローンCIでのテストの実行方法について少し説明します。 .drone.yml

のステップは次のようになります。

  run-tests-in-compose: image: michalpodeszwa/docker-compose:latest volumes: - /var/run/docker.sock:/var/run/docker.sock commands: - ./bin/drone-run-tests.sh api-tests - ./bin/drone-run-tests.sh web-tests when: event: [pull_request]

/bin/drone-run-tests.sh

は、 /bin/drone-run-tests.sh

-composeの小さなラッパーでテストを実行します。私たちのアプローチを掘り下げる前に、私たちが行った妥協についてお話したいと思います。まず、この行のコンテナを隔離することを拒否しました。

 volumes: - /var/run/docker.sock:/var/run/docker.sock

要するに、この行は実際にこのコンテナがdockerサービスが実行できるコマンドを実行できるようにします。これにより、dockerサービスはユーザーroot

として実行されるため、ホストで任意のコマンドを実行できます。この記事のすべての結果に慣れることができます。この方法は、共有リポジトリには明らかに適していません。

なぜこのようなリスクを冒したのですか？いくつかの理由があります。

1つのチームを扱うクローズドプロジェクトがあります。
ドローンCIは別のサーバーで実行されており、誰かが分離の欠如を利用してそれを破ろうとしても、何も失うことはありません。 DNSアップデートを考慮して、新しいDrone CIをアップグレードするのに5分もかかりません。
主な理由は、Dockerキャッシュを効率的に使用したかったからです。毎日約20〜100件のリポジトリへのコミットを行い、それぞれがテストを実行します。 Dockerキャッシュを使用していなかった場合、コンテナはコミットするたびに再構築されますが、これには多くの時間がかかります。

このアプローチの欠点について理解できたので、アプローチ自体を分析しましょう。基本的に、テストを実行するには、単にdocker-compose up --file docker-compose.drone-tests.yml

ます。同様に、テストは作業環境で実行されます。 docker-composeを介してテストを実行するときに実行した唯一の問題は、docker-composeの終了コードが常に0であったことです。ステップ。この状況を修正するために、テストの実行後にコンテナの終了コードを分析する小さなスクリプトを作成し、少なくとも1つのコンテナがゼロ以外のコードで終了した場合、このコードを使用して終了します。上記のテスト実行ステップで見た/bin/drone-run-tests.sh

スクリプトの内容は次のようになります。

 #!/bin/sh # remove old containers docker-compose --file docker-compose.drone-tests.yml rm -f # run tests docker-compose --file docker-compose.drone-tests.yml up --build echo "Inspecting exited containers:" docker-compose --file docker-compose.drone-tests.yml ps docker-compose --file docker-compose.drone-tests.yml ps -q | xargs docker inspect -f '{{ .State.ExitCode }}' | while read code; do if [ "$code" != "0" ]; then exit $code fi done

リンクとヒント

他のツールと同様に、ドローンCIには開発中のものがいくつかあり、常に希望どおりに動作するとは限りません。幸いなことに、いくつかしかありませんでした。

ビルドプロセスで表示される情報が多すぎると、ドローンUIがフリーズします。 Node.JSのすべてのDockerファイルでは、 npm install

実行npm install

ときに--quiet

を追加する必要がありました-無駄な情報が出力されていました。 npmでこのオプションがデフォルトで使用されない理由はよくわかりません。
Drone 0.4と0.5の2つのバージョンがあります。後者は現在活発に開発されていますが、十分に安定しています（2か月で問題はありませんでした）。さまざまな回答を検索するときに、関連性がなくなった古い回答が見つかることがよくありました。
バージョン0.5のドキュメントは、次のアドレスにあります： http : //readme.drone.io/0.5/ 。ドキュメンテーションは、おそらく現時点でドローンの最も弱い側面です。私からは、Webpackドキュメントの最初のバージョン（以下のコメントを読んでください）も最高ではなかったと言えますが、これはほとんどのWebプロジェクトの標準になることを妨げませんでした。

ドローンを試すように説得できた場合、以下に役立つリンクのリストがあります。

ドローンGitHub
ドローンプラグインgithub
Drone 0.5ドキュメント
ドローンのギター
Drone 0.4ドキュメント -このドキュメントの一部は、まだバージョン0.5に完全に移植されていません。

おわりに

ドローンCIは、継続的な統合の問題に対する最新のソリューションです。 Droneを使用すると、サーバーを二度と設定することなく、ビルドを起動するための完全に隔離された環境を取得し、CIサーバーを無限に拡張できます。 2か月間、私たちは彼と完全に恋に落ちました。

Drone CIの使用を開始できるように、2つのGithubリポジトリを用意しました。

Droneのデプロイ -本番および本番環境向けのDrone CIのインストールを簡素化します。
Drone Starter — Drone CI, Ansible, Docker Node.js .

, 51%, 49% — Github :)

, !

, .

Drone CI、Docker、Ansibleとの継続的な統合