ドリコムのインフラCI

Copyright Drecom Co., Ltd. All Rights Reserved.
sue445
2016/12/01 ドリコムAdventCalendar
ドリコムのインフラCI

● Go Sueyoshi a.k.a sue445
○ Ruby歴 4年半
○ golang歴 2年
○ Go歴 34年（34歳）
● 株式会社ドリコム　インフラストラクチャー部所属
○ インフラチームは全部で数人
○ 社内ツールや社内ライブラリを中心に、サーバサイド全般をアプリから
インフラまで浅く広く
○ 良く言えば「フルスタックエンジニア」、悪く言えば「ワンオペエンジニア」
● 「ドリコムのプリキュアの人」として社内外で有名
自己紹介

【宣伝】ドリコムについて
● http://www.drecom.co.jp/
● スマホゲームと広告配信サービスを開発・運用している会社
● 社員数280名
● ゲームはRuby + Ruby on Rails、広告はElixir + Phoenix

Agenda
● インフラCIとは？
● 弊社のインフラCI
● 使ってるツールの紹介
● Jenkinsのジョブ
● インフラCIのハマりどころ
● おまけ

インフラCIとは？
● インフラ環境をCIすること
○ よくある例）PullRequestで検証環境にプロビジョニングを
実行し、問題なければPullRequestをマージ、自動的に本
番環境にも同じプロビジョニングが実行される
● 詳しい資料
○ インフラの継続的デリバリー - naoyaのはてなダイアリー
http://d.hatena.ne.jp/naoya/20140821/1408577976
○ インフラ系技術の流れ - Gosuke Miyashita
http://mizzy.org/blog/2013/10/29/1/
● 弊社のケースは若干違う（後述）

弊社のインフラCIでやってること
● ゴール
○ 特定のアプリに依存しない全社基盤のイメージを作成
○ 必要に応じてアプリ固有のレシピも適用してイメージを作
成
● Jenkinsで行っていること
○ PullRequestやmasterブランチをAWSなどにプロビジョニ
ングを実行（開発ビルド）
■ 自動実行
○ masterブランチをAWSなどにプロビジョニングを実行し、イ
メージの作成（イメージビルド）
■ インフラチームによる手動実行

インフラCIの全体像（開発ビルド）
社内Jenkinsサーバ
ソースをclone
JenkinsがVagrantで
AWSなどにVMを立て
て、itamaeのレシピと
Serverspec実行

インフラCIの全体像（イメージビルド）
ソースをclone
packerでitamaeとServerspecを実行
して、問題なければイメージ（ AMIや
テンプレート）を作成する
社内Jenkinsサーバ
AMI
テンプレート

使っているツールの紹介

使っているツール：itamae
● http://itamae.kitchen/
● クックパッドの中の人が作ったプロビジョニングツール
● Ruby製でChefの軽量版
● 日本人が作ったということもあり、国内だと割と使われている
○ 日本語で質問できるのもメリット
○ 海外からのissueやPRも見るので海外で全然使われてい
ないってわけではなさそう
● 自分で作ったレシピをgem（Rubyのライブラリ）にして
rubygems.org（gemのホスティングサイト）で配布することもで
きる

サンプルコード
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

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で作成

itamaeを導入した理由
● vs Chef
○ ChefはRuby製だけどRuby以外に覚えること（Chefの独
自ルール）が多くて初見だと学習コスト高そうだった
○ itamaeは普通のRubyのgemでRubyを知っていれば他に
覚えることは少ないのでアプリエンジニアにもとっつきやす
い
○ 当時6人中3人がitamae使えたのでチーム内で教えれば
なんとかなるだろうという思い
● vs Ansible
○ 検討材料としては挙がったけど、Ruby書ける人が多かっ
たので流れでitamaeになった

使っているツール：Serverspec
● http://serverspec.org/
● RSpec（Rubyのテスティングフレームワーク）をベースにした、
インフラ構成をテストするためのツール
● インフラ構成のテストをするツールだとこれがデファクトスタン
ダード
● itamaeで実行したプロビジョニングが本当に設定されてるかど
うかの検証をしている

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
サンプルコード

使っているツール：Vagrant
● https://www.vagrantup.com/
● HashiCorp社が作った仮想環境の構築ツール
● VirtualBoxやAWSなどを同一インターフェースで扱える
● プラグイン導入することでいろんな環境で使える

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放置されてる(´・ω・｀)

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

使っているツール：Packer
● https://www.packer.io/
● HachiCorp社が作った、複数プラットフォームでイメージを作
成するツール
● プラグイン導入することでいろんな環境で使える
● packer buildでやってること
○ 1. イメージを作りたい先のクラウドにVMを作成
○ 2. 予めgit archiveでtar.gzに固めておいたローカルのレシ
ピをVMに転送
○ 3. VM内でtar.gzを展開してレシピとテストを実行
○ 4. 問題なければイメージを作成

プロビジョニングの構成
● 1つのVMに対してitamaeを2回実行している
● 1回目：イメージ作成時
○ role(サーバの役割)に関わらずpackageは全てインストー
ルする
● VM作成してクラウドのコンソールからタグを付与
● 2回目：VM再起動時
○ VM起動時に2回目のitamaeを実行するためのsystemd
serviceを実行
○ 自分自身に付与されたタグ情報を取得
■ roleに応じてserviceを起動（例：dbロールであれば
mysqlを起動）
■ タグにアプリ名が含まれていればアプリ固有のレシピ
を実行

