Slide 1
Slide 1 text
PHPerもIaCを使おう！
17年物のインフラをTerraformに大移行
At: PHPカンファレンス福岡2023
Speaker: Kensho Iwashita
Slide 2
Slide 2 text
自己紹介
名前： 岩下 拳勝
Twitter, GitHub： iwashi623
担当業務： バックエンドエンジニア（PHPer）
趣味：プロ野球観戦（阪神ファン）
AWSの資格取得（SAA/SAP/SOS/DVA）
Slide 3
Slide 3 text
注意
● 本発表はIaC導入のメリットや、Terraform導入時の心構え、チョットしたTipsを話す発表です。
○ オンプレインフラを一気に「クラウド × Terraform」化した具体的な手順やコードなどは一
切出てこないので悪しからず。
● IaC運用の具体的なルールは各社毎に異なりますので、先輩や偉い人の言うことを聞いてくださ
い。
● 現在自分が経験してきた中でこれはTerraform運用に必要だな〜と思うことを話します。数年
（下手したら数日）後には変わることがあることをご承知おきください。
Slide 4
Slide 4 text
はじめに
突然ですが、PHPerの皆さんは普段からインフラ構成の変更をしていますか？
Slide 5
Slide 5 text
Webアプリケーションエンジニアがインフラに触れるメリット
会社目線
● チームの開発・改善の効率性が向上
○ 自チームに必要なインフラを一番良くわかっているチームメンバーが、自分たちでインスタンス追加・配置変更などができるようになる
。
→ 組織のコミュニケーションコストやタスク調整の工数が減少する。
個人目線
● スキルの向上
○ Webアプリケーションの開発力向上 だけを行っていてもどこかで成長の波が鈍化する。（パレートの法則）
■ 偏差値30 -> 50より、50 -> 70の方が難しいのと同じ
■ 偏差値50くらいのインフラ知識があれば、QiitaやZennの記事を読んだときにもっと分かることが増える気がする！
● 市場価値の向上
○ （ぶっちゃけ）クラウドが広がったおかげもあり、インフラスキルの汎用性が上がったので転職も容易なのでは？
私の主張：PHPerもインフラ触っていこうぜ！
Slide 6
Slide 6 text
反論
● 「触ることができるならお前に言われなくても…！」
○
● 「インフラってなにからしていいのかわからない！」
○
● 「うちのインフラを見てみろや！飛ぶぞ！」
○
Slide 7
Slide 7 text
反論
● 「触ることができるならお前に言われなくても…！」
○ わかります、PR TIMESがオンプレ時代の私もそうでした
● 「インフラってなにからしていいのかわからない！」
○
● 「うちのインフラを見てみろや！飛ぶぞ！」
○
Slide 8
Slide 8 text
反論
● 「触ることができるならお前に言われなくても…！」
○ わかります、PR TIMESがオンプレ時代の私もそうでした
● 「インフラってなにからしていいのかわからない！」
○ わかります、まずはマネコンにログインしましょう
● 「うちのインフラを見てみろや！飛ぶぞ！」
○
Slide 9
Slide 9 text
反論
● 「触ることができるならお前に言われなくても…！」
○ わかります、PR TIMESがオンプレ時代の私もそうでした
● 「インフラってなにからしていいのかわからない！」
○ わかります、まずはマネコンにログインしましょう
● 「うちのインフラを見てみろや！飛ぶぞ！」
○ 👼
Slide 10
Slide 10 text
実例紹介
● PR TIMESは、以前はオンプレミスのデータセンターにあるサーバーにデプロイされていました。
○ この時代のインフラはドキュメントも満足に揃ってない
○ 構成変更や拡張をしたくてもその都度色々問題が噴出する状況
Slide 11
Slide 11 text
実例紹介
● PR TIMESは、以前はオンプレミスのデータセンターにあるサーバーにデプロイされていました。
○ この時代のインフラはドキュメントも満足に揃ってない
○ 構成変更や拡張をしたくてもその都度色々問題が噴出する状況
ぼく「ドキュメント… ドキュメント…」
Slide 12
Slide 12 text
実例紹介
● PR TIMESは、以前はオンプレミスのデータセンターにあるサーバーにデプロイされていました。
○ この時代のインフラはドキュメントも満足に揃ってない
○ 構成変更や拡張をしたくてもその都度色々問題が噴出する状況
ぼく「ドキュメント… ドキュメント…」
先輩「そんなもんあるわけないじゃないですかｗww」
Slide 13
Slide 13 text
実例紹介
● PR TIMESは、以前はオンプレミスのデータセンターにあるサーバーにデプロイされていました。
○ この時代のインフラはドキュメントも満足に揃ってない
○ 構成変更や拡張をしたくてもその都度色々問題が噴出する状況
ぼく「ドキュメント… ドキュメント…」
先輩「そんなもんあるわけないじゃないですかｗww」
ぼく「なにわろとんねん」
Slide 14
Slide 14 text
実例紹介
そんな状況なのでみんなで頑張ってAWSに移行しました
● 移行時にTerraformも頑張って導入しました。
○ EC2、RDS、CloudFront、VPCなど...
○ インフラの全貌がつかみやすくなる
● 導入した人たちがTerraformを使っていくと、段々と組織内に拡大、定着していった。
○ 作業の影響範囲が見える化されて、構成変更への謎の恐怖がなくなったことが要因
Slide 15
Slide 15 text
実例紹介
そんな状況なのでみんなで頑張ってAWSに移行しました
● 移行時にTerraformも頑張って導入しました。
○ EC2、RDS、CloudFront、VPCなど...
○ インフラの全貌がつかみやすくなる
● 導入した人たちがTerraformを使っていくと、段々と組織内に拡大、定着していった。
○ 作業の影響範囲が見える化されて、構成変更への謎の恐怖がなくなったことが要因
新卒の若手が9割の20人規模（当時）の組織でもTerraform化できた！
Slide 16
Slide 16 text
本トークの対象者と目的
対象者
● IaCというかっこいいものが流行っているのは知っているけど触れていない方
● 「IaCのメリットはわかっているけど、うちには導入できない！」と思っている方
● なんとなく、インフラを触ってみたいけど二の足を踏んでしまっているビギナーの方
目的
● IaC（主にTerraform）の概要を掴んでいただいて、皆様の心に「IaC導入したい！」という火をつけること
Slide 17
Slide 17 text
まずは歴史のお勉強
Slide 18
Slide 18 text
鉄（オンプレミス）の時代
鉄の時代 … ソフトウェアがハードウェアの物理的な制約をうける
→
Slide 19
Slide 19 text
鉄（オンプレミス）の時代
鉄の時代 … ソフトウェアがハードウェアの物理的な制約をうける
→ マシンのプロビジョニングとメンテナンスは手動、確立された変更管理プロセスの準備が必要。サー
バーを増やすには、調達費用・時間もかかる。
もちろん、構成変更にも膨大な時間と労力がかかる。
Slide 20
Slide 20 text
鉄（オンプレミス）の時代の開発フロー
Slide 21
Slide 21 text
鉄（オンプレミス）の時代の特徴
● スケーリングが難しい
○ リソースは自分で拡張、設定する。まさに鉄の時代。
○ 設定のミスによりインフラ全体がダウンする可能性もある。
○ 一つのサーバーを大切に、真心を込めて機能追加。
Slide 22
Slide 22 text
鉄（オンプレミス）の時代の特徴
● 確立されたインフラ変更プロセスを用意するのが難しい
○ もちろん手動で作業をする。
■ 自前スクリプトなど高尚なものを持つ会社もあるが、それは一部の上積み。
○ サーバーの責務や台数によって必要なプロセスは異なる。
■ さらに本番・Test・ステージングなど環境毎にプロセスは異なる
○ 一時的に確立されたプロセスも、メンテナンスされなければ古文書となる。
■ （確立されたプロセスがあるだけでも実はマシ、なにも揃っていないアナーキーな現場も…）
Slide 23
Slide 23 text
鉄（オンプレミス）の時代の特徴
● インフラに強い人の協力なくしてデプロイ・構成変更が難しい
○ 人間はわからないものは怖いし触りたくないし見たくもない
○ ただしアプリの運用にインフラは必須のため、誰かが触っている
○ 誰かがやってくれているのでインフラの変更が他人事のようになる
■ リソースがPHPer（アプリケーションエンジニア）から遠い存在になっていく
Slide 24
Slide 24 text
時代は進む…
Slide 25
Slide 25 text
クラウド期
クラウドの時代 … 物理的なリソースの制限からソフトウェアが解放される。
→ どんなユーザーでも簡単に、すぐに、サーバーを建てられる様になった。
Slide 26
Slide 26 text
インフラのスケーリング、拡張は非常に容易になった
● リソースの制限はほとんどなし、必要なサーバーをその都度いくらでも建てられる
○ サーバー調達の手間などがほとんどなし！
○ 鉄の時代はおしまい、 金の時代へ
● サーバーを立てる手順も、コンソールをポチポチするだけ
○ サーバーの詳細な設定などが隠蔽されて、クラウド事業者ごとのちょっとした設定を覚えればPHPerでも気軽にサー
バーが建てられる！！！
クラウドの利用のメリット
Slide 27
Slide 27 text
インフラのスケーリング、拡張は非常に容易になった
● リソースの制限はほとんどなし、必要なサーバーをその都度いくらでも建てられる
○ サーバー調達の手間などがほとんどなし！
○ 鉄の時代はおしまい、 金の時代へ
● サーバーを立てる手順も、コンソールをポチポチするだけ
○ サーバーの詳細な設定などが隠蔽されて、クラウド事業者ごとのちょっとした設定を覚えればPHPerでも気軽にサー
バーが建てられる！！！
クラウドの利用のメリット
？？？「まかせろ！作るのは簡単だ！」
Slide 28
Slide 28 text
インフラのスケーリング、拡張は非常に容易になった
● リソースの制限はほとんどなし、必要なサーバーをその都度いくらでも建てられる
○ サーバー調達の手間などがほとんどなし！
○ 鉄の時代はおしまい、 金の時代へ
● サーバーを立てる手順も、コンソールをポチポチするだけ
○ サーバーの詳細な設定などが隠蔽されて、クラウド事業者ごとのちょっとした設定を覚えればPHPerでも気軽にサー
バーが建てられる！！！
クラウドの利用のメリット
？？？「まかせろ！作るのは簡単だ！」
？？？「作ったぞ、後は任せた！」
Slide 29
Slide 29 text
確立された運用プロセスが オンプレ時代 より求められる
● 誰でも簡単にサーバーを建てられる反面、それを管理するのが人間には非常に難しい。
○ ？？？「えっ、このサーバー使ってたんですか？」
○ そびえ立つ、” 〇〇〇〇prod-test ”という名の謎DB
● 秘伝のタレのように脈々と設定追加されるLB、CDN、etc…
● 「なんか動いている」
○
○
● もはや誰も管理できていない
○
クラウドの辛さ
Slide 30
Slide 30 text
確立された運用プロセスがオンプレ時代より求められる
● 誰でも簡単にサーバーを建てられる反面、それを管理するのが人間には非常に難しい。
○ ？？？「えっ、このサーバー使ってたんですか？」
○ そびえ立つ、” 〇〇〇〇prod-test ”という名の謎DB
● 秘伝のタレのように脈々と設定追加されるLB、CDN、etc…
● 「なんか動いている」
○ ほぼジェンガみたいなやつ
○ 奇跡のバランス・「 そのサーバーは、触れるな・見るな・忘れろ 」
● もはや誰も管理できていない
○
クラウドの辛さ
Slide 31
Slide 31 text
確立された運用プロセスがオンプレ時代より求められる
● 誰でも簡単にサーバーを建てられる反面、それを管理するのが人間には非常に難しい。
○ ？？？「えっ、このサーバー使ってたんですか？」
○ そびえ立つ、” 〇〇〇〇prod-test ”という名の謎DB
● 秘伝のタレのように脈々と設定追加されるLB、CDN、etc…
● 「なんか動いている」
○ ほぼジェンガみたいなやつ
○ 奇跡のバランス・「 そのサーバーは、触れるな・見るな・忘れろ 」
● もはや誰も管理できていない
○ オンプレ時代と何が変わったの？
クラウドの辛さ
Slide 32
Slide 32 text
① 統一的かつ継続的なプロセスでインフラ管理をしたい
● 各サーバーごとに必要な手順が異なると、複雑性が増加する。
● リソースの変更が入り、差分が発生するのは大した問題ではない。
○ なぜ・どのような差分があるのかを忘れて、同じリソースを素早く再構築できないことが問題である。
② インフラの構成・設定変更を気軽をできるようにしたい
● インフラリソースは変更されるという前提
○ 気軽に作成・破棄・交換・サイズ変更・移動ができるようになっていると、実行中のインフラに変更を入れることが怖くなくなる。
○ 何かあったら巻き戻せばいい
● 「サーバーはペットではなく畜牛のように扱え
」
○ サーバーへの真心は捨てよう、動かなくなったら次のサーバーを作ればいいい
③ きちんとバージョン管理されたドキュメントがほしい
● これを読む全員がもうすでにわかっていること（と同時に悲しいことではあるの）だが、
○ 人間に抜けもれなくドキュメントを作れと言っても不可能
○ 作ったものを確実に更新しろというのも不可能
ここまでの解決したい課題まとめ
Slide 33
Slide 33 text
さらに時代は進む…
Slide 34
Slide 34 text
IaCの時代
IaCの時代（現代）
→ IaCツールは、自身で記述したコードに基づいてクラウドリソースを作成、破棄、変更、移動でき
る。
また、コードをバージョン管理することにより、どうしてその変更が行われたのかなどの追跡も容易に
なった。
Slide 35
Slide 35 text
IaCツールのメリット
あらゆる変更をコード管理・バージョン管理できる
システムの柔軟な変更が可能になる
簡単に同様の環境を再現できる
Slide 36
Slide 36 text
IaCツールのメリット
あらゆる変更をコード管理・バージョン管理できる
● ツールの使い方を覚えればどのようなリソースがどんな設定で組まれているのかをコードを読めば分かる状態になる。
○ ドキュメントの代替になる。（諸説ある）
● 最初の実行時だけでなく、設定変更を継続的にコード管理できる。
○ 変更と変更が行われたバックグラウンドを知るためにPull Requestを見に行くなどのアクションが取れる。
システムの柔軟な変更が可能になる
簡単に同様の環境を再現できる
Slide 37
Slide 37 text
IaCツールのメリット
あらゆる変更をコード管理・バージョン管理できる
● ツールの使い方を覚えればどのようなリソースがどんな設定で組まれているのかをコードを読めば分かる状態になる。
○ ドキュメントの代替になる。（諸説ある）
● 最初の実行時だけでなく、設定変更を継続的にコード管理できる。
○ 変更と変更が行われたバックグラウンドを知るためにPull Requestを見に行くなどのアクションが取れる。
システムの柔軟な変更が可能になる
● システムが壊れないように変更を最小限に抑えても、システムは堅牢にはならない
● 使っていない筋肉が衰えていくのと同じ
● むしろ日頃から常にシステムに改良を重ねることで、システムの弱点や問題点を知ることができる。
○ 結果として将来発生しうる大きなインシデントに、オペレーションではなくシステムの能力を向上させることで対処できるようになる。
● IaCツールがあると、柔軟な変更が容易になる。
簡単に同様の環境を再現できる
Slide 38
Slide 38 text
IaCツールのメリット
あらゆる変更をコード管理・バージョン管理できる
● ツールの使い方を覚えればどのようなリソースがどんな設定で組まれているのかをコードを読めば分かる状態になる。
○ ドキュメントの代替になる。（諸説ある）
● 最初の実行時だけでなく、設定変更を継続的にコード管理できる。
○ 変更と変更が行われたバックグラウンドを知るためにPull Requestを見に行くなどのアクションが取れる。
システムの柔軟な変更が可能になる
● システムが壊れないように変更を最小限に抑えても、システムは堅牢にはならない
● 使っていない筋肉が衰えていくのと同じ
● むしろ日頃から常にシステムに改良を重ねることで、システムの弱点や問題点を知ることができる。
○ 結果として将来発生しうる大きなインシデントに、オペレーションではなくシステムの能力を向上させることで対処できるようになる。
● IaCツールがあると、柔軟な変更が容易になる。
簡単に同様の環境を再現できる
● クラウドとIaCツールを掛け合わせると、鉄の時代では考えられなかったような速度で検証環境などが用意できる。
Slide 39
Slide 39 text
IaCツールのメリット
DevOps文化の醸成に寄与する
● コードでリソースを管理する事ができる
○ ソフトウェアとデータの関係のようにインフラリソースを扱うことができる。
○ 開発者が変更Pull Requestを作成 → インフラ担当者がレビューといったフローを実現可能
● できること、視野が広がると、開発者（Developer）と運用者（Operator）の関心の輪が広がる
Slide 40
Slide 40 text
ツールごとの学習コストが掛かる
● 最初は誰でも初心者
○ ツールを導入した結果、余計インフラに取っつきにくくなってしまう懸念
○ ツール特有のバグや、バージョンアップのコストもかかる
CI/CDパイプラインの構築・運用の手間
● 個人的にはここが一番の難関
● とはいえCI/CDパイプラインがないと、快適なIaC環境とは言えないのでほぼセットとして考えたい
コード化が目的になると辛い
● コード化を採用する理由を把握していないと、「コンソールからやったほうが早くね？」と思うことはある。
○ クラウドは本当に優秀で、たしかにコンソール画面がわかりやすいし動作も早い
● 自分だけでなく、他のメンバーはコード化する理由をわかっているのか？
○ 辛いことを押し付けているだけになっていないか？
IaCツールのデメリット
Slide 41
Slide 41 text
IaCツールを使っていくぞ！
Slide 42
Slide 42 text
まずは主なIaCツールをご紹介
Slide 43
Slide 43 text
Terraform
● HashiCorp社が開発した「Infrastructure as Code(IaC)」ツール。
● HCL(HashiCorp Configuration Language)という独自の言語で記述する。
○ 下記味はYAMLやJSONのように非常にシンプルで誰が書いてもだいたい同じような記述になる
● 実装実態はGoで書かれており、オープンソース。
https://github.com/hashicorp/terraform
● 採用企業が圧倒的に多い
○ Wantedlyにて絞り込みをして計測（2023/08/14時点）
○ Terraform → 1890 CloudFormation → 373 AWS CDK → 272
● 複数のクラウドに対応（AWS, Azure, GCP, Fastly, etc...）
Slide 44
Slide 44 text
Terraform
● 書き味は非常にシンプル。
● `terraform init`
`terraform plan`
`terraform apply`
の順でコマンドを実行するとリソースが作成される。
● 既存のリソースをstateに取り込む`terraform import`もある。
Slide 45
Slide 45 text
CloudFormation
● AWSのリソースをJSONまたはYAMLの形式でプロビジョニン
グできるサービス。
● Stackと呼ばれる単位でリソースをひとまとめにできる
○ （≒ Terraformのstate）
● 作成できるのはAWSのサービスのみ。
● （今日はIaCツールの比較勉強会ではないので詳細は割愛）
Slide 46
Slide 46 text
AWS CDK
● TypeScript、JavaScript、Python、Javaなどの言語で記述が
可能
○ プログラミング言語の高い表現力を使える
● 似たツールにTerraform for CDKがあり、こちらはAWS以外の
リソースも作れる。
● （今日はIaCツールの比較勉強会ではないので詳細は割愛）
Slide 47
Slide 47 text
本題： Terraformを導入する
Slide 48
Slide 48 text
PR TIMESのAWS移行
● 詳細はこちら
https://developers.prtimes.jp/2022/12/01/prtimes-aws-migration/
● Webサーバー、DBサーバー、Redis、などなど色々とAWSへ移行しました。
● 移行時には
○ ポチポチコンソールによるAWSリソースの作成
○ Terraformへimport
の順番で作業を進めました。
Slide 49
Slide 49 text
PR TIMESのAWS移行
● 詳細はこちら
https://developers.prtimes.jp/2022/12/01/prtimes-aws-migration/
● Webサーバー、DBサーバー、Redis、などなど色々とAWSへ移行しました。
● 移行時には
○ ポチポチコンソールによるAWSリソースの作成
○ Terraformへimport
の順番で作業を進めました。
この順番が非常に大切。
いきなり全てをコード化するのではなくて、徐々にコードに取り込んでいったことが勝ち筋でした。
Slide 50
Slide 50 text
Terraform導入時に大切なこと・Tips
1. お約束
a. Terraform警察になろう
2. terraform importとData Sourcesを活用する
a. terraform import
b. Data Sources
3. IaCにもCI/CDパイプラインを構築する
4. tfmigrateを導入する
１ → ４の順番で重要です。
Slide 51
Slide 51 text
お約束
本発表を見て、聞いてTerraformを自社のインフラに導入したいと思っていただけるのは非常に光栄です。
そんなやる気に満ち溢れているアナタ、僕と一つ約束をしてください。
すごく簡単なことです。
Slide 52
Slide 52 text
お約束
毎日「terraform plan」を実行してくれぃ！！！
引用：ライスチャンネル（https://www.youtube.com/watch?v=PCENvh7dLH8）
Slide 53
Slide 53 text
Terraform警察になろう
「terraform plan」はコードと実態・stateの中身を比較して差分を検出するコマンドです。
● 差分とは読んで字の如く、コードが実態やstateの内容と乖離していることを示します。
● IaCの本旨は「いつでも」「どこでも」「何個でも」簡単に意図したインフラをプロビジョニングできるところにあります。
Slide 54
Slide 54 text
Terraform警察になろう
つまり、同じインフラを作れなくなっている時点でそのTerraformは死んでいるのです（仮死状態）。
● そして経験則ですが、差分はある日突然やってきます。
● AWS側の設定が変わったり、コンソールから他のメンバーがAWSリソースをいじったり
「terraform plan」はコードと実態・stateの中身を比較して差分を検出するコマンドです。
● 差分とは読んで字の如く、コードが実態やstateの内容と乖離していることを示します。
● IaCの本旨は「いつでも」「どこでも」「何個でも」簡単に意図したインフラをプロビジョニングできるところにあります。
Slide 55
Slide 55 text
Terraform警察になろう
つまり、同じインフラを作れなくなっている時点でそのTerraformは死んでいるのです（仮死状態）。
● そして経験則ですが、差分はある日突然やってきます。
● AWS側の設定が変わったり、コンソールから他のメンバーがAWSリソースをいじったり
「terraform plan」はコードと実態・stateの中身を比較して差分を検出するコマンドです。
● 差分とは読んで字の如く、コードが実態やstateの内容と乖離していることを示します。
● IaCの本旨は「いつでも」「どこでも」「何個でも」簡単に意図したインフラをプロビジョニングできるところにあります。
差分が大量にできたTerraformは誰も触りたくないので、Terraform以外から手を加え始めます。
● これを人は【Terraform恐怖症の悪循環 】と呼びます。
○ 避けるべき状態
Slide 56
Slide 56 text
Terraform恐怖症の悪循環
Slide 57
Slide 57 text
Terraform警察になろう
つまり、同じインフラを作れなくなっている時点でそのTerraformは死んでいるのです（仮死状態）。
● そして経験則ですが、差分はある日突然やってきます。
● AWS側の設定が変わったり、コンソールから他のメンバーがAWSリソースをいじったり
「terraform plan」はコードと実態・stateの中身を比較して差分を検出するコマンドです。
● 差分とは読んで字の如く、コードが実態やstateの内容と乖離していることを示します。
● IaCの本旨は「いつでも」「どこでも」「何個でも」簡単に意図したインフラをプロビジョニングできるところにあります。
差分が大量にできたTerraformは誰も触りたくないので、Terraform以外から手を加え始めます。
● これを人は【Terraform恐怖症の悪循環 】と呼びます。
○ 避けるべき状態
こうなるとせっかく導入したTerraformが本当に無駄になってしまうので、毎日Planを実行して差分を検出 → 修正をしましょう。
※参考 「O'Reilly Infarastructure as Code
オートメーション恐怖症の悪循環」
Slide 58
Slide 58 text
毎日Planを実行するだけ、
簡単でしょ？
Slide 59
Slide 59 text
あなたも今日からTerraform警察
Slide 60
Slide 60 text
差分を摘発せよ！
Slide 61
Slide 61 text
つぎ
Slide 62
Slide 62 text
terraform importとData Sourcesを活用する
● Terraformに慣れていない状況でいきなり全てのリソースをTerraformから作成するのは非常に難しいです。
○ いきなりIaCを強要すると、インフラに触りたくなくなり、PHPer（アプリケーションエンジニア）とインフラの距離はより拡大しま
す。
● 新規作成するリソースに関しては
○ コンソールから作成
○ Terraformへの取り込み
の順で実行して、無理なく稼働中のリソースにTerraform導入をしましょう。
※ 既にTerraform管理下のリソースの設定変更はコード側からやりましょう、そうしないとIaCとしての意味がないです。
● Terraformには、Terraform外で作成されたリソースを管理下に置くための「terraform import」コマンドがあります。
Slide 63
Slide 63 text
terraform import
`terraform import`の使い方は基本的に以下のとおりです。
1. リソースをコンソールから作成する。
2. importコマンドを実行する。
3. リソースの実態に合わせてstateが更新される。
4. 更新されたstateにコードを合わせる。
Slide 64
Slide 64 text
terraform import
`terraform import`の使い方は基本的に以下のとおりです。
1. リソースをコンソールから作成する。
2. importコマンドを実行する。
3. リソースの実態に合わせてstateが更新される。
4. 更新されたstateにコードを合わせる。
Slide 65
Slide 65 text
terraform import
`terraform import`の使い方は基本的に以下のとおりです。
1. リソースをコンソールから作成する。
2. importコマンドを実行する。
3. リソースの実態に合わせてstateが更新される。
4. 更新されたstateにコードを合わせる。
Slide 66
Slide 66 text
terraform import
`terraform import`の使い方は基本的に以下のとおりです。
1. リソースをコンソールから作成する。
2. importコマンドを実行する。
3. リソースの実態に合わせてstateが更新される。
4. 更新されたstateにコードを合わせる。
Slide 67
Slide 67 text
terraform import
`terraform import`の使い方は基本的に以下のとおりです。
1. リソースをコンソールから作成する。
2. importコマンドを実行する。
3. リソースの実態に合わせてstateが更新される。
4. 更新されたstateにコードを合わせる。
Slide 68
Slide 68 text
terraform import
`terraform import`の使い方は基本的に以下のとおりです。
1. リソースをコンソールから作成する。
2. importコマンドを実行する。
3. リソースの実態に合わせてstateが更新される。
4. 更新されたstateにコードを合わせる。
簡単！！！😁
Slide 69
Slide 69 text
Data Sources
Data Sourcesとは？
Slide 70
Slide 70 text
Data Sources
Data Sourcesとは？
要するに、リソースの依存関係を解決するためにすごく便利なやつ。
Slide 71
Slide 71 text
Data Sources
例えば、サブネットを新規で作りたいケースを考えてます。
Slide 72
Slide 72 text
Data Sources
● 公式Documentのaws_subnetを見に行く
○ Argument Reference にはvpc_idがrequiredとなっている
○ vpc_idは各VPC毎に割り振られるランダムな値。
○ つまり、本来サブネット作成時にはこのvpc_idがTerraform側から参照できる状態でなければならない
Slide 73
Slide 73 text
Data Sources
● 公式Documentのaws_subnetを見に行く
○ Argument Reference にはvpc_idがrequiredとなっている
○ vpc_idは各VPC毎に割り振られるランダムな値。
○ つまり、本来サブネット作成時にはこのvpc_idがTerraform側から参照できる状態でなければならない
● しかしサブネットを作成したいときに、VPCがTerraform管理されているとは限らない。
○ また、Terraform管理されていたとしても、同じState（≒ 参照可能な範囲）に存在しないケースも多々ある。
Slide 74
Slide 74 text
Data Sources
● 公式Documentのaws_subnetを見に行く
○ Argument Reference にはvpc_idがrequiredとなっている
○ vpc_idは各VPC毎に割り振られるランダムな値。
○ つまり、本来サブネット作成時にはこのvpc_idがTerraform側から参照できる状態でなければならない
● しかしサブネットを作成したいときに、VPCがTerraform管理されているとは限らない。
○ また、Terraform管理されていたとしても、同じState（≒ 参照可能な範囲）に存在しないケースも多々ある。
○ 実は文字列でvpc_idをハードコーディングしても動作はするのだが、それはそれで微妙
Slide 75
Slide 75 text
Data Sources
● そんなときに便利なのがData Sources
こちらのコードは、Terraform管理されていないAWSアカウントのデフォルトVPCを参照するときに使えるコード。
Slide 76
Slide 76 text
Data Sources
● そんなときに便利なのがData Sources
こちらのコードは、Terraform管理されていないAWSアカウントのデフォルトVPCを参照するときに使えるコード。
● 本来同じStateで管理されていないと参照できないような値も、Data Sourcesを使うことでTerraform管理する（≒
importする）前から、管理下のリソースと同じように参照できる。
○ 私はimportする時に、 ALBやCloudFrontなど変更の入る予定の多いものから段々とimportすることをオススメ
しています。
○ その時、ALBやCloudFrontが依存しているリソースに気を取られることなく、目当てのものをimportするために
Data Sourcesは非常に役立ちます。
■
Slide 77
Slide 77 text
Data Sources
● そんなときに便利なのがData Sources
こちらのコードは、Terraform管理されていないAWSアカウントのデフォルトVPCを参照するときに使えるコード。
● 本来同じStateで管理されていないと参照できないような値も、Data Sourcesを使うことでTerraform管理する（≒
importする）前から、管理下のリソースと同じように参照できる。
○ 私はimportする時に、 ALBやCloudFrontなど変更の入る予定の多いものから段々とimportすることをオススメ
しています。
○ その時、ALBやCloudFrontが依存しているリソースに気を取られることなく、目当てのものをimportするために
Data Sourcesは非常に役立ちます。
■ （注意）Data Sourcesは参照できるだけで依存先がコード管理されているわけではない
Slide 78
Slide 78 text
依存関係を（ほとんど）気にせずTerraformは導
入できるんです。
Slide 79
Slide 79 text
できそうじゃない？
Slide 80
Slide 80 text
つぎ
Slide 81
Slide 81 text
IaCにもCI/CDパイプラインを構築する
● バージョン管理システムを使いたい
○ GitHubのPull Requestなどで変更のレビューなんかできると最高ですよね
○ インフラに自信のないPHPer（アプリケーションエンジニア）たちでも、レビュワーに強い人を当ててレビュー依頼していきましょ
う！
● CI/CDパイプラインも作りたい
○ GitHub ActionsなのかCircleCIなのかCodeBuildなのか、それはなんでもいい気がする。
■ 大切なのは、GitHubのメインブランチ（みんなが参照できるコード）とStateの差分が生じていないこと
○
■
■
○
○ ここが一番大変かもしれませんが、運用を楽をするための苦労だと思って走りきりましょう。
Slide 82
Slide 82 text
IaCにもCI/CDパイプラインを構築する
● バージョン管理システムを使いたい
○ GitHubのPull Requestなどで変更のレビューなんかできると最高ですよね
○ インフラに自信のないPHPer（アプリケーションエンジニア）たちでも、レビュワーに強い人を当ててレビュー依頼していきましょ
う！
● CI/CDパイプラインも作りたい
○ GitHub ActionsなのかCircleCIなのかCodeBuildなのか、それはなんでもいい気がする。
■ 大切なのは、GitHubのメインブランチ（みんなが参照できるコード）とStateの差分が生じていないこと
○ ローカルのApplyは甘えです
■ ローカルでApplyするってことは、オペミスがあったらメインブランチとStateに差分があるってことになる
■ みんなが見れるコードが差分ありの状態ってIaCの意味ないよね…？
○
○ ここが一番大変かもしれませんが、運用を楽をするための苦労だと思って走りきりましょう。
Slide 83
Slide 83 text
IaCにもCI/CDパイプラインを構築する
● バージョン管理システムを使いたい
○ GitHubのPull Requestなどで変更のレビューなんかできると最高ですよね
○ インフラに自信のないPHPer（アプリケーションエンジニア）たちでも、レビュワーに強い人を当ててレビュー依頼していきましょ
う！
● CI/CDパイプラインも作りたい
○ GitHub ActionsなのかCircleCIなのかCodeBuildなのか、それはなんでもいい気がする。
■ 大切なのは、GitHubのメインブランチ（みんなが参照できるコード）とStateの差分が生じていないこと
○ ローカルのApplyは甘えです
■ ローカルでApplyするってことは、オペミスがあったらメインブランチとStateに差分があるってことになる
■ みんなが見れるコードが差分ありの状態ってIaCの意味ないよね…？
○ 私と約束した「毎日のPlan実行 」もCIツールで自動化したいですね
○ ここが一番大変かもしれませんが、運用を楽をするための苦労だと思って走りきりましょう。
Slide 84
Slide 84 text
IaCにもCI/CDパイプラインを構築する
● バージョン管理システムを使いたい
○ GitHubのPull Requestなどで変更のレビューなんかできると最高ですよね
○ インフラに自信のないPHPer（アプリケーションエンジニア）たちでも、レビュワーに強い人を当ててレビュー依頼していきましょ
う！
● CI/CDパイプラインも作りたい
○ GitHub ActionsなのかCircleCIなのかCodeBuildなのか、それはなんでもいい気がする。
■ 大切なのは、GitHubのメインブランチ（みんなが参照できるコード）とStateの差分が生じていないこと
○ ローカルのApplyは甘えです
■ ローカルでApplyするってことは、オペミスがあったらメインブランチとStateに差分があるってことになる
■ みんなが見れるコードが差分ありの状態ってIaCの意味ないよね…？
○ 私と約束した「毎日のPlan実行 」もCIツールで自動化したいですね
○ ここが一番大変かもしれませんが、運用を楽をするための苦労だと思って走りきりましょう。
大切なのは、
アプリケーションコードと同じようにインフラのコードも扱うこと
Slide 85
Slide 85 text
つぎ
Slide 86
Slide 86 text
tfmigrateを導入する
● tfmigrateについては作者の方のQiita記事があるので詳しくはそちらへ
○ Terraformのstate操作をgitにコミットしたくてtfmigrateというツールを書いた
● 導入すると、`terraform state mv`や`terraform import`のようなstateを操作するコマンドも、Gitの履歴に残せるようになる。
○ 最初少人数でTerraformを使っているときはあまり気にならないが、みんながTerraformを触るようになると上記のよう
なStateを編集するコマンドをローカルで実行してしまうと、他の人のローカルコードとの間に差分が発生してしまう。
○ そもそも、`state mv`や`state rm`コマンドもstateを編集するコマンドでインフラリソースに影響があるのでGit管理して
コードレビューなどをできるようにしたい。
Slide 87
Slide 87 text
tfmigrateを導入する
● 導入のメリット
○ tfmigrateは内 部で「terraform plan」が` no changed`、つまり差分なしになることを要求する。
■
○ state操作をする際、以前の履歴がコードで残っているので参考にしてstate操作が可能になる。
○ 実際のstate操作ではなくコードを書いてコードレビューというフローにすることで、敷居が下がる
■
Slide 88
Slide 88 text
tfmigrateを導入する
● 導入のメリット
○ tfmigrateは内 部で「terraform plan」が` no changed`、つまり差分なしになることを要求する。
■ remote stateの変更によるリソースの変更がないことを担保できる。
○ state操作をする際、以前の履歴がコードで残っているので参考にしてstate操作が可能になる。
○ 実際のstate操作ではなくコードを書いてコードレビューというフローにすることで、敷居が下がる
■
Slide 89
Slide 89 text
tfmigrateを導入する
● 導入のメリット
○ tfmigrateは内 部で「terraform plan」が` no changed`、つまり差分なしになることを要求する。
■ remote stateの変更によるリソースの変更がないことを担保できる。
○ state操作をする際、以前の履歴がコードで残っているので参考にしてstate操作が可能になる。
○ 実際のstate操作ではなくコードを書いてコードレビューというフローにすることで、敷居が下がる
■ 詳しくない人でも「やってみた！」ができる環境づくり。
Slide 90
Slide 90 text
tfmigrateを導入する
● 導入のメリット
○ tfmigrateは内 部で「terraform plan」が` no changed`、つまり差分なしになることを要求する。
■ remote stateの変更によるリソースの変更がないことを担保できる。
○ state操作をする際、以前の履歴がコードで残っているので参考にしてstate操作が可能になる。
○ 実際のstate操作ではなくコードを書いてコードレビューというフローにすることで、敷居が下がる
■ 詳しくない人でも「やってみた！」ができる環境づくり。
前章の内容と絡めて、
● tfmigrate plan
● tfmigrate apply
まで一気通貫したCI/CDパイプラインになるともう怖いものはなくなります。
Slide 91
Slide 91 text
まとめ
● Terraformの導入は怖くないです。
○ 本当に怖いのはインフラが壊れたときにそれを直す術がないことです。
● IaCが目的になるのは良くないので、「自分たちがIaC管理したい！」と思うリソースから一つずつコー
ド化していきましょう。
● 個人的にはコンソールからのリソース作成・編集・破棄を完全に禁じるのは微妙だなと思っていま
す。
○ ぶっちゃけコンソールからの方が操作が早くて容易なことは多々ある。
○ 差分ができることは悪ではありません、差分を放置してなぜその状態にあるのか皆が忘れて
しまう状態なのが悪なのです。
● 私との約束を覚えていますか？
Slide 92
Slide 92 text
まとめ
● Terraformの導入は怖くないです。
○ 本当に怖いのはインフラが壊れたときにそれを直す術がないことです。
● IaCが目的になるのは良くないので、「自分たちがIaC管理したい！」と思うリソースから一つずつコー
ド化していきましょう。
● 個人的にはコンソールからのリソース作成・編集・破棄を完全に禁じるのは微妙だなと思っていま
す。
○ ぶっちゃけコンソールからの方が操作が早くて容易なことは多々ある。
○ 差分ができることは悪ではありません、差分を放置してなぜその状態にあるのか皆が忘れて
しまう状態なのが悪なのです。
● 私との約束を覚えていますか？
毎日、「terraform plan」を実行してくれぃ！！！
Slide 93
Slide 93 text
参考文献
● Kief Morris「O'Reilly Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス」
● 門別 優多「IaCで全てが上手くいくと思うなよ_失敗事例のご紹介」
https://speakerdeck.com/mokocm/iactequan-tekashang-shou-kuikutosi-unayo-shi-bai-shi-li-falsekoshao-jie
● TRUST BUNK「DevOps実装初期フェーズの組織がTerraformとecspressoで求めるAmazon ECS CICDの最適解」
https://speakerdeck.com/tocyuki/aws-ecs-cicd-with-terraform-and-ecspresso