技術本部 Advanced Dev.Center（略してADC）の大倉です。
私達は、Make Your Goals Come True. Easier + Faster. 、をコンセプトに1600人規模の開発環境の改善や統一化を行ってます。
この記事は、CircleCI Enterprise管理者を対象としております。今後、導入を予定されている管理者の方にとって、少しでも有益な情報になればと思います。
CircleCI kim様、kevin様、いつも迅速なサポートありがとうございます。とても感謝しております。
CircleCI kim, kevin
Thank you very much always for your cooperation !
なぜ、オンプレ化したか
当初のEnterprise版は.com版と同じようにクラウドサービスとして展開されていましたが、2016年にCircleCI Enterpriseのビジネスモデルに更新が入ったことで、
たとえば、継続してクラウドサービスとして利用する場合、
- 高額（前年度比較７倍弱）の更新費用がかかる
- iOS用のビルド・テスト環境が利用できない
という状況になったことが主な理由です。
オンプレ化のメリット／デメリット
- メリット
次章”アーキテクチャ詳細図”のようなサーバー構成にしたところ、ビルド及びテスト処理速度が速くなりました。つまり、サーバー構成をカスタマイズできる点が
大きなメリットでしょうか。また、ビルドイメージをサービス仕様に合わせてカスタマイズすることもできるので、より処理速度を速くできるという点もあります。
- デメリット
サーバー構成やビルドイメージをカスタマイズできるメリットの代わりに、それを運用・管理する困難さが管理者に発生します。Enterprise版は発展途上なので、管理者向けのドキュメントやノウハウは、利用者向けのドキュメントと比較するとかなり少ない状況ですので、CircleCIのエンジニアと情報共有をしながら、BugFixしてもらいながら、運用・管理する必要があります。
アーキテクチャ詳細図
基本、GithubEnterpriseへのPush→（トリガー）→CircleCIEntrepriseでJobを実行 → 結果をSlackへ送信
といったCI環境を構成しています。CircleCIEntrepriseはymlの設定だけでCI環境を得ることができるため、プロジェクト毎にサーバを用意することなく、属人的作業も排除することが出来、サービス品質を維持していく上で重要な役割を担っています。
"Immutable Infrastructure"という設計
BuilderBoxは基本使い捨てする設計（Immutable Infrastructure）で提供されているのですが、弊社のOn-Premise（OpenStack）環境では、インスタンスを使い捨てるような設計にすることが厳しかったので、LXCコンテナデータを削除し、コンテナイメージを再ダウンロードすることで、LXCコンテナを使い捨てる（初期化する）ことにしました。
$vi /etc/init/circle-image.conf---> 9行目のmanualをコメントアウト#manual<---$ sudo service circle-image start$ sudo tail -f /var/log/upstart/circle-image.log〜省略〜+ curl -sSL -o /mnt/tmp/container.tar.gz https://circleci-enterprise-assets-us-east-1.s3.amazonaws.com/containers/circleci-precise-container_0.0.1338.tar.gz+ untar_image /mnt/slave-image+ SUBVOLUME=/mnt/slave-image+ sudo -n btrfs subvolume create /mnt/slave-imageCreate subvolume '/mnt/slave-image'+ sudo -n tar -xp --use-compress-program=pigz -f /mnt/tmp/container.tar.gz -C /mnt/slave-image --numeric-owner
監視（CLITICAL）
主に監視をしているのは以下の項目です。
- ServiceBox（cpu, disk, url（https://{circleci-url}) , load , ntp, docker containers）
- BuilderBox（“Fleet State = not-healthy”, “queue total wait time per instance" and "leaked error at a container”）
監視をする上で利用しているREST APIは、この辺でしょうか。
※非公式APIも含まれますのでUpdateにより利用できなくなる可能性があります。
- https://{CIRCLECI URL}/api/v1/admin/build-state-summary
- https://{CIRCLECI URL}//api/v1/admin/build-state
- https://{CIRCLECI URL}//api/v1/admin/recent-builds?shallow=true&offset=0&limit=100
- https://{CIRCLECI URL}//api/v1/admin/users?circle-token={TOKEN_CODE}
- https://{CIRCLECI URL}//api/v1/admin/recent-builds
スケールアウト
（アーティファクトを保存する先としては、AWS S3を利用してるため）スケールアウトはBuilderBoxのみ考えれば問題ありません。
free / busy コンテナの数をグラフ化し、以下のようにグラフが交差したときに弊社では2インスタンス（6コンテナ）追加しました。
コンテナ
コンテナは、Javaプラットフォーム上にClojureで作られているようです。
$ lein repl :connect 6005
で対話式に設定変更が可能ですが、通常アクセスする必要はありません。
（弊社ではDebugするためにCircleCI様の元でアクセスすることはありましたが）
なお、Javaプロセスは、以下のように起動しています。
sudo -E -u ubuntu java -Djava.net.preferIPv4Stack=true -server -XX:+UseConcMarkSweepGC -Xss1m -Xmx4g -Xverify:none -XX:+CMSClassUnloadingEnabled -Dfile.encoding=UTF-8 -jar /var/cache/circle-builder/circle.jar
はまったところ
ステージング環境ではまったのですが、NTPの時刻がServiceBoxとBuilderBoxで合ってないとServiceBoxにてBuilderBoxが正常に認識されないということがありました。
ステージング環境でも最低限の監視は入れたほうがいいですね。
おわりに
CircleCIでは、.comの運用をAWSで行っているからかAWSを基本とした設計になっています。予算に余裕があれば、オンプレ化するなら、AWSをおすすめします。
また、発展途上のツールなので、最新のバージョンにしておいたほうがBugを踏まなくて済みます。
参考URL
https://circleci.com/docs/enterprise/
https://enterprise-docs.circleci.com/