ドリコムのインフラCI

2016年12月1日公開 2021年6月24日更新

自己紹介

こんにちはインフラストラクチャー部のsue445（末吉）です。

ドリコムのインフラストラクチャー部は数人いて、そのうち僕はサーバに関係することはアプリからインフラまでだいたいやってます。

良く言えば「フルスタックエンジニア」で、悪く言えば「ワンオペ」ですｗ

今はレガシーな社内アプリのリプレイスをやっています

先日とある勉強会に誘われてしゃべる機会があったので、その時のスライドを公開したいと思います

ドリコムのインフラCI from Go Sueyoshi (a.k.a sue445)

表紙以外は当日使ったのと全く同じです

スライドに書ききれなかった補足情報です

AWSではタグ、IDCFではユーザデータとして、VMに対して任意のデータを設定できますが、下記のようなものを利用しています

名前	説明	備考
env	本番かステージングなど	production, staging など、おおよそRailsアプリであればだいたい `RAILS_ENV` に対応しています
service	サービス名
roles	インスタンスの役割	*(1)**
daemons	起動したいcollectdのdaemonの種類	memcached, mysql, nginx, redis, unicorn *(2)**
numbering	ナンバリング	01-01, 01-02
consul_server_addr	consul serverのIPアドレス	11.22.33.44

(*1)

: roleの種類
- web : nginxをインストールしてユーザからのリクエストを受けるrole。弊社ではこのwebサーバでRailsアプリが動いています
- db : MySQLでデータを永続化するrole
- cache : memcachedなどキャッシュ用途のrole
- kvs : redisを動かすrole
- job :
  
  Sidekiq
  
  のジョブを動かすrole。nginxが動いていない以外はwebと構成は同じ
- all : web + job + db + kvs + cache のオールインワン（全部入り環境）です。ステージング用のアプリや小さい社内アプリなどでよく使われる
- consul_server : consul serverを起動するrole
- build : stretcherでデプロイする時に
  bundle install
  や
  assets:precompile
  を実行してアプリをtarに固める環境
(*2)

: daemons
- memcachedやunicorn用のcollectdの設定ファイルを配置することでメトリクスを社内の監視サーバに送信しています

service, env, roles, numbering, 自分自身のIPアドレスを組み合わせることでhostnameをレシピで設定しています

例）app1-web-01-01-11x22x33x44, app1staging-db-12x34x56x78
productionをhostnameに含めていないのは、ほとんどのサーバが本番サーバにあたるのでわざわざつける必要がないため
serviceとenvの間にハイフンがないのは、productionをhostnameに含めないルールだとserviceとenvの間にハイフンを入れると別の監視ツールでsplitした時にproductionかそれ以外かで場合分けが必要になるため

当初は1回のitamaeの実行で全てのプロビジョニングが完結するようにしていたのですが、

serviceやroleはサービスインする時に初めて付与するものなので、CI実行時には自分がどのserviceやroleを付与されているか分からない
itamaeを1回にするとロール毎にイメージを作成する必要があるが、それだとイメージが大量に作られて管理が大変になる
- roleが1つだけならいいんだけど、web+job, kvs+cacheなどの組み合わせとかも考慮すると必要なイメージが無限になる

ため、管理するイメージをなるべく少なくするためにこのような仕組みにしました。（作成時期によってイメージはいくつも作られるが、最新のイメージは常に1つ）

またタグを付与してイメージ起動する時にsystemdでitamae-bootstrapというserviceを実行して2回目のitamaeを実行されるようになっていますが、一度タグを付与して起動してしまえばそれ以降は再起動してもitamae-bootstrapが実行されないようになっています。

手動でタグを付与するのはサーバを最初に作る1回だけなのでそんなに手間ではないです。（だいたいが社内アプリや開発サーバなどサーバの台数が増減しないサーバ）

本番環境に投入されているアプリはオートスケーリング時に自動的にタグを付与しているので人間が頻繁にタグを設定しているということはないです。

弊社では下記のようなディレクトリ構成でレシピを管理しています

ルートの bootstrap.rb を起点にitamaeを実行
- 実行順は上のディレクトリ図の順番（cookbooks/system/ -> cookbooks/service/）
system配下、servoce配下のディレクトリを名前順に自動で
include_recipe
して実行
実行したいレシピは基本的に順番に依存しないようになってるが、どうしても実行順を制御したい場合はディレクトリ名に
00-
,
10-
などをつけることにより先に実行している
apps/ 配下に、アプリによって個別に適用したいレシピを配置
- アプリ名はタグのserviceから取得している