自己ホスト型の継続的統合システムの使用経験

はじめに

継続的インテグレーションなしの最新の開発を想像することは困難です。 多くの企業が1日に複数のリリースをリリースし、数千のテストを実行しています。 JenkinsとTravis CIの時代以来、最も多様なツールの多くが市場に登場しています。 それらのほとんどはSaaSモデルで動作します。サービスの使用またはユーザー数に対して固定料金を支払います。

ただし、アプリケーションコードを転送できない場合や、外部サービスに依存したくない場合など、ホストプラットフォームの使用は常に可能とは限りません。 この場合、サーバーにインストールできる（自己ホスト型）システムが役立ちます。 ボーナスとして、リソースを完全に制御でき、たとえばAmazon ec2を使用して、必要に応じてリソースをスケーリングできます。

この記事では、複数のオープンソースの自己ホスト型の継続的統合システムを使用した個人的な経験を紹介します。 他のシステムを使用した場合は、コメントでそれを教えてください。

基本的な概念

CIの基礎は、ビルド（ビルド）-プロジェクトの単一のアセンブリです。 ビルドは、さまざまなトリガーに従って組み立てることができます-スケジュールに従って、リポジトリへのプッシュ、プルリクエスト。 ビルドは一連のタスク（ジョブ）で構成されます。 タスクは、順次および並行して実行できます。 タスクのセットは、すべてのタスクまたはビルドマトリックス（分離が発生する特性）をリストすることで指定されます。 たとえば、プログラミング言語と環境変数のバージョンを示すことにより、言語の各バージョンと変数の各値に対してタスクが作成されます。

一部のciシステムにはパイプラインもあります-タスクはグループにグループ化され（ステージ）、現在のグループのすべてのタスクは並列で実行され、次のグループは前のグループが正常に完了した場合にのみ実行されます。 たとえば、テストパイプラインはデプロイです。テスト中のすべてのタスクが正常に完了した場合、デプロイグループからタスクを実行できます。

ciが効率的に機能するためには、キャッシュを作成することが重要です。キャッシュは、ビルドを高速化するために使用されます。 apt-packages、npm cache、composerのいずれかです。 キャッシュがなければ、各タスクを開始するときに、すべての依存関係を再度ダウンロードしてインストールする必要があります。これは、テストの実行自体よりも時間がかかる場合があります。 キャッシュがタスクを実行するサーバーに近いほど、たとえば、amazon ec2を使用している場合は、amazon s3にキャッシュを保存することをお勧めします。

ビルドを実行すると、アーティファクトが生成される可能性があります-アセンブリ結果、コードの清潔さに関するレポート、ログ。 これらのアーティファクトを表示およびダウンロードできるCIシステムは、生活を大幅に簡素化します。

同時に起動された多数のタスクを持つ大規模なプロジェクトがある場合、スケーリングせずに行うことはできません。 スケーリングは手動および自動です。 手動スケーリングを使用すると、無料のサーバーでランナーを自分で起動および停止できます。 自動スケーリングの場合、システム自体が新しい仮想マシンを作成するかどうか、およびその数量を決定します。 さまざまなCIシステムがさまざまなプロバイダーをサポートします-通常、Amazon、Google Compute、Digital Oceanなど。

重要なことは、システムがビルド構成（エグゼキューター）で指定されたコマンドを実行する方法です。 いくつかの方法があります：直接実行（ランナーが実行されているホスト上）、sshを介した仮想マシン、Dockerコンテナ内での実行。 それぞれの方法には、ciシステムを選択する際に考慮しなければならない機能があります。たとえば、Dockerコンテナーでタスクを開始する場合、セッションやターミナルがないため、テストできないものがあります。 また、ホストで実行する場合は、実行の終了後にリソースをクリーンアップすることを忘れないでください-データベース、Dockerイメージなどからデータを削除します。

最後に、重要ではないが、ciでの作業をより楽しくするオプションがあります。 ログ出力-リアルタイムモードで動作しますか、それとも一定の間隔で動作しますか？ 問題が発生した場合にビルドを中断することは可能ですか？ ビルド構成とタスクを確認できますか？

ドローン

ドローンは、ドッカーコンテナーに基づく継続的な統合システムです。 Goで書かれています。 現在のバージョンは0.4で、バージョン0.5はベータ版です。 レビューではバージョン0.5を考慮しています。



ドローンは、GitHub、Bitbucket、Bitbucket Server、GitLab、Gogsなどの多数のgitリポジトリで動作します。 ビルド構成は、リポジトリのルートにある.drone.ymlファイルで構成されます。