開発ビルド用のジョブ
● マルチ構成プロジェクトにして、1つのジョブで同時に複数ビル
ドが実行できるようにしてる
● Jenkins 2.0の新機能のpipelineを使いたいけど、複数のジョ
ブのコンソールログが1ヶ所になって混ざってしまうので移行は
してない

縦の軸はどのクラウドに対してプロビジョニングをするかどうか
● 対応するVagrantプラグインをインストールして
● vagrant up --provider=$PROVIDER みたいな感じで実行
$
P
R
O
V
I
D
E
R

横の軸は使用するnodeファイル（設定ファイル）
● リポジトリにコミットしてるのはdefault.yml（role全無し）だけだ
が、ビルド時にrolesを全部付与したyml（role_all.yml）を生成
してビルドを実行することにより、role全有り、全無しを両方テ
ストしてる
$NODE

イメージビルド用のジョブ
● プルダウンでパラメータを切り替えている
● 弊社だとサービス単位（費用が発生する請求単位）で AWSや
IDCFのアカウントが複数分かれているので、作成先のアカウ
ントを選択できるようにしてる
○ クラウドによってはアカウント間でのイメージ共有ができる
ので不要なんだけど念のため

● パラメータが多いけど、Rebuilder Pluginで一度使ったパラ
メータを使いまわせるようにしてるので2回目以降はそんなに
大変ではない
○ https://wiki.jenkins-ci.org/display/JENKINS/Rebuild+Pl
ugin
● イメージ作成に成功したらgitのtagを作り、かつイメージにも
tagと同じ名前をつけることにより、イメージからどの時点の
ソースコードを元にビルドしたかが特定できるようにしてる

git tags
AMI

インフラCIのハマりどころ
1. ビルドが遅い
2. たまにビルドが落ちる

1. ビルドが遅い
● VMの起動に1〜2分
● itamaeを全部流し切るのにローカル実行で20分くらい、AWS
のc3.largeで10分くらい
● Serverspecの実行は数分
● 解決策は金の弾丸で殴るしかなさそうｗ

何が遅いのか調べる
● itamae実行時に --profile をつければコマンド単位の実行時
間をjsonで出力してくれる
● jsonをparseして処理時間が長いものを抽出
● ワーストランキングを出力するスクリプト
○ https://gist.github.com/sue445/96058bd109601b58f5a
81b826949135f

調べた
● 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

＿人人人人人人人＿
＞　yum install　＜
￣Y^Y^Y^Y^Y^Y￣

なぜ遅いか考察
● rpmの取得と、取得したrpmをローカルにインストールする部
分のどっちが遅いかまでは検証してない
● packageを全部インストールした状態でイメージ化しておい
て、roleによってserviceの起動のみを切り替えるというのは理
にかなってそう

2. たまにビルドが落ちる
毎回2 x 3通りもテストをやってると1つだけビルドが落ちることが
たまによくある（インフラCIガチャ）

インフラCIのビルドが落ちるケース
● VM起動に失敗
● rsync中に固まる
○ 無限に止まるので他のジョブに影響するのでタイムアウト
30分に設定
○ https://wiki.jenkins-ci.org/display/JENKINS/Build-timeo
ut+Plugin
● AWSスポットインスタンスの価格高騰で起動に失敗
○ $0.04に設定していればほぼ安全圏だけど、たまに$1超え
るｗ
○ 高騰していないスペックやアベイラビリティゾーンを変えて
回避

インフラCIのビルドが落ちるケース
● レシピ実行中にプロセスが突然死ぬ
○ 何回実行しても再現するので調べたら、一部コマンドの標
準出力への書き込みをやめたらプロセスが死ななくなった
● rikenが調子悪くてyum install失敗
● いずれの場合も失敗した内容によって偶然落ちたビルドなの
でスルーするかどうか判断する必要がある（つらい）
● コンソールログの内容を見て判断する必要があるので、失敗
した時のために可能な限りログは全部出しておく

おまけ1：テスト駆動インフラ
アプリ開発でよく使われるTDD (Test Driven Development = テ
スト駆動開発) をインフラにも適用することができる
1. インフラの確認項目をServerspecでテストを書く
2. 期待したエラーが出ることを確認 (Red)
3. サーバで適用したいitamaeのコードを書く
4. テストが通っていることを確認 (Green)
5. ダメなら3に戻る
6. 必要ならリファクタリング (Refactoring)
● VagrantとVirtualBoxを使うと手軽にVMを作り直せるのでイン
フラTDDしやすい

テスト駆動インフラでも黄金の回転を
http://www.slideshare.net/t_wada/the-spirit-of-tdd/27

おまけ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本体やプラグインのアップデート前にバックアップしておくとす
ぐに戻せて安心

最後に
● 複数のクラウドに対するインフラCIの事例はあまり見ないの
で、参考になったら幸いです

ドリコムのインフラCI

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à ドリコムのインフラCI

Similaire à ドリコムのインフラCI (20)

Plus de Go Sueyoshi (a.k.a sue445)

Plus de Go Sueyoshi (a.k.a sue445) (16)

Dernier

Dernier (9)

ドリコムのインフラCI