ひよっこSREがHashiCorp Meetupに参加してきたお話し

インフラエンジニアの寺岡です。
社内ではSREチームに所属して、インフラの設計/構築/運用を一貫して担当しています。
ちなみにSREは一般的に言うと「Site Reliability Engineering」の略ですが
弊社では「サイトのみじゃなくてサービス全体を見てるよね」ということで
「Service Reliability Engineering」と呼ぶようにしています。

今回はHashiCorpのMeetupに参加してきたお話しです。
DevOpsを支える今話題のHashiCorpツール群について
会場が東京の渋谷ヒカリエだったのでプチ旅行でした。
大阪から新幹線だと何だかんだ3時間くらいかかるのでやっぱり遠いですね。。。
次は大阪でも開催してくださるのを陰ながら心待ちにしています！

■感想の箇条書き

• 生ハムとビールは至高
• ミッチェル・ハシモト氏はダジャレ好き(HashiCorpとかけて箸をプレゼントしてました)
• Terraform使っている人約8割
• Packerは約4割
• Cousul/vault/nomadはまだ使っている人少なそう
• Consul Connect気になる(サービス間の通信を暗号化できる)
• sentinel(Configuration as Code)使ってみたいからOSSで出してほしい！

DeNA様の差し入れで生ハムとビールが用意されていたのですが美味しかったです。

生ハム原木も差し入れ頂きました！ pic.twitter.com/gkvdEB20zK

— HashiCorp Japan (@hashicorpjp) September 12, 2018

ミッチェル・ハシモト氏のダジャレの話が面白かったです。
有言実行で会場で箸を配ってたので参りました。

技術面で言うとTerraformの普及率が凄まじいです。
使ったことある人？という質問に殆どの人が手を挙げていました。

Packerはようやく半分くらいかな？というところでしたが
マシンイメージを管理する上でのベストプラクティス的なツールだと
個人的に思うので使えるようになっておくべきです。

弊社ではTerraform/Packerは一部使っている案件があるといった程度なので
まずはコードをモジュール化して共通化することで仕組みを整えつつ
導入していないツールはConsulの導入検証から始めないとなあ。。。と思いました。
ということで登壇された方の内容を書いていきます。

■AI＆分析基盤で活躍！HashiCorpProducts

株式会社ディー・エヌ・エー システム本部 AIシステム部 松木 秀憲 様

・AI＆分析基盤のインフラを担当
・AI研究開発エンジニアが容易に自由に開発できるインフラの構築/運用を行っている。
・AI＆分析基盤インフラの課題をHashiCorpのツールを使って解決する

AIインフラ

AIのプロジェクトには2～3人の小規模なプロジェクトが複数存在している。
それぞれがAWS及びGCPを利用して機密性の高いデータや、膨大なデータ量を扱うため
各プラットフォーム別のインフラをすばやく用意する必要がある。

AIインフラの課題解決

・Terraformの利用
　・インフラのプロビジョニングツールとしてTerraformを利用
　・インスタンスの起動をTerraformで行い、ミドルウェアのインストールはitamae
　・インスタンスはツールによって簡単に構築できるようになった
　・GPU搭載インスタンスを起動して機械学習インフラを構築

・Packerの利用(案)
　・AIインフラのDocker化を進めている
　・Packerを利用してAWS/GCPのDockerリポジトリで管理できるようにしたい
　・PackerもHCLで書きたい(わかりすぎて思わず頷いてしまいました。。。)

分析インフラ

・fluentdでサービスのログを収集
・収集したログをhadoopで分析
・結果をembulkでBigQueryに投入
・ArgusDashboardから可視化
・Hadoopのバージョンアップが辛い。。。
・分析基盤はそもそも検証することすら大変

分析インフラの課題解決

・Vagrantで分析基盤の検証をやってみる！
・でもやっぱり大変。。。(残課題らしいです)

所感

・マルチプロバイダなTerraformは要件に非常に合っていると思った。
・Terraformのprovisionerを使わないことは共通してた(弊社はitamaeではなくansibleですが)
・PackerもHCLで書きたいというくだりは同意しかなかった

