Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ドリコムのインフラCI

2,041 views

Published on

ドリコム AdventCalendar 2016( http://www.adventar.org/calendars/1768 ) の資料です

Published in: Technology
  • Be the first to comment

ドリコムのインフラCI

  1. 1. Copyright Drecom Co., Ltd. All Rights Reserved. sue445 2016/12/01 ドリコムAdventCalendar ドリコムのインフラCI
  2. 2. Copyright Drecom Co., Ltd. All Rights Reserved. ● Go Sueyoshi a.k.a sue445 ○ Ruby歴 4年半 ○ golang歴 2年 ○ Go歴 34年(34歳) ● 株式会社ドリコム インフラストラクチャー部所属 ○ インフラチームは全部で数人 ○ 社内ツールや社内ライブラリを中心に、サーバサイド全般をアプリから インフラまで浅く広く ○ 良く言えば「フルスタックエンジニア」、悪く言えば「ワンオペエンジニア」 ● 「ドリコムのプリキュアの人」として社内外で有名 自己紹介
  3. 3. Copyright Drecom Co., Ltd. All Rights Reserved. 【宣伝】ドリコムについて ● http://www.drecom.co.jp/ ● スマホゲームと広告配信サービスを開発・運用している会社 ● 社員数280名 ● ゲームはRuby + Ruby on Rails、広告はElixir + Phoenix
  4. 4. Copyright Drecom Co., Ltd. All Rights Reserved. Agenda ● インフラCIとは? ● 弊社のインフラCI ● 使ってるツールの紹介 ● Jenkinsのジョブ ● インフラCIのハマりどころ ● おまけ
  5. 5. Copyright Drecom Co., Ltd. All Rights Reserved. インフラCIとは? ● インフラ環境をCIすること ○ よくある例)PullRequestで検証環境にプロビジョニングを 実行し、問題なければPullRequestをマージ、自動的に本 番環境にも同じプロビジョニングが実行される ● 詳しい資料 ○ インフラの継続的デリバリー - naoyaのはてなダイアリー http://d.hatena.ne.jp/naoya/20140821/1408577976 ○ インフラ系技術の流れ - Gosuke Miyashita http://mizzy.org/blog/2013/10/29/1/ ● 弊社のケースは若干違う(後述)
  6. 6. Copyright Drecom Co., Ltd. All Rights Reserved. 弊社のインフラCIでやってること ● ゴール ○ 特定のアプリに依存しない全社基盤のイメージを作成 ○ 必要に応じてアプリ固有のレシピも適用してイメージを作 成 ● Jenkinsで行っていること ○ PullRequestやmasterブランチをAWSなどにプロビジョニ ングを実行(開発ビルド) ■ 自動実行 ○ masterブランチをAWSなどにプロビジョニングを実行し、イ メージの作成(イメージビルド) ■ インフラチームによる手動実行
  7. 7. Copyright Drecom Co., Ltd. All Rights Reserved. インフラCIの全体像(開発ビルド) 社内Jenkinsサーバ ソースをclone JenkinsがVagrantで AWSなどにVMを立て て、itamaeのレシピと Serverspec実行
  8. 8. Copyright Drecom Co., Ltd. All Rights Reserved. インフラCIの全体像(イメージビルド) ソースをclone packerでitamaeとServerspecを実行 して、問題なければイメージ( AMIや テンプレート)を作成する 社内Jenkinsサーバ AMI テンプレート
  9. 9. Copyright Drecom Co., Ltd. All Rights Reserved. 使っているツールの紹介
  10. 10. Copyright Drecom Co., Ltd. All Rights Reserved. 使っているツール:itamae ● http://itamae.kitchen/ ● クックパッドの中の人が作ったプロビジョニングツール ● Ruby製でChefの軽量版 ● 日本人が作ったということもあり、国内だと割と使われている ○ 日本語で質問できるのもメリット ○ 海外からのissueやPRも見るので海外で全然使われてい ないってわけではなさそう ● 自分で作ったレシピをgem(Rubyのライブラリ)にして rubygems.org(gemのホスティングサイト)で配布することもで きる
  11. 11. Copyright Drecom Co., Ltd. All Rights Reserved. サンプルコード recipe.rb package 'nginx' do action :install end service 'nginx' do action [:enable, :start] end ● itamae local recipe.rb ● itamae ssh --host host001.example.jp recipe.rb
  12. 12. Copyright Drecom Co., Ltd. All Rights Reserved. Chef -> itamae ● 弊社だと元々CentOS 6環境をChefでプロビジョニングしてい た ○ ドリコムのInfrastructure as code http://www.slideshare.net/y05_net/infrastructure-as-co de-35373108 ● CentOS 7移行時にChefのレシピを全部itamaeに置き換えた ○ レシピ数は全部で30~40くらい ○ 過渡期でインフラエンジニア2人 + アプリエンジニア4人くら いがかりで2~3ヶ月 ○ 既存サービスはそのままで、新規サービスは全てCentOS 7で作成
  13. 13. Copyright Drecom Co., Ltd. All Rights Reserved. itamaeを導入した理由 ● vs Chef ○ ChefはRuby製だけどRuby以外に覚えること(Chefの独 自ルール)が多くて初見だと学習コスト高そうだった ○ itamaeは普通のRubyのgemでRubyを知っていれば他に 覚えることは少ないのでアプリエンジニアにもとっつきやす い ○ 当時6人中3人がitamae使えたのでチーム内で教えれば なんとかなるだろうという思い ● vs Ansible ○ 検討材料としては挙がったけど、Ruby書ける人が多かっ たので流れでitamaeになった
  14. 14. Copyright Drecom Co., Ltd. All Rights Reserved. 使っているツール:Serverspec ● http://serverspec.org/ ● RSpec(Rubyのテスティングフレームワーク)をベースにした、 インフラ構成をテストするためのツール ● インフラ構成のテストをするツールだとこれがデファクトスタン ダード ● itamaeで実行したプロビジョニングが本当に設定されてるかど うかの検証をしている
  15. 15. Copyright Drecom Co., Ltd. All Rights Reserved. nginx_spec.rb describe package('nginx') do it { should be_installed } end describe service('nginx') do it { should be_enabled } it { should be_running } end サンプルコード
  16. 16. Copyright Drecom Co., Ltd. All Rights Reserved. 使っているツール:Vagrant ● https://www.vagrantup.com/ ● HashiCorp社が作った仮想環境の構築ツール ● VirtualBoxやAWSなどを同一インターフェースで扱える ● プラグイン導入することでいろんな環境で使える
  17. 17. Copyright Drecom Co., Ltd. All Rights Reserved. Vagrantプラグイン ● https://github.com/schubergphilis/vagrant-cloudstack ○ IDCFがcloudstackのAPIに対応してるのでvagrantプラグ インもそのまま使えた ● https://github.com/KariusDx/vagrant-aws ○ スポットインスタンス対応のfork版 ○ CIでスポットインスタンスを使うことにより費用を抑えてい る(オンデマンドの1/10くらいの値段) ● どちらも社内で使うには若干機能足りてなかったり、バグが あったのでPR投げた ○ vagrant-cloudstackはmasterに取り込まれたが現時点で はまだリリースされてない ○ vagrant-awsはPR放置されてる(´・ω・`)
  18. 18. Copyright Drecom Co., Ltd. All Rights Reserved. Tips:正式公開されていないVagrantプラグインを使う方法 ● 正式公開されていれば vagrant plugin install でインストール すれば使えるが、それができない時の対処法 ● Vagrantプラグインも普通のgemなので、Gemfileを書いて bundle exec vagrant 〜 で実行すればいい ● https://www.vagrantup.com/docs/plugins/packaging.html source "https://rubygems.org" group :development do gem "vagrant", github: "mitchellh/vagrant", tag: "v1.8.6" end group :plugins do gem "vagrant-aws", github: "sue445/vagrant-aws", branch: "spot_iam_instance_profile" gem "vagrant-cloudstack", github: "schubergphilis/vagrant-cloudstack", branch: "master", ref: "c2107d" end
  19. 19. Copyright Drecom Co., Ltd. All Rights Reserved. 使っているツール:Packer ● https://www.packer.io/ ● HachiCorp社が作った、複数プラットフォームでイメージを作 成するツール ● プラグイン導入することでいろんな環境で使える ● packer buildでやってること ○ 1. イメージを作りたい先のクラウドにVMを作成 ○ 2. 予めgit archiveでtar.gzに固めておいたローカルのレシ ピをVMに転送 ○ 3. VM内でtar.gzを展開してレシピとテストを実行 ○ 4. 問題なければイメージを作成
  20. 20. Copyright Drecom Co., Ltd. All Rights Reserved. プロビジョニングの構成 ● 1つのVMに対してitamaeを2回実行している ● 1回目:イメージ作成時 ○ role(サーバの役割)に関わらずpackageは全てインストー ルする ● VM作成してクラウドのコンソールからタグを付与 ● 2回目:VM再起動時 ○ VM起動時に2回目のitamaeを実行するためのsystemd serviceを実行 ○ 自分自身に付与されたタグ情報を取得 ■ roleに応じてserviceを起動(例:dbロールであれば mysqlを起動) ■ タグにアプリ名が含まれていればアプリ固有のレシピ を実行
  21. 21. Copyright Drecom Co., Ltd. All Rights Reserved. 開発ビルド用のジョブ ● マルチ構成プロジェクトにして、1つのジョブで同時に複数ビル ドが実行できるようにしてる ● Jenkins 2.0の新機能のpipelineを使いたいけど、複数のジョ ブのコンソールログが1ヶ所になって混ざってしまうので移行は してない
  22. 22. Copyright Drecom Co., Ltd. All Rights Reserved. 開発ビルド用のジョブ 縦の軸はどのクラウドに対してプロビジョニングをするかどうか ● 対応するVagrantプラグインをインストールして ● vagrant up --provider=$PROVIDER みたいな感じで実行 $ P R O V I D E R
  23. 23. Copyright Drecom Co., Ltd. All Rights Reserved. 開発ビルド用のジョブ 横の軸は使用するnodeファイル(設定ファイル) ● リポジトリにコミットしてるのはdefault.yml(role全無し)だけだ が、ビルド時にrolesを全部付与したyml(role_all.yml)を生成 してビルドを実行することにより、role全有り、全無しを両方テ ストしてる $NODE
  24. 24. Copyright Drecom Co., Ltd. All Rights Reserved. イメージビルド用のジョブ ● プルダウンでパラメータを切り替えている ● 弊社だとサービス単位(費用が発生する請求単位)で AWSや IDCFのアカウントが複数分かれているので、作成先のアカウ ントを選択できるようにしてる ○ クラウドによってはアカウント間でのイメージ共有ができる ので不要なんだけど念のため
  25. 25. Copyright Drecom Co., Ltd. All Rights Reserved. イメージビルド用のジョブ ● パラメータが多いけど、Rebuilder Pluginで一度使ったパラ メータを使いまわせるようにしてるので2回目以降はそんなに 大変ではない ○ https://wiki.jenkins-ci.org/display/JENKINS/Rebuild+Pl ugin ● イメージ作成に成功したらgitのtagを作り、かつイメージにも tagと同じ名前をつけることにより、イメージからどの時点の ソースコードを元にビルドしたかが特定できるようにしてる
  26. 26. Copyright Drecom Co., Ltd. All Rights Reserved. イメージビルド用のジョブ git tags AMI
  27. 27. Copyright Drecom Co., Ltd. All Rights Reserved. インフラCIのハマりどころ 1. ビルドが遅い 2. たまにビルドが落ちる
  28. 28. Copyright Drecom Co., Ltd. All Rights Reserved. 1. ビルドが遅い ● VMの起動に1〜2分 ● itamaeを全部流し切るのにローカル実行で20分くらい、AWS のc3.largeで10分くらい ● Serverspecの実行は数分 ● 解決策は金の弾丸で殴るしかなさそうw
  29. 29. Copyright Drecom Co., Ltd. All Rights Reserved. 何が遅いのか調べる ● itamae実行時に --profile をつければコマンド単位の実行時 間をjsonで出力してくれる ● jsonをparseして処理時間が長いものを抽出 ● ワーストランキングを出力するスクリプト ○ https://gist.github.com/sue445/96058bd109601b58f5a 81b826949135f
  30. 30. Copyright Drecom Co., Ltd. All Rights Reserved. 調べた ● 36.90秒 yum -y install td-agent-2.3.1 ● 36.33秒 yum -y install openssl-devel ● 26.64秒 /usr/local/bin/gem update --force --no-document ● 19.99秒 yum -y install ImageMagick-6.7.8.9 ● 17.93秒 yum -y install tcpflow ● 17.33秒 yum -y install epel-release ● 15.76秒 yum -y install chrony-2.1.1 ● 15.13秒 yum -y install gcc-c++ ● 14.20秒 yum -y install autoconf ● 14.20秒 yum -y install mdadm
  31. 31. Copyright Drecom Co., Ltd. All Rights Reserved. _人人人人人人人_ > yum install <  ̄Y^Y^Y^Y^Y^Y ̄
  32. 32. Copyright Drecom Co., Ltd. All Rights Reserved. なぜ遅いか考察 ● rpmの取得と、取得したrpmをローカルにインストールする部 分のどっちが遅いかまでは検証してない ● packageを全部インストールした状態でイメージ化しておい て、roleによってserviceの起動のみを切り替えるというのは理 にかなってそう
  33. 33. Copyright Drecom Co., Ltd. All Rights Reserved. 2. たまにビルドが落ちる 毎回2 x 3通りもテストをやってると1つだけビルドが落ちることが たまによくある(インフラCIガチャ)
  34. 34. Copyright Drecom Co., Ltd. All Rights Reserved. インフラCIのビルドが落ちるケース ● VM起動に失敗 ● rsync中に固まる ○ 無限に止まるので他のジョブに影響するのでタイムアウト 30分に設定 ○ https://wiki.jenkins-ci.org/display/JENKINS/Build-timeo ut+Plugin ● AWSスポットインスタンスの価格高騰で起動に失敗 ○ $0.04に設定していればほぼ安全圏だけど、たまに$1超え るw ○ 高騰していないスペックやアベイラビリティゾーンを変えて 回避
  35. 35. Copyright Drecom Co., Ltd. All Rights Reserved. インフラCIのビルドが落ちるケース ● レシピ実行中にプロセスが突然死ぬ ○ 何回実行しても再現するので調べたら、一部コマンドの標 準出力への書き込みをやめたらプロセスが死ななくなった ● rikenが調子悪くてyum install失敗 ● いずれの場合も失敗した内容によって偶然落ちたビルドなの でスルーするかどうか判断する必要がある(つらい) ● コンソールログの内容を見て判断する必要があるので、失敗 した時のために可能な限りログは全部出しておく
  36. 36. Copyright Drecom Co., Ltd. All Rights Reserved. おまけ1:テスト駆動インフラ アプリ開発でよく使われるTDD (Test Driven Development = テ スト駆動開発) をインフラにも適用することができる 1. インフラの確認項目をServerspecでテストを書く 2. 期待したエラーが出ることを確認 (Red) 3. サーバで適用したいitamaeのコードを書く 4. テストが通っていることを確認 (Green) 5. ダメなら3に戻る 6. 必要ならリファクタリング (Refactoring) ● VagrantとVirtualBoxを使うと手軽にVMを作り直せるのでイン フラTDDしやすい
  37. 37. Copyright Drecom Co., Ltd. All Rights Reserved. テスト駆動インフラでも黄金の回転を http://www.slideshare.net/t_wada/the-spirit-of-tdd/27
  38. 38. Copyright Drecom Co., Ltd. All Rights Reserved. おまけ2:Jenkins運用 ● Jenkinsサーバ構築自体もitamaeで行ってる ○ コマンド1つで必要なミドル一式(jenkins, nginx, vagrant, packer, virtualbox辺り)全部入るようになってる ● webから設定する部分(インストールしてるプラグインとか)は 全部社内confluenceにまとめた ● バックアップ ○ 1日1回 https://github.com/sue445/jenkins-backup-script を定期実 行して設定やプラグイン一式をtarに保存 ○ tarを物理的に別の所にあるバックアップサーバに転送 ○ Jenkinsマシンがいつ死んでもすぐに復旧できるようになってる ○ Jenkins本体やプラグインのアップデート前にバックアップしておくとす ぐに戻せて安心
  39. 39. Copyright Drecom Co., Ltd. All Rights Reserved. 最後に ● 複数のクラウドに対するインフラCIの事例はあまり見ないの で、参考になったら幸いです

×