ビルドは複数のステップで構成され、各ステップは個別のdockerコンテナで並行して実行されます。 ビルドマトリックスは、環境変数によって定義されます。 サービスコンテナーを使用することができます-たとえば、データベースで動作するWebアプリケーションをテストする場合、サービスセクションでデータベースのドッカーイメージを設定する必要があり、ビルドコンテナーから自動的に利用可能になります。 任意のdockerイメージを使用できます。



ドローンは、ドローンサーバーとドローンエージェントで構成されます。 ドローンサーバーはコーディネーターとして機能し、1つ以上のドローンエージェントがビルドを実行します。 スケーリングは、追加のドローンエージェントを起動することで実行されます。 自動実行エージェントにクラウドリソースを使用する方法はありません。 組み込みのキャッシュサポートはありません（s3ストレージにキャッシュをロードおよび保存するためのサードパーティのプラグインがあります）。



ビルドで指定されたコマンドは、shインタープリターによってdockerコンテナーで直接実行されます。これは、条件付きロジックを持つ複雑なコマンドを実行する必要がある場合に問題を引き起こします。

Gitlab CI

Gitlab CIは、Githubの自己ホスト型アナログであるGitlabプロジェクトの一部です。 Gitlabはrubyで書かれ、 gitlabランナーはGoで書かれています。 gitlabの現在のバージョンは8.15、gitlabランナーは1.9です。



Gitlab CIはgitlabと統合されているため、リポジトリとしてgitlabのみを使用します。 gitlabでサードパーティのリポジトリをミラーリングできますが、私の意見では、これはあまり便利ではありません。 ビルドは、コンベアの原理に基づいて構成されています。 タスク起動のタイプを設定できます-Webインターフェースから自動または手動で。



Gitlab CIは、Webインターフェイス（コーディネーター）とランナーで構成されています。 コーディネーターは、タスクを実行するランナーにタスクを配布します。 シェル、docker、docker-ssh、ssh、virtualbox、kubernetes-幅広いエグゼキューターがあります。 ビルドログはリアルタイムではありません-Webインターフェースは定期的にサーバーをポーリングし、ログの新しい部分が表示された場合、最後に追加されます。



組み込みのキャッシュサポートがあり、s3互換のストレージをストレージとして使用できます。 アーティファクトがあります-個々のファイルを表示し、Webインターフェースからアーティファクト全体をダウンロードできます。



クラウドリソースの操作は、Docker mashineを使用して整理されます。 新しいビルドのリクエストを受信すると、空きマシンがない場合、Docker mashineは新しいマシンを作成し、そのマシン上でビルドを実行します。 同時に、ビルドに必要なイメージを再度ダウンロードする必要があるため、gitlabは、docker mashineプロバイダーと同じネットワーク上にある別のdockerレジストリを上げることをお勧めします。

シンプルシ

SimpleCIは、リソースの使用を最大化するために作成された継続的な統合システムです。 フロントエンドはphp（Symfony3、es6）で書かれ、バックエンドはjavaで書かれています。 現在のバージョンは0.6であり、積極的な開発が進行中です。



SimpleCIはgithubおよびgitlabリポジトリをサポートしています。 ビルドは、gitlabと同様、パイプラインの原則に基づいて編成されています。 1つのステージのフレームワーク内のすべてのタスクが正常に完了すると、次のステージが開始されます。



キャッシュのサポートされた作業。 キャッシュは、タスクの一部としてキャッシュファイルが変更された場合にのみストレージに注がれます。 s3互換ストレージとGoogleストレージの 2種類のストレージで作業を実装しました。



ビルドは、Dockerコンテナーを起動し、sshを介してビルドコンテナーに接続し、ビルドスクリプトを実行することで実行されます。 ビルドログはリアルタイムで表示されます（websocketとcentrifugoを使用）。



クラウドプロバイダーのリソースを使用することにより、自動スケーリングの可能性があります（これまではgoogleコンピューティングエンジンのみ）。 スケーリングを設定する場合、仮想マシンの作成時に使用されるスナップショットを指定する必要があります。 これにより、新しいマシンを作成するたびにロードしないように、必要なdocker-imagesを使用してスナップショットを作成できます。 アーティファクトのサポートはまだありません。

おわりに

このレビューでは、いくつかの自己ホスト型オープンソース継続的統合システムを紹介しています。 レビュー済みのものに加えて、ホスト型、商用、およびオープンなシステムも多数あります。 さまざまなCIシステムから選択し、必要なものに注意を払うと、テストに感謝します。

参照資料

• ドローン
• Gitlab CI
• シンプルシ
• ジェンキンス
• awersome ci - CIシステムのリスト、テストツール、およびデプロイ