こんにちは。アドテクスタジオでネットワークエンジニアをしている山本 孔明です。

アドテクスタジオでは、これまで CircleCI.com を利用しておりましたが、オンプレでの運用に切り替えました。

オンプレに移行するにあたり

まず、2016年4月(CircleCICI.com 利用)のアドテクスタジオでの利用状況は以下の通りでした。

• アドテクスタジオ内大半のプロダクト開発で利用
• 最大で同時 32 ビルドが可能
• 複数の利用者が好きに使用しており、処理待ちになってしまうことが多々あって処理速度に不満がチラホラでてきていた
• USリージョンへの転送待ち時間への不満が出ていた
• 機能としては概ね満足している

上記の3点目の処理に関する課題とコストの両方を解決できるのが、オンプレでの実装でした。オンプレで利用することで、以下の効果がありました。

• 同時に立ち上げるコンテナの数に契約上の制約がなく、物理リソース次第で思い切って増やすことが可能
• オンプレで構築することにより、転送速度の大幅な向上

いままでの CircleCI.com 利用時と比較して利用ユーザが  記事執筆時点で 3.5 倍程度に増えました。

オンプレの環境について

構成は以下の通りです。

主に、AWS、OpenStack の環境に作られたアプリケーションのビルドとして利用されています。図中の CircleCI Enterprise 部分は以前利用していたサーバを有効活用して専用のラックへ構築しております。利用したサーバは Intel の CPU E3-1270v3 を搭載したサーバで、OS は Ubuntu 14.04.4 LTS を使用しています。

※ CircleCICI Enterprise は以下のコンポーネントで構成されています。公式の図では Github Enterprise となっていますが、アドテクスタジオでは github.com で利用しております。

ServiceBox は CircleCI の frontend として利用されるコンポーネントです。ユーザからのアクセスや Github からの Webhook もこの ServiceBox で受けています。アドテクスタジオでは、OpenStack 上の仮想マシンとしては構築しています。

BuilderBox は実際のビルド処理をするコンテナが動作するサーバで、先ほど記載した Ubuntu をインストールした物理サーバで構築しています。コンテナは同時100を超える数を起動可能です。

処理のイメージは以下の通りです。

1. 該当の Repository に Pull Request が送られる
2. GitHub が Webhook の設定に従い CI Enterprise へ通知する
3. CircleCI.yml の内容に従いビルドが行われる
4. 結果を GitHub へ通知、GitHub は結果を表示する

CircleCI.com と何も変わりません。そのため、仕組みさえ作ってあげれば利用者側では Webhook 先を変えるだけで移行が可能という利点があります。

CircleCI Enterprise の管理について

CircleCICI の管理ですが、まだまだ管理者側で追える部分が少なく、メーカ側の解析対応（admin dev-consoleを使ってdebugをするなど）が必要になることが多いです。
管理画面の一部がおかしいなどとなると、CircleCICI のAdmin 画面であったり、出力されたログから追うことになるのですが、GUI、CLI ともにこれからの充実に期待といった感触です。まだ admin dev-console でテクニカルな操作をする必要がありますので、ここがAdmin画面からある程度のレベルは定型化され操作できると嬉しいです。

ユーザ目線ですと、CircleCI CI の画面上で Debug via SSH を使ったトラブルシュートなどは今まで通り使用することができますので、ビルドがうまくいかないなどの切り分けは従来通り可能です。

まとめ

色々と書きましたが、CircleCI Enterprise をオンプレ環境によって当初の課題をクリアすることができました。コストを抑えつつビルド環境をストレスなく利用できるようになったこと、アプリケーションのサイクルを開発者がストレスなく回していけるという意味で、多大な効果があったと感じております。

ビルドイメージのカスタマイズなどオンプレならではの取り組みはこらからではありますので、引き続きCircleCI Enterprise の動向に注目しつつ取り組んでいきたいと思います。