■コンテナ基盤を支えるHashiCorpソフトウェア

GMOペパボ株式会社 技術部技術基盤チーム プリンシパルエンジニア 小田 知央 様

ロリポップ！マネージドクラウドとは

・コンテナベースのPaaS
・運用付きのクラウドでクラウド寄りのレンタルサーバ
・コンテナの負荷に応じて動的にスケールする
・k8sやDockerは使っていない
・Oohori/FastContainer/Haconiwaという独自コンテナ環境を使っている
・全て独自開発したもの(golangで開発)

なぜ独自開発して使うのか

・安価なコンテナ環境の提供にコンテナが高集積である必要がある
・ユーザ管理のコンテナが継続的に安全である必要がある
・コンテナリソースや権限に対して柔軟な設定が可能であることと、それらが能動的である必要がある（コンテナ自身が動的にリソース変更）
・要するに要件を満たすために必要だった！

全体的な特徴

・OpenStackとBaremetalのハイブリット環境
・Packerで作るイメージは最小限で全ロール共通化して使用
・TerraformのProvisionerは使わずKnife-Zeroを使う
・開発環境はVagrant
・頻繁に発生する大きな仕様変更とステートレスなロールが多いことからImmutable Infraを捨てる戦略

Terraform

・可能な限りmoduleで再利用できるようにしている
・tfstateはやっぱりS3で管理
・workspaceはProductionとStagingで利用
・lifecycleの設定は事故防止に必須
・CIでfmtするようにしている

Consul

・メインはサービスディスカバリ
・外形監視かサービス監視かでMackerelと役割分担
・Consulの内部DNSとUnboundで名前解決
・Vaultのストレージバックエンドとしても利用
・全ノードにConsulAgent/PrometheusのConsul/node/blackbox exporterが入っている
・踏み台サーバでConsulで名前解決することで多段SSHが便利になる
・ProxyのUpstreamをCounsul DNSでラウンドロビン出来る

vault

・PKIとTeansitシークレットを利用
・DBに保持する秘密情報を全てVaultで暗号化
・発行した秘密情報はChefで配布
・TokenはTTLを延長しながら使用
・max-lease-ttlの期限で失効する

PKIのRootCA配布問題

VaultサーバにTLS接続する場合どうすれば良いか
・Consulをストレージとして利用するとアクティブなVaultに対してvault.service.consulが自動的に設定される
・Vaultは認証局として設定しサーバ証明書を自分で発行する
・Vaultは再起動するとSealされる

Consule Templateの使用2

・vaultにSIGHUPシグナルでサーバ証明書を再読み込みする
・SIGHUPではSealされない
・Audit logのlogrotateにも使える
・vaultが発行したRoot CAはChefで配布

Application Tokenの配布問題

・ApplicationがVaultに対して認証するapprole
・認証すると指定のTTLが指定されたTokenが発行される
・ApplicationはTokenを使ってVaultとやり取りする
・Applicationがapproleのrole_idとsecret_idを持っていても意味がない
・Applicationプロセスの外でTokenを発行する

Application Tokenの配布問題解決法

・Applicationのデプロイ時にapprole authをするコマンドを実行
・コマンドは認証のPWであるsecret_idのTTL延長をPOST
・続けて認証を実行しTokenを取得する
・取得したTokenをApplicationが読めるパスに配置

Vault Tokenが失効して障害

・Approleのsecret_idをrenewするためにcustom secret_idとして設定している
・custom secret_idに設定するtokenはauth/tokenで発行
・マウントしたsecretごとにmax-lease-ttlという設定があり、システム全体にもmax ttlが存在する
・両方が未設定の場合、システムのmax ttlである32daysが上限
・Tokenが失効したらaudit.logに403エラーが頻発していた
・Vault serverのConsul checksでaudit.logの監視を追加
・検知したものはConsul AlertでSlackに通知

所感

