DeNAさんのオフィスで行われたHashiCorpJapan Meetupに参加してきました。
発表を聞いて参考になった箇所をピックアップしていきます。
対象となるツールは次の6種類ですが、Terraformに関する内容が多いです。
発表資料はこちら
DevOpsを支える今話題のHashiCorpツール群について
Consul
- あるサービスが別のサービスと通信する場合に、通信相手を見つける（サービスディスカバリ）機能を提供するツール
- Consulにサービスを登録することでサービスイン、Consulが障害を検知するとサービスアウト
- Consul Connectという機能ではサービス間の通信を透過的にTLSで保護することが可能
WebサーバとDBサーバといったサービス間の依存を疎結合にできそうな印象がありました。
Packer
- DockerイメージやAWSのAMIを作成するためのツール
- イメージの構成管理にはAnsibleを組み合わせることも可能
仕事でAMIの管理をどうするのが良いのか探していたので、ちょうど良いものが見つかりました。
導入予定です。
TerraformのCI/CD
- 毎回削除するテスト用の環境でplan, apply, destroy
- 削除はしないサンドボックス環境でplan, apply
- ボタンを押すと本番環境にapply
Terraformのテストってどうするのが良いのかって思っていましたが、基本はterraform planを自動化するんですね。
ボタン1つでterraform applyは便利さもありますが、terraform用の機密情報を個々の開発者が持つのではなく、デプロイ用のサーバで一元管理できるのが魅力に思いました。
Terraformのディレクトリ構成
- Workspaceによる環境の分離は少数、production、developmentといったディレクトリを作る方法が多数
自分もWorkspaceは使わず、環境ごとのディレクトリを分けて運用しています。
全サービスのTerraformコードを1リポジトリで管理
- 目的はCIの設定コスト、レビューのコストを下げるため
- リポジトリの中ではサービスごとにディレクトリを分ける
- 各サービスのディレクトリはGitHubのCODEOWNERSで権限を管理
1リポジトリで管理するメリットは、同じリポジトリで再利用可能なmoduleを作って簡単に参照できることもあるのかと思いました。（Privateリポジトリのmoduleを参照するって有償版でないとできないんでしょうか？）
CODEOWNERSは初めて知りましたが便利な機能ですね。
クラウドのアカウント管理
- サービスごとにアカウントを分けていることが多い
- 煩雑なアカウントの初期設定はTerraformで自動化している
単純にAWSのアカウントってどの単位で分けているのか気になってました。
サービスごとに分ける理由は他のサービスへの影響をなくすためかな？
最後に
製品の紹介ではなく、運用で得た知見が詰まった活用方法の発表だったので業務に活かせる内容が多かったです。
イベントで生ハムの原木と生ビールが出てくるDeNAさんの福利厚生は素晴らしい。