
RubyistがScalaを勉強した話(続き)
こんにちは。アドテクスタジオでネットワークエンジニアをしている山本 孔明です。
アドテクスタジオでは、これまで CircleCI.com を利用しておりましたが、オンプレでの運用に切り替えました。
まず、2016年4月(CircleCICI.com 利用)のアドテクスタジオでの利用状況は以下の通りでした。
上記の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を超える数を起動可能です。
処理のイメージは以下の通りです。
CircleCI.com と何も変わりません。そのため、仕組みさえ作ってあげれば利用者側では Webhook 先を変えるだけで移行が可能という利点があります。
CircleCICI の管理ですが、まだまだ管理者側で追える部分が少なく、メーカ側の解析対応(admin dev-consoleを使ってdebugをするなど)が必要になることが多いです。
管理画面の一部がおかしいなどとなると、CircleCICI のAdmin 画面であったり、出力されたログから追うことになるのですが、GUI、CLI ともにこれからの充実に期待といった感触です。まだ admin dev-console でテクニカルな操作をする必要がありますので、ここがAdmin画面からある程度のレベルは定型化され操作できると嬉しいです。
ユーザ目線ですと、CircleCI CI の画面上で Debug via SSH を使ったトラブルシュートなどは今まで通り使用することができますので、ビルドがうまくいかないなどの切り分けは従来通り可能です。
色々と書きましたが、CircleCI Enterprise をオンプレ環境によって当初の課題をクリアすることができました。コストを抑えつつビルド環境をストレスなく利用できるようになったこと、アプリケーションのサイクルを開発者がストレスなく回していけるという意味で、多大な効果があったと感じております。
ビルドイメージのカスタマイズなどオンプレならではの取り組みはこらからではありますので、引き続きCircleCI Enterprise の動向に注目しつつ取り組んでいきたいと思います。
Author