・k8sやDockerを使わずに独自開発しているのがすごい
・TerraformのProvisionerは使わない、他の構成管理ツールを使っている会社がやはり多い
・tfstateはbackendを記述してS3で管理するのが安定
・lifecycleの記述を普段使わないので覚える必要があると思った
・踏み台からの多段SSHは担当している案件でもあるのでConsulを使ってみたい
・vaultは正直よくわからず、、、勉強不足なので覚えなおしです。。。

■applibotのDevOpsを支えるterraform/packer

西村 遊 様,　株式会社アプリボット（サイバーエージェントグループ）
企画・開発Div.　システムオペレーションエンジニア

・チーム＝1アプリケーション毎にカンパニー制
・SYSOP(サーバ環境を用意する人)は2人しかいない！
・SYSOPはアプリケーションチームのサーバエンジニアと協力することが多い
・terraform/packerを使って過去にあった課題を解消したお話

Case1 Image作成

・RUNDECK/Ansible/Packerを使っている
・Ansibleと併用してマシンイメージの作成を行う
・メリット：イメージ作成の流れをテンプレート化できる

・Before
　・AMIからEC2起動
　・Ansibleで構成変更を適用
　・イメージ取得したサーバの削除
　・を全て手動で実行

・After
　・packer buildコマンドで一発

Case02 負荷試験構築

・terraform/hubotを使っている
・SYSOPは負荷試験を行う環境の構築/構成変更/レビューを行う

・インフラ周りで用意するもの
　・最終的に、本番同等の環境
　・試験のタイミングで作成する
　・本番同等規模で維持するとコストがかかるため試験の度に作成する
　・試験期間中でも使わないときは小さく
　・負荷をかけるサーバ
　　・Jmeterを利用、ネットワークとアカウントを別にしている。
　　・master-slave構成。slaveはAutoScalngでスケールする
　　・試験の度に作成、使わないときは削除
　・各種モニタリング
　　・grafana/prometheus/kibana+elasticsearch

・Before
　・管理インスタンス分のawscliをごりごり
　・起動順番はスクリプトで調整
　・出来上がる秘伝のタレ
　・sysop側で毎朝・毎晩の拡張・縮小対応

・After
　・構成要素は全てterraform化
　・すでにあるリソースはterraform importで対応
　・どうしても整合性が合わない場合はtfstateを直接修正
　・起動管理の集約ができた
　・terraformのコードを見れば構成がわかる
　・作成もスケールもterraform applyで実行できるように
　・depends_onで構成順序を指定する
　・インフラの縮小拡張はvarsを切り替える
　・slackの通知のみで全てが完結するようになった

Case3 新規環境構築

・terraform/gitlabを使っている

・Before
　・rootアカウントの封印
　・Consolidated Billing設定
　・IAMUserの作成、グループ作成、スイッチ作成
　・CloudTrail/log用のS3バケットの作成
　・ネットワーク設定、監視用ポート開け

・After
　・アカウント自体の設定管理ができるようになった
　・rootアカウントの封印
　・Consolidated Billing設定
　・terraform用IAMユーザー作成
　・terraform実行でOK
　・設定変更もMergeRequestで管理可能

・定型作業はテンプレ化大事！！

所感

・Packer + Ansibleでマシンイメージを作成するのは本当に便利
・Packerでマシンイメージを作成しつつ、Ansibleで実行するコマンドの構成管理が可能
・Ansibleの他にもPackerではシェルスクリプトの実行も可能
・負荷試験環境の構築は弊社でもterraformを使って構築できるようにしているので参考になった
・hubotを使ったチャットへの通知はやっていなかったので取り入れてみたい
・新規環境構築時に必要な処理は全てmodule化しているみたいなのでいろいろ参考になった

■tfnotify - Show Terraform execution plan beautifully on GitHub

b4b4r07 様,　株式会社メルカリ　ソフトウェアエンジニア

tfnotifyとは？

・Go製のCLIツール
・Terraformの実行結果をパースして任意の通知先へ通知する
・terraform apply | tfnotify applyというようにパイプして利用する

なぜ必要？

