NEW !
テーマ:

技術本部 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のビジネスモデルに更新が入ったことで、

たとえば、継続してクラウドサービスとして利用する場合、

  • 高額(前年度比較7倍弱)の更新費用がかかる
  • 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-image
    Create 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/

     

     

     

    いいね!した人  |  リブログ(0)

    テーマ:

    こんにちは
    株式会社AbemaTVのAbemaTV FRESH!でフロントエンドの開発をしているすちをと申します。

    今回は9月にオランダのアムステルダムで開催されたIBC2016(International Broadcast Conference)に参加してきましたのでその報告をさせていただきます。

    IBCとは

    もともとはヨーロッパ内の放送局向けに、放送分野を中心とした映像・音響技術の展示会として開催されはじめたイベントですが、近年ではそれに加えインターネット配信に纏わる幅広い最新テクノロジーのアピール場所となっています。今年は世界各国から1,600を超える出展がありました。

     

    会場

    毎年RAI(東京でいうビックサイト・大阪でいうインデックス)という会場で開催されています。

     

    会場内はジャンルごとに14のセクションへと分かれていています。

    中央にある3のホールでは期間中講演が行われていました。

    ご覧の通り広大で、何回も迷子になってしまいました。

     

    ゲート付近の端末で事前に予約しておいたメール内のQRコードを読み取ると、プリンターから入場カードが印刷されます。

     

    ブース

    今回見たブースの中で特に気になったものを紹介していきます。

    IBM

    ブースの写真を撮り忘れたので拝借させていただきました。

     

    IBMが開発している自然言語処理のWatsonを用いて、テニスのUSオープン映像に含まれている音声を字幕におこすデモが展示されていました。

    サンプルをみていただくとわかると思いますが、Confidenceは70〜90%台とほぼ正確に字幕として表示されています。

    実際にBluemixから使用が可能となっており、日本語にも対応している所が驚きでした。

    Adobe

    Adobe CCに搭載される新機能の発表と共にデモが行われていました。

    私が聞いた内容としてはAbode Premiereで

    • チームプロジェクト機能が強化される
    • ファイルはローカルではなくクラウド上で管理される
    • アプリケーション内でチャットのように共有作業者を招待できる

    というものでした。

    これまでは1人の作業データをクラウドで扱うという感じでしたが、これからは複数人がクラウド上で同時に作業を行えるというAdobeのアナウンスでした。

    詳しくはコチラにまとめられていたので気になる方は見てみて下さい。

     

    Crevo

    FRESH!の配信でも使用されているLiveShellは配信時に映像リソース(カメラなど)からHDMI経由でLiveShell端末を繋ぐことによってそのまま配信サーバーに映像を飛ばす事ができるデバイスです。(=PCを使わずに配信できるのがメリット)

    こちらで新しく展示してあったLiveShell.Xは1080p/60fpsでの生配信が可能なものなので将来的にはFRESH!でもこのレベルの画質で遅延なく配信できればいいなと感じました。

     

     

     

    Peer5 Happy Our

    夕方からは徐々に各ブースで🍺や🍷が配られるようになり参加者やブースの出展者が交流を深める時間となります。

    私もHls.jsの作者である@manguiさんとお話をしました。(Peer5のブースでした)

    FRESH!では数ヶ月前から一部のブラウザでHls.jsを使用しており、manguiさんが「最近TwitterでHls.jsと検索するとよく日本語のツイートでAbemaと引っかかるようになったがお前のとこか」の様なことを言っていましたw

    各国のエンジニアたちもクロスブラウザでのHLS(HTTP Live Streaming)再生に疲弊しているようで、デンマークから来たエンジニアはその場で1時間くらいmanguiさんにWebVTTの質問をしていました。

     

    所感

    知らないことが多かった

    今回このIBCに参加して心に残ったことは自分の知らない発見がたくさんあったことでした。映像という分野において4K、HDR、VRなどの技術をどうWebの中で表現していくか注視していきたいと思います。またOTTの台頭によってインターネット動画の機運が世界的に急速に高まっていることも身にしみて感じました。

    つたない英語でも親身に受け答えしてもらえた

    IBCに参加されている方は皆さん優しく、私みたいな英語スキルの低い日本人の質問にも耳を傾けてくださいました。それ故、今回来ていたヨーロッパ各国のエンジニアと同じくらいスムーズに議論できるようにならないとと痛感しました。

    アムステルダムはすごいいいところだった

    コンパクトな街で市内であれば自転車やロードバイクでアクセスできそうな感じでした。Heinekenがものすごく安くかったです。

     

     

     

     

     

    いいね!した人  |  リブログ(0)

    テーマ:

    技術本部 Advanced Dev.Center(略してADC)の村上です。

    私達はMake Your Goals Come True. Easier + Faster. 

    をコンセプトに開発環境の改善や統一化を行ってます。

    タイトルのとおり、私達の組織ではソースコードのバージョン管理システムとしてGithub Enterprise(以下GHE)を導入しており、今回久しぶりにアップデートを行ったので、それについて書かせていただきます。

    なお、今回の作業にはADCメンバーに加え、敏腕インフラエンジニアの@kakerukaeruさんのお力添えあってこそということを彼の上司@strskへ向けてアピールしておきます。

     

    規模・SPEC

    規模感としてはユーザ数は約1000名、Organization約400、Repository約10,000になります。

     

    - Primary on AWS EC2

    Instance Type :r3.4xlarge

    EBS(root device) :100GiB

    EBS(block device) :1500GiB

     

    - Replica on AWS EC2

    Instance Type :r3.4xlarge

    EBS(root device) :60GiB

    EBS(block device) :1500GiB

     

    アップデート方針決め

    アップデート前のバージョンはVersion 2.2.7で、アップデート検討中にVersion2.7が発表されたのですが、発表されたばかりだったため2.7系へのアップデートは行わず、2.6系に留めることにしました。

    今回Version 2.6.8にアップデートしたわけですが、GHEの仕様上、アップデートは現在のバージョン(v2.2.7)から最新バージョン(v2.6.8)まで一気に行うことはできないので、いったん2.4系へアップデートしてから2.6系へアップデートする手順を踏んでいます。

     

    今回の作業で最も注意を払った点は

    ・会社の資産であるソースコードや付随データを失わないこと

    ・サービスに支障をきたさないこと

     

    なので万が一のことを考えいつでも戻せるような手順を事前検証を行いつつ、何度も考えては議論しました。

    右矢印結論

    ・アップデート前のプライマリはアップデート後もそのまま残しておいて、いつでも元のバージョンへ戻せるようにしておく。

    ・アップデートするのはレプリカのみとする。アップデート後は本番のElasticIPを付け替えて本番として利用する。

    ・新プライマリ、旧プライマリのそれぞれには新規でレプリカを用意する。

     

     

    事前検証&準備

    主に検証したのは以下になります。

    ・インスタンス作成〜レプリケーション

    ・リストア検証、snapshotからの再構築
    今回は切り戻しをしないので本手順は発生しませんが、再現性の確認のため実施。

    ・プライマリとレプリカの設定ファイルの比較

    $ ssh -p122 admin@hostname -- 'ghe-config -l'
    

    でCLIから設定の確認ができます。

    アップデート前はv2.2だったのでレプリカとの設定ファイルの結構差分がありました。

     

    ・backupUtilsの更新

    githubの公式ツールであるbackupUtilsが古くなっていたので更新。

    ・EBS snapshotの作成

    snapshotは差分バックアップなので、事前に実行しておくとメンテナンス時間中のバックアップが短くてすみます。

     

    手順

    ・メンテナンス開始告知

    ・メンテナンスモードに入れ、ユーザアクセス遮断

    ・バックアップ( backup-utiles及び EBSスナップショット)を取得

    ・レプリカとプライマリのレプリケーションを切断

    ・レプリカのSettingsをプライマリと同じにする

    ・レプリカをアップデート(v2.2.7 -> 2.4.9 -> 2.6.8)

    2.2.7 -> 2.4.9は約1時間、2.4.9 -> 2.6.8は約40分かかりました。

    ・新しくレプリカ機を用意しレプリケーション開始

    ・プライマリとレプリカのElasticIPを付け替える

    この作業により、DNS更新なしにレプリカを本番に置き換えることができますし、万が一の場合も即時元のバージョンへ戻すことができます。

    ・メンテナンスモードを解除

     

    確認コマンド

    アップデート前後でのrepoやorganizationデータの比較に利用したAdmin用APIは下記になります。

    - Repository list
    http(s)://<hostname>/stafftools/reports/all_repositories.csv
    
    - Organizations list
    http(s)://<hostname>/stafftools/reports/all_organizations.csv
    
    - Gist list(only public)
    http(s)://<hostname>/api/v3/gists/public
    
    - number of issue, hook, milestone, orgs, repost, comment etc
    http(s)://<hostname>/api/v3/enterprise/stats/all
    

     

    アップデート後

    1. pull requestが消えた!?

    メンテナンス終了後、業務開始時間になると、pull requestが表示されないとの報告が続々と寄せられました。

    アップデート前後のpull request数の変化はなく、詳細に確認してみるとlistの表示だけに問題があることがわかりました。結果としてindex作成が終わっていないことが原因でした。その後もindex作成は完了せず、結局、16時間後に確認した時点で80%弱の進捗でした。

    翌朝ようやくIndex再構築の完了が確認でき、pull requestのリスト表示は正常に戻りました。次回のアップデートでは事前に周知しておきたいです。

    2. deploy keyが消えた!?

    GHEの仕様でdeploy keyはrepository毎に設定してくださいというアナウンスをしていましたが、事実上2.2系では同じorganization内であればdeploy keyの使い回しができてしまっていました。v2.4にバージョンアップしたことで仕様に忠実(?)になり、その使い回しができなくなったようです。

    https://enterprise.github.com/releases/2.4.0/notes

    正しい挙動になったということなのですが、一部利用者間で混乱が発生する事態になりました。repository数が多いプロジェクト救済のため、MachineUserの運用も検討しましたが、複数のデメリットが払拭できず見送ることにしました。
    GHEへMachineUserの運用について問い合わせたところ、issueは上がっているものの、現行、一般ユーザと権限・コスト両面で同様の取り扱いということでしたので、改善を待ちたいです。

    3. markdownの画像が表示されない!?

    バージョン2.6からW3Cのレコメンドに従い、HTTPSコンテンツ上のHTTPコンテンツ(いわゆるmixed content)はブロックするように仕様変更されていました。

    なので2.6以降使えなくなっています。

    https://enterprise.github.com/releases/2.6.0/notes

    4. やっぱり古いバージョンを残しておいて良かった

    こちらは頃合いをみて削除予定ですが、アップデート後はたくさんの方が検証するために、アップデートとは無関係の事象も報告されたりするので、問題の切り分けのためにも残しておいてよかったと思いました。また、いざという時はこっちにそのままのデータがあるという安心感も大きいです。

    これから

    未解決の問題もまだ残っており、新機能の検証、バイナリデータの管理等改善したい項目が日々生まれている状況です。全サービスのエンジニアと協力し合いながら、快適な開発環境の提供をチームで取り組んでいきます。

    いつもADCに協力してくれるエンジニア・クリエイターの皆様、いつもありがとうございます。皆様の激励が我々の励みになっています。

    また今回の記事が同じような開発環境を担当している方々の参考になれば幸いです。
     

     

     

    いいね!した人  |  リブログ(1)