IIJのサービス開発を支えるGithub Enterpriseとdrone.io

2018年12月04日 火曜日


【この記事を書いた人】
濵﨑 一樹

システムクラウド本部所属。IaaSを作っています。旅行をしたり、雪山に登って写真を撮るのが趣味です。

「IIJのサービス開発を支えるGithub Enterpriseとdrone.io」のイメージ

IIJ 2018 TECHアドベントカレンダー 12/4(火)の記事です】

IIJではサービス開発を支えるための基盤としてGithub Enterpriseを利用しています。

今までにIIJの開発環境についてはいくつか発表をしていますのでこちらもご覧ください。

GitHub Enterprise と内製開発の文化 from IIJ
IIJではGithub Enterpriseと組み合わせて使うための継続的インテグレーション・継続的デリバリー(CI/CD)環境としてdrone.ioを提供しています。この記事ではこちらをメインにご紹介いたします!

Github Enterprise (GHE)

IIJでは2013年8月から Github Enterprise の利用を開始し、2018年12月現在IIJではGithub Enterpriseを470ユーザで利用しています。これは国内でもなかなか大きい規模なのではないかと思います。

IIJではなるべく最新版を提供するようにしていて、現在はv2.15.3を提供しています。2018年12月の利用規模は以下のようになっています。

リポジトリ数 8063
push数 567766
organization数 304
Pull Request数 86056
Issue数 137516
gists数 8590

470ユーザでリポジトリ数が8000を超えているのは正直多すぎるような気もしますが、ちょっとしたコードやツールでもGHE上で管理することが根付いてきている証拠だと思います。

GHEの問題点

GHEを利用していて一番困ることのは、様々なCI/CDサービスとの連携が難しくなることです。SaaSからはGHEのコードにアクセスできないため、自分たちで環境を整える必要がありました。

いまでは Travis CICircle CISider もエンタープライズ版を出していますが、GHE導入当時としてはJenkinsを自分たちで立てて利用するのが主流であったと思います。

CI/CD環境drone.io

drone v0.8のスクリーンショット

 

IIJではGithub Enterpriseと連携するCI/CD環境としてdrone.ioを利用しています。

一日あたり300から400ほどのテストを実行しており、10〜20ほどのテストが同時に走っています。これだけのテストが走るとSaaSを利用した場合テスト待ちが発生する可能性が高いですが、エージェントを増やすことでほとんどテスト実行待ちを発生させないように運用しています。

実際に利用してみようという方は、細かいTipsを drone.io Advent Calendar 2017 に書いていますのでご覧ください。

dockerを便利に使えるようにする

drone.ioはdockerベースのCIツールです。dockerのコンテナ上で実行することで実行場所を選びませんし、テスト環境も毎回同じ環境で実行することが可能です。

オンプレミスで実行する場合には Docker Hub に上げられないようなテスト実行用の内製イメージ置き場が必要になります。IIJでは共通で使えるイメージ置き場として Docker Registry 、Web UIとして Docker Registry Frontend を提供しており、droneで使うテスト用イメージを自由に置いておくことができます。

Docker Registry Frontend

 

もし新しくイメージ置き場を導入するのであれば Harbor を導入するのが良いと思います。

イメージ置き場の管理では登録されたイメージは消すことができない、というのが運用上の注意です。チーム内でしか使わないと言った場合には管理できるかもしれませんが、複数チームで使われだした場合はどのイメージが不要になったかを調べるすべはなくなります。S3などのオブジェクトストレージに入れるのがよいですが、難しい場合はディスクの拡張をはじめから考えておきましょう。

今では300GB近くのイメージを管理していますが、150GBほどのイメージは毎日のテストで使われています。

破壊的変更との戦い

この記事を書いている時点でのdroneの最新版はv0.8.9です。IIJではv0.3のころから利用していましたが、正式版ではないということでバージョンが0.1上がるたびに破壊的変更が多く入りました。設定ファイルの書式が大きく変わったり、プラグイン機構が変わったりするなどしたため、移行するのも大変でした。そのため破壊的変更が入るたびに複数のバージョンのdroneを並行稼働させることでそのまま利用し続けられるようにしました。現在ではv0.3, 0.4, 0.5, 0.8の4バージョンを並行して提供しています

社内向けのドキュメントにバージョンごとの設定を案内するなどしてなるべく利用しやすいようにしています。

キャッシュ置き場の提供

droneのv0.5からテストをまたいだキャッシュ機能がなくなりプラグイン化されました。それまではジョブ実行ノードに直接吐かれる仕様でした。似たような挙動をするプラグインとして Volume Cache Plugin がありますが、これは特権を要求するので使い勝手がよくありません。

そこで AWS S3 Cache Plugin から利用できるようにS3互換ストレージを minio で建てています。キャッシュ専用領域としておいて、定期的に古いキャッシュを削除するスクリプトを設定して運用しています。

ちょっとしたツールですが、それぞれのバージョンに合わせて便利になるように立てていたり、ドキュメントが少ないので時にはソースコードを読んで挙動を追ったりしてドキュメントに反映させています。

droneの新バージョン1.0のRelease Candidateが登場

そんな中、droneの正式バージョンであるDrone 1.0 Release Candidateが登場しました。私の次の記事でdroneがどのように進化したのかをレポートする予定です。

濵﨑 一樹

2018年12月04日 火曜日

システムクラウド本部所属。IaaSを作っています。旅行をしたり、雪山に登って写真を撮るのが趣味です。

Related
関連記事