・Microservices領域でTerraformを利用している
・Ownershipの観点からレビューマージは各MicroservicesチームによってされるべきだがPlatformチームにレビューされたいケースもある
・Platform/MicroServicesチームでIaCの重要性を理解してTerraformでコード化して実行計画を毎回見ることを習慣づけたい
・CIの画面を見に行く手間を省きたい(GitHub上でクイックに確認したい)

メルカリでのHashicorpツール

・70以上のMicroServicesがある
・全てのMicroServicesとそのPlatformのインフラ構築はTerraformを利用
・開発者にもIaCを実践してもらう
・tfstateの数140個
・一つの中央レポジトリで全てのTerraformコードを管理している

リポジトリ構成

・各MicroServicesごとにディレクトリを分ける
・Serviceごとにtfstateを分ける
・Resourceごとにfileを分ける
・CODEOWNERSで権限委譲

権限委譲

・GitHubの機能
・CODEOWNERSに記載された人からApproveされるまでマージ出来ないようにできる
・勝手に変更できないようにしている

tfnotifyの実装

・io.TeeReaderを使っている
・Terraformの実行結果は自前のパーサで構造化する
・POSTするメッセージはGoのテンプレートで書くことができる
・設定はYAMLで持つ

所感

・Terraformは中央レポジトリで管理、Gitでのコード管理をどうしようか悩んでいたので参考になった
・tfnotifyがGitlabCIとチャットワークに対応してくれるとなお嬉しい
・開発者にもIaCを実践してもらうことが大事、Terraformの実行計画は毎回しっかり確認することが大事
・GithubのCODEOWNERS機能を使ってみたい(まずはgithubに移行したい。。。)

dwangoでのHashiCorp OSS活用について

鈴木 栄伍 様,　株式会社ドワンゴ　第二サービス開発本部　Dwango Cloud Service部
Consultingセクション　第二プロダクト開発部　第一セクション

dwangoのインフラ

・VMware vSphere
・AWS
・ベアメタル
・その他一部Azure/OpenStackなど

dwangoでのHashiCorpツール

・Packer
　・Vagrantのbox作成に利用
　・AWS環境が増えたためAMI作成にも利用
　
・Consul
　・ServiceDiscoveryとして利用
　　・MySQLサーバがダウンしたときにアプリケーションの設定ファイルを書き換え
　・KVSやhealthcheckとして利用
　・Ansible playbookのdynamic inventoryとして利用
　
・Terraform
　・AWS環境の構成管理として利用
　　・ニコニコアンケート、friends.nico、ニコナレ、N予備校の一部などで利用

TerraformでのCI(利用ツール)

・github
・Jenkins
・Terraform
・tfenv

TerraformでのCI(流れ)

1.PRが出る
2.Jenkinsでpr_test環境をplan -> apply -> destroy
3.2が通ったらsandbox環境にplan -> apply
4.全て通ったらmergeする

TerraformでのCIでうれしいこと

・github上でapplyが成功したか失敗したかがわかる
・環境の構成をdev/prodにしているので、applyが安全に行えることを事前に確認できる
・tfenvによってterraform自体のバージョンアップ時の確認が容易に行える

TerraformでのCD

・CIが通ったらdevなどに自動でデプロイしたい
・Jenkinsでジョブ化して安全に行えるようにしている
・誰が作業しても基本的に問題なくデプロイできるようになった
・Slackで結果が通知されるのでお手軽に確認できるようになった

所感

・AMIの作成はやっぱりPackerが便利
・Ansibleを弊社でも利用しているのでConsulをdynamic inventoryとして利用してみたい
・tfenvのバージョン切り替えは便利
・terraformはplanが通ってもapplyでエラーになることがあるのでpr_test環境に対してデプロイするのは良い方法だと思った
・CDはやっぱりJenkinsおじさん。コマンドを直接実行するよりもジョブ化しておいた方が楽だし確実

。。。以上、ほぼ箇条書きですがまとめです。
弊社でもIaCを実現するためにHashiCorpのツールを積極的に使っていきたいです！