PHPerもIaCを使おう！ 17年物のインフラをTerraformに大移行

PHPerもIaCを使おう！  17年物のインフラをTerraformに大移行  At: PHPカンファレンス福岡2023  Speaker: Kensho Iwashita 

自己紹介  名前：岩下拳勝  Twitter, GitHub： iwashi623  担当業務：バックエンドエンジニア（PHPer）  趣味：プロ野球観戦（阪神ファン） 
AWSの資格取得（SAA/SAP/SOS/DVA） 

注意  • 本発表はIaC導入のメリットや、Terraform導入時の心構え、チョットしたTipsを話す発表です。   ◦ オンプレインフラを一気に「クラウド × Terraform」化した具体的な手順やコードなどは一切出てこないので悪しからず。  •
IaC運用の具体的なルールは各社毎に異なりますので、先輩や偉い人の言うことを聞いてください。  • 現在自分が経験してきた中でこれはTerraform運用に必要だな〜と思うことを話します。数年（下手したら数日）後には変わることがあることをご承知おきください。  

はじめに  突然ですが、PHPerの皆さんは普段からインフラ構成の変更をしていますか？  

Webアプリケーションエンジニアがインフラに触れるメリット   会社目線  • チームの開発・改善の効率性が向上   ◦ 自チームに必要なインフラを一番良くわかっているチームメンバーが、自分たちでインスタンス追加・配置変更などができるようになる。  →
組織のコミュニケーションコストやタスク調整の工数が減少する。   個人目線  • スキルの向上   ◦ Webアプリケーションの開発力向上だけを行っていてもどこかで成長の波が鈍化する。（パレートの法則）   ▪ 偏差値30 -> 50より、50 -> 70の方が難しいのと同じ   ▪ 偏差値50くらいのインフラ知識があれば、QiitaやZennの記事を読んだときにもっと分かることが増える気がする！   • 市場価値の向上   ◦ （ぶっちゃけ）クラウドが広がったおかげもあり、インフラスキルの汎用性が上がったので転職も容易なのでは？   私の主張：PHPerもインフラ触っていこうぜ！ 

反論  • 「触ることができるならお前に言われなくても…！」  ◦   • 「インフラってなにからしていいのかわからない！」  ◦   •
「うちのインフラを見てみろや！飛ぶぞ！」  ◦  

反論  • 「触ることができるならお前に言われなくても…！」  ◦ わかります、PR TIMESがオンプレ時代の私もそうでした  • 「インフラってなにからしていいのかわからない！」  ◦  
• 「うちのインフラを見てみろや！飛ぶぞ！」  ◦  

反論  • 「触ることができるならお前に言われなくても…！」  ◦ わかります、PR TIMESがオンプレ時代の私もそうでした  • 「インフラってなにからしていいのかわからない！」  ◦ わかります、まずはマネコンにログインしましょう 
• 「うちのインフラを見てみろや！飛ぶぞ！」  ◦  

反論  • 「触ることができるならお前に言われなくても…！」  ◦ わかります、PR TIMESがオンプレ時代の私もそうでした  • 「インフラってなにからしていいのかわからない！」  ◦ わかります、まずはマネコンにログインしましょう 
• 「うちのインフラを見てみろや！飛ぶぞ！」  ◦ 👼 

実例紹介  • PR TIMESは、以前はオンプレミスのデータセンターにあるサーバーにデプロイされていました。   ◦ この時代のインフラはドキュメントも満足に揃ってない   ◦ 構成変更や拡張をしたくてもその都度色々問題が噴出する状況
 

  ぼく「ドキュメント… ドキュメント…」

  ぼく「ドキュメント… ドキュメント…」先輩「そんなもんあるわけないじゃないですかｗww」  

  ぼく「ドキュメント… ドキュメント…」先輩「そんなもんあるわけないじゃないですかｗww」   ぼく「なにわろとんねん」  

実例紹介  そんな状況なのでみんなで頑張ってAWSに移行しました   • 移行時にTerraformも頑張って導入しました。   ◦ EC2、RDS、CloudFront、VPCなど...   ◦
インフラの全貌がつかみやすくなる   • 導入した人たちがTerraformを使っていくと、段々と組織内に拡大、定着していった。   ◦ 作業の影響範囲が見える化されて、構成変更への謎の恐怖がなくなったことが要因  

実例紹介  そんな状況なのでみんなで頑張ってAWSに移行しました   • 移行時にTerraformも頑張って導入しました。   ◦ EC2、RDS、CloudFront、VPCなど...   ◦
インフラの全貌がつかみやすくなる   • 導入した人たちがTerraformを使っていくと、段々と組織内に拡大、定着していった。   ◦ 作業の影響範囲が見える化されて、構成変更への謎の恐怖がなくなったことが要因   新卒の若手が9割の20人規模（当時）の組織でもTerraform化できた！ 

本トークの対象者と目的  対象者  • IaCというかっこいいものが流行っているのは知っているけど触れていない方   • 「IaCのメリットはわかっているけど、うちには導入できない！」と思っている方   • なんとなく、インフラを触ってみたいけど二の足を踏んでしまっているビギナーの方
  目的  • IaC（主にTerraform）の概要を掴んでいただいて、皆様の心に「IaC導入したい！」という火をつけること  

まずは歴史のお勉強 

鉄（オンプレミス）の時代  鉄の時代 … ソフトウェアがハードウェアの物理的な制約をうける  →  

鉄（オンプレミス）の時代  鉄の時代 … ソフトウェアがハードウェアの物理的な制約をうける  → マシンのプロビジョニングとメンテナンスは手動、確立された変更管理プロセスの準備が必要。サーバーを増やすには、調達費用・時間もかかる。   もちろん、構成変更にも膨大な時間と労力がかかる。  

鉄（オンプレミス）の時代の開発フロー 

鉄（オンプレミス）の時代の特徴  • スケーリングが難しい   ◦ リソースは自分で拡張、設定する。まさに鉄の時代。   ◦ 設定のミスによりインフラ全体がダウンする可能性もある。  
◦ 一つのサーバーを大切に、真心を込めて機能追加。

鉄（オンプレミス）の時代の特徴  • 確立されたインフラ変更プロセスを用意するのが難しい   ◦ もちろん手動で作業をする。   ▪ 自前スクリプトなど高尚なものを持つ会社もあるが、それは一部の上積み。  
◦ サーバーの責務や台数によって必要なプロセスは異なる。   ▪ さらに本番・Test・ステージングなど環境毎にプロセスは異なる   ◦ 一時的に確立されたプロセスも、メンテナンスされなければ古文書となる。   ▪ （確立されたプロセスがあるだけでも実はマシ、なにも揃っていないアナーキーな現場も…）  

鉄（オンプレミス）の時代の特徴  • インフラに強い人の協力なくしてデプロイ・構成変更が難しい   ◦ 人間はわからないものは怖いし触りたくないし見たくもない   ◦ ただしアプリの運用にインフラは必須のため、誰かが触っている  
◦ 誰かがやってくれているのでインフラの変更が他人事のようになる   ▪ リソースがPHPer（アプリケーションエンジニア）から遠い存在になっていく  

時代は進む… 

クラウド期  クラウドの時代 … 物理的なリソースの制限からソフトウェアが解放される。  → どんなユーザーでも簡単に、すぐに、サーバーを建てられる様になった。 

インフラのスケーリング、拡張は非常に容易になった   • リソースの制限はほとんどなし、必要なサーバーをその都度いくらでも建てられる   ◦ サーバー調達の手間などがほとんどなし！   ◦ 鉄の時代はおしまい、
金の時代へ  • サーバーを立てる手順も、コンソールをポチポチするだけ   ◦ サーバーの詳細な設定などが隠蔽されて、クラウド事業者ごとのちょっとした設定を覚えればPHPerでも気軽にサーバーが建てられる！！！   クラウドの利用のメリット 

金の時代へ  • サーバーを立てる手順も、コンソールをポチポチするだけ   ◦ サーバーの詳細な設定などが隠蔽されて、クラウド事業者ごとのちょっとした設定を覚えればPHPerでも気軽にサーバーが建てられる！！！     クラウドの利用のメリット    ？？？「まかせろ！作るのは簡単だ！」  

金の時代へ  • サーバーを立てる手順も、コンソールをポチポチするだけ   ◦ サーバーの詳細な設定などが隠蔽されて、クラウド事業者ごとのちょっとした設定を覚えればPHPerでも気軽にサーバーが建てられる！！！     クラウドの利用のメリット  ？？？「まかせろ！作るのは簡単だ！」   ？？？「作ったぞ、後は任せた！」  

確立された運用プロセスがオンプレ時代より求められる   • 誰でも簡単にサーバーを建てられる反面、それを管理するのが人間には非常に難しい。   ◦ ？？？「えっ、このサーバー使ってたんですか？」  
◦ そびえ立つ、” 〇〇〇〇prod-test ”という名の謎DB   • 秘伝のタレのように脈々と設定追加されるLB、CDN、etc…   • 「なんか動いている」   ◦   ◦   • もはや誰も管理できていない   ◦   クラウドの辛さ 

確立された運用プロセスがオンプレ時代より求められる   • 誰でも簡単にサーバーを建てられる反面、それを管理するのが人間には非常に難しい。   ◦ ？？？「えっ、このサーバー使ってたんですか？」   ◦ そびえ立つ、”
〇〇〇〇prod-test ”という名の謎DB   • 秘伝のタレのように脈々と設定追加されるLB、CDN、etc…   • 「なんか動いている」   ◦ ほぼジェンガみたいなやつ   ◦ 奇跡のバランス・「そのサーバーは、触れるな・見るな・忘れろ」  • もはや誰も管理できていない   ◦   クラウドの辛さ 

確立された運用プロセスがオンプレ時代より求められる   • 誰でも簡単にサーバーを建てられる反面、それを管理するのが人間には非常に難しい。   ◦ ？？？「えっ、このサーバー使ってたんですか？」   ◦ そびえ立つ、”
〇〇〇〇prod-test ”という名の謎DB   • 秘伝のタレのように脈々と設定追加されるLB、CDN、etc…   • 「なんか動いている」   ◦ ほぼジェンガみたいなやつ   ◦ 奇跡のバランス・「そのサーバーは、触れるな・見るな・忘れろ」  • もはや誰も管理できていない   ◦ オンプレ時代と何が変わったの？  クラウドの辛さ 

① 統一的かつ継続的なプロセスでインフラ管理をしたい   • 各サーバーごとに必要な手順が異なると、複雑性が増加する。   • リソースの変更が入り、差分が発生するのは大した問題ではない。   ◦
なぜ・どのような差分があるのかを忘れて、同じリソースを素早く再構築できないことが問題である。   ② インフラの構成・設定変更を気軽をできるようにしたい   • インフラリソースは変更されるという前提   ◦ 気軽に作成・破棄・交換・サイズ変更・移動ができるようになっていると、実行中のインフラに変更を入れることが怖くなくなる。   ◦ 何かあったら巻き戻せばいい  • 「サーバーはペットではなく畜牛のように扱え」  ◦ サーバーへの真心は捨てよう、動かなくなったら次のサーバーを作ればいいい   ③ きちんとバージョン管理されたドキュメントがほしい   • これを読む全員がもうすでにわかっていること（と同時に悲しいことではあるの）だが、   ◦ 人間に抜けもれなくドキュメントを作れと言っても不可能   ◦ 作ったものを確実に更新しろというのも不可能   ここまでの解決したい課題まとめ 

さらに時代は進む… 

IaCの時代   IaCの時代（現代）   → IaCツールは、自身で記述したコードに基づいてクラウドリソースを作成、破棄、変更、移動できる。  また、コードをバージョン管理することにより、どうしてその変更が行われたのかなどの追跡も容易になった。 

IaCツールのメリット  あらゆる変更をコード管理・バージョン管理できる     システムの柔軟な変更が可能になる     簡単に同様の環境を再現できる  

IaCツールのメリット  あらゆる変更をコード管理・バージョン管理できる   • ツールの使い方を覚えればどのようなリソースがどんな設定で組まれているのかをコードを読めば分かる状態になる。   ◦ ドキュメントの代替になる。（諸説ある）   •
最初の実行時だけでなく、設定変更を継続的にコード管理できる。   ◦ 変更と変更が行われたバックグラウンドを知るためにPull Requestを見に行くなどのアクションが取れる。   システムの柔軟な変更が可能になる     簡単に同様の環境を再現できる  

最初の実行時だけでなく、設定変更を継続的にコード管理できる。   ◦ 変更と変更が行われたバックグラウンドを知るためにPull Requestを見に行くなどのアクションが取れる。   システムの柔軟な変更が可能になる   • システムが壊れないように変更を最小限に抑えても、システムは堅牢にはならない   • 使っていない筋肉が衰えていくのと同じ   • むしろ日頃から常にシステムに改良を重ねることで、システムの弱点や問題点を知ることができる。   ◦ 結果として将来発生しうる大きなインシデントに、オペレーションではなくシステムの能力を向上させることで対処できるようになる。   • IaCツールがあると、柔軟な変更が容易になる。     簡単に同様の環境を再現できる  

最初の実行時だけでなく、設定変更を継続的にコード管理できる。   ◦ 変更と変更が行われたバックグラウンドを知るためにPull Requestを見に行くなどのアクションが取れる。   システムの柔軟な変更が可能になる   • システムが壊れないように変更を最小限に抑えても、システムは堅牢にはならない   • 使っていない筋肉が衰えていくのと同じ   • むしろ日頃から常にシステムに改良を重ねることで、システムの弱点や問題点を知ることができる。   ◦ 結果として将来発生しうる大きなインシデントに、オペレーションではなくシステムの能力を向上させることで対処できるようになる。   • IaCツールがあると、柔軟な変更が容易になる。     簡単に同様の環境を再現できる   • クラウドとIaCツールを掛け合わせると、鉄の時代では考えられなかったような速度で検証環境などが用意できる。  

IaCツールのメリット  DevOps文化の醸成に寄与する   • コードでリソースを管理する事ができる   ◦ ソフトウェアとデータの関係のようにインフラリソースを扱うことができる。   ◦
開発者が変更Pull Requestを作成 → インフラ担当者がレビューといったフローを実現可能   • できること、視野が広がると、開発者（Developer）と運用者（Operator）の関心の輪が広がる  

ツールごとの学習コストが掛かる   • 最初は誰でも初心者   ◦ ツールを導入した結果、余計インフラに取っつきにくくなってしまう懸念   ◦ ツール特有のバグや、バージョンアップのコストもかかる
  CI/CDパイプラインの構築・運用の手間   • 個人的にはここが一番の難関   • とはいえCI/CDパイプラインがないと、快適なIaC環境とは言えないのでほぼセットとして考えたい   コード化が目的になると辛い   • コード化を採用する理由を把握していないと、「コンソールからやったほうが早くね？」と思うことはある。   ◦ クラウドは本当に優秀で、たしかにコンソール画面がわかりやすいし動作も早い   • 自分だけでなく、他のメンバーはコード化する理由をわかっているのか？   ◦ 辛いことを押し付けているだけになっていないか？   IaCツールのデメリット 

IaCツールを使っていくぞ！ 

まずは主なIaCツールをご紹介 

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...）  

Terraform  • 書き味は非常にシンプル。   • `terraform init`   `terraform plan`
  `terraform apply`   の順でコマンドを実行するとリソースが作成される。   • 既存のリソースをstateに取り込む`terraform import`もある。  

CloudFormation  • AWSのリソースをJSONまたはYAMLの形式でプロビジョニングできるサービス。   • Stackと呼ばれる単位でリソースをひとまとめにできる   ◦ （≒
Terraformのstate）   • 作成できるのはAWSのサービスのみ。   • （今日はIaCツールの比較勉強会ではないので詳細は割愛）  

AWS CDK  • TypeScript、JavaScript、Python、Javaなどの言語で記述が可能  ◦ プログラミング言語の高い表現力を使える   • 似たツールにTerraform
for CDKがあり、こちらはAWS以外のリソースも作れる。   • （今日はIaCツールの比較勉強会ではないので詳細は割愛）  

本題： Terraformを導入する 

PR TIMESのAWS移行  • 詳細はこちら  https://developers.prtimes.jp/2022/12/01/prtimes-aws-migration/   • Webサーバー、DBサーバー、Redis、などなど色々とAWSへ移行しました。   •
移行時には  ◦ ポチポチコンソールによるAWSリソースの作成   ◦ Terraformへimport  の順番で作業を進めました。  

PR TIMESのAWS移行  • 詳細はこちら  https://developers.prtimes.jp/2022/12/01/prtimes-aws-migration/   • Webサーバー、DBサーバー、Redis、などなど色々とAWSへ移行しました。   •
移行時には  ◦ ポチポチコンソールによるAWSリソースの作成   ◦ Terraformへimport  の順番で作業を進めました。   この順番が非常に大切。   いきなり全てをコード化するのではなくて、徐々にコードに取り込んでいったことが勝ち筋でした。  

Terraform導入時に大切なこと・Tips  1. お約束  a. Terraform警察になろう   2. terraform importとData Sourcesを活用する
  a. terraform import   b. Data Sources  3. IaCにもCI/CDパイプラインを構築する   4. tfmigrateを導入する     １ → ４の順番で重要です。  

お約束  本発表を見て、聞いてTerraformを自社のインフラに導入したいと思っていただけるのは非常に光栄です。   そんなやる気に満ち溢れているアナタ、僕と一つ約束をしてください。   すごく簡単なことです。   

お約束  毎日「terraform plan」を実行してくれぃ！！！󰢛    引用：ライスチャンネル（https://www.youtube.com/watch?v=PCENvh7dLH8）  

Terraform警察になろう  「terraform plan」はコードと実態・stateの中身を比較して差分を検出するコマンドです。   • 差分とは読んで字の如く、コードが実態やstateの内容と乖離していることを示します。   • IaCの本旨は「いつでも」「どこでも」「何個でも」簡単に意図したインフラをプロビジョニングできるところにあります。  

Terraform警察になろう  つまり、同じインフラを作れなくなっている時点でそのTerraformは死んでいるのです（仮死状態）。   • そして経験則ですが、差分はある日突然やってきます。   • AWS側の設定が変わったり、コンソールから他のメンバーがAWSリソースをいじったり   「terraform
plan」はコードと実態・stateの中身を比較して差分を検出するコマンドです。   • 差分とは読んで字の如く、コードが実態やstateの内容と乖離していることを示します。   • IaCの本旨は「いつでも」「どこでも」「何個でも」簡単に意図したインフラをプロビジョニングできるところにあります。  

Terraform警察になろう    つまり、同じインフラを作れなくなっている時点でそのTerraformは死んでいるのです（仮死状態）。   • そして経験則ですが、差分はある日突然やってきます。   • AWS側の設定が変わったり、コンソールから他のメンバーがAWSリソースをいじったり  
「terraform plan」はコードと実態・stateの中身を比較して差分を検出するコマンドです。   • 差分とは読んで字の如く、コードが実態やstateの内容と乖離していることを示します。   • IaCの本旨は「いつでも」「どこでも」「何個でも」簡単に意図したインフラをプロビジョニングできるところにあります。   差分が大量にできたTerraformは誰も触りたくないので、Terraform以外から手を加え始めます。   • これを人は【Terraform恐怖症の悪循環】と呼びます。  ◦ 避けるべき状態  

Terraform恐怖症の悪循環

Terraform警察になろう    つまり、同じインフラを作れなくなっている時点でそのTerraformは死んでいるのです（仮死状態）。   • そして経験則ですが、差分はある日突然やってきます。   • AWS側の設定が変わったり、コンソールから他のメンバーがAWSリソースをいじったり  
「terraform plan」はコードと実態・stateの中身を比較して差分を検出するコマンドです。   • 差分とは読んで字の如く、コードが実態やstateの内容と乖離していることを示します。   • IaCの本旨は「いつでも」「どこでも」「何個でも」簡単に意図したインフラをプロビジョニングできるところにあります。   差分が大量にできたTerraformは誰も触りたくないので、Terraform以外から手を加え始めます。   • これを人は【Terraform恐怖症の悪循環】と呼びます。  ◦ 避けるべき状態     こうなるとせっかく導入したTerraformが本当に無駄になってしまうので、毎日Planを実行して差分を検出 → 修正をしましょう。   ※参考「O'Reilly Infarastructure as Code  オートメーション恐怖症の悪循環」

毎日Planを実行するだけ、  簡単でしょ？ 

あなたも今日からTerraform警察󰠕 

差分を摘発せよ！ 

つぎ 

terraform importとData Sourcesを活用する  • Terraformに慣れていない状況でいきなり全てのリソースをTerraformから作成するのは非常に難しいです。   ◦ いきなりIaCを強要すると、インフラに触りたくなくなり、PHPer（アプリケーションエンジニア）とインフラの距離はより拡大します。  •
新規作成するリソースに関しては  ◦ コンソールから作成  ◦ Terraformへの取り込み  の順で実行して、無理なく稼働中のリソースにTerraform導入をしましょう。   ※ 既にTerraform管理下のリソースの設定変更はコード側からやりましょう、そうしないとIaCとしての意味がないです。   • Terraformには、Terraform外で作成されたリソースを管理下に置くための「terraform import」コマンドがあります。    

terraform import  `terraform import`の使い方は基本的に以下のとおりです。   1. リソースをコンソールから作成する。   2. importコマンドを実行する。
  3. リソースの実態に合わせてstateが更新される。   4. 更新されたstateにコードを合わせる。  

terraform import  `terraform import`の使い方は基本的に以下のとおりです。   1. リソースをコンソールから作成する。   2. importコマンドを実行する。
  3. リソースの実態に合わせてstateが更新される。   4. 更新されたstateにコードを合わせる。   簡単！！！😁 

Data Sources  Data Sourcesとは？ 

Data Sources  Data Sourcesとは？  要するに、リソースの依存関係を解決するためにすごく便利なやつ。  

Data Sources  例えば、サブネットを新規で作りたいケースを考えてます。  

Data Sources  • 公式Documentのaws_subnetを見に行く   ◦ Argument Reference にはvpc_idがrequiredとなっている  
◦ vpc_idは各VPC毎に割り振られるランダムな値。   ◦ つまり、本来サブネット作成時にはこのvpc_idがTerraform側から参照できる状態でなければならない  

◦ vpc_idは各VPC毎に割り振られるランダムな値。   ◦ つまり、本来サブネット作成時にはこのvpc_idがTerraform側から参照できる状態でなければならない   • しかしサブネットを作成したいときに、VPCがTerraform管理されているとは限らない。   ◦ また、Terraform管理されていたとしても、同じState（≒ 参照可能な範囲）に存在しないケースも多々ある。  

◦ vpc_idは各VPC毎に割り振られるランダムな値。   ◦ つまり、本来サブネット作成時にはこのvpc_idがTerraform側から参照できる状態でなければならない   • しかしサブネットを作成したいときに、VPCがTerraform管理されているとは限らない。   ◦ また、Terraform管理されていたとしても、同じState（≒ 参照可能な範囲）に存在しないケースも多々ある。   ◦ 実は文字列でvpc_idをハードコーディングしても動作はするのだが、それはそれで微妙  

Data Sources  • そんなときに便利なのがData Sources   こちらのコードは、Terraform管理されていないAWSアカウントのデフォルトVPCを参照するときに使えるコード。  

Data Sources  • そんなときに便利なのがData Sources   こちらのコードは、Terraform管理されていないAWSアカウントのデフォルトVPCを参照するときに使えるコード。   • 本来同じStateで管理されていないと参照できないような値も、Data
Sourcesを使うことでTerraform管理する（≒ importする）前から、管理下のリソースと同じように参照できる。   ◦ 私はimportする時に、 ALBやCloudFrontなど変更の入る予定の多いものから段々とimportすることをオススメしています。  ◦ その時、ALBやCloudFrontが依存しているリソースに気を取られることなく、目当てのものをimportするために Data Sourcesは非常に役立ちます。   ▪  

Data Sources  • そんなときに便利なのがData Sources   こちらのコードは、Terraform管理されていないAWSアカウントのデフォルトVPCを参照するときに使えるコード。   • 本来同じStateで管理されていないと参照できないような値も、Data
Sourcesを使うことでTerraform管理する（≒ importする）前から、管理下のリソースと同じように参照できる。   ◦ 私はimportする時に、 ALBやCloudFrontなど変更の入る予定の多いものから段々とimportすることをオススメしています。  ◦ その時、ALBやCloudFrontが依存しているリソースに気を取られることなく、目当てのものをimportするために Data Sourcesは非常に役立ちます。   ▪ （注意）Data Sourcesは参照できるだけで依存先がコード管理されているわけではない  

依存関係を（ほとんど）気にせずTerraformは導入できるんです。 

できそうじゃない？ 

つぎ 

IaCにもCI/CDパイプラインを構築する  • バージョン管理システムを使いたい   ◦ GitHubのPull Requestなどで変更のレビューなんかできると最高ですよね   ◦ インフラに自信のないPHPer（アプリケーションエンジニア）たちでも、レビュワーに強い人を当ててレビュー依頼していきましょ
う！  • CI/CDパイプラインも作りたい   ◦ GitHub ActionsなのかCircleCIなのかCodeBuildなのか、それはなんでもいい気がする。   ▪ 大切なのは、GitHubのメインブランチ（みんなが参照できるコード）とStateの差分が生じていないこと   ◦   ▪   ▪   ◦   ◦ ここが一番大変かもしれませんが、運用を楽をするための苦労だと思って走りきりましょう。  

う！  • CI/CDパイプラインも作りたい   ◦ GitHub ActionsなのかCircleCIなのかCodeBuildなのか、それはなんでもいい気がする。   ▪ 大切なのは、GitHubのメインブランチ（みんなが参照できるコード）とStateの差分が生じていないこと   ◦ ローカルのApplyは甘えです   ▪ ローカルでApplyするってことは、オペミスがあったらメインブランチとStateに差分があるってことになる   ▪ みんなが見れるコードが差分ありの状態ってIaCの意味ないよね…？   ◦   ◦ ここが一番大変かもしれませんが、運用を楽をするための苦労だと思って走りきりましょう。  

う！  • CI/CDパイプラインも作りたい   ◦ GitHub ActionsなのかCircleCIなのかCodeBuildなのか、それはなんでもいい気がする。   ▪ 大切なのは、GitHubのメインブランチ（みんなが参照できるコード）とStateの差分が生じていないこと   ◦ ローカルのApplyは甘えです   ▪ ローカルでApplyするってことは、オペミスがあったらメインブランチとStateに差分があるってことになる   ▪ みんなが見れるコードが差分ありの状態ってIaCの意味ないよね…？   ◦ 私と約束した「毎日のPlan実行」もCIツールで自動化したいですね   ◦ ここが一番大変かもしれませんが、運用を楽をするための苦労だと思って走りきりましょう。  

う！  • CI/CDパイプラインも作りたい   ◦ GitHub ActionsなのかCircleCIなのかCodeBuildなのか、それはなんでもいい気がする。   ▪ 大切なのは、GitHubのメインブランチ（みんなが参照できるコード）とStateの差分が生じていないこと   ◦ ローカルのApplyは甘えです   ▪ ローカルでApplyするってことは、オペミスがあったらメインブランチとStateに差分があるってことになる   ▪ みんなが見れるコードが差分ありの状態ってIaCの意味ないよね…？   ◦ 私と約束した「毎日のPlan実行」もCIツールで自動化したいですね   ◦ ここが一番大変かもしれませんが、運用を楽をするための苦労だと思って走りきりましょう。   大切なのは、  アプリケーションコードと同じようにインフラのコードも扱うこと 

つぎ 

tfmigrateを導入する  • tfmigrateについては作者の方のQiita記事があるので詳しくはそちらへ  ◦ Terraformのstate操作をgitにコミットしたくてtfmigrateというツールを書いた  • 導入すると、`terraform state mv`や`terraform import`のようなstateを操作するコマンドも、Gitの履歴に残せるようになる。 
◦ 最初少人数でTerraformを使っているときはあまり気にならないが、みんながTerraformを触るようになると上記のようなStateを編集するコマンドをローカルで実行してしまうと、他の人のローカルコードとの間に差分が発生してしまう。  ◦ そもそも、`state mv`や`state rm`コマンドもstateを編集するコマンドでインフラリソースに影響があるのでGit管理してコードレビューなどをできるようにしたい。 

tfmigrateを導入する  • 導入のメリット  ◦ tfmigrateは内部で「terraform plan」が` no changed`、つまり差分なしになることを要求する。  
▪   ◦ state操作をする際、以前の履歴がコードで残っているので参考にしてstate操作が可能になる。   ◦ 実際のstate操作ではなくコードを書いてコードレビューというフローにすることで、敷居が下がる   ▪  

▪ remote stateの変更によるリソースの変更がないことを担保できる。   ◦ state操作をする際、以前の履歴がコードで残っているので参考にしてstate操作が可能になる。   ◦ 実際のstate操作ではなくコードを書いてコードレビューというフローにすることで、敷居が下がる   ▪  

▪ remote stateの変更によるリソースの変更がないことを担保できる。   ◦ state操作をする際、以前の履歴がコードで残っているので参考にしてstate操作が可能になる。   ◦ 実際のstate操作ではなくコードを書いてコードレビューというフローにすることで、敷居が下がる   ▪ 詳しくない人でも「やってみた！」ができる環境づくり。  

▪ remote stateの変更によるリソースの変更がないことを担保できる。   ◦ state操作をする際、以前の履歴がコードで残っているので参考にしてstate操作が可能になる。   ◦ 実際のstate操作ではなくコードを書いてコードレビューというフローにすることで、敷居が下がる   ▪ 詳しくない人でも「やってみた！」ができる環境づくり。       前章の内容と絡めて、  • tfmigrate plan  • tfmigrate apply  まで一気通貫したCI/CDパイプラインになるともう怖いものはなくなります。   

まとめ  • Terraformの導入は怖くないです。  ◦ 本当に怖いのはインフラが壊れたときにそれを直す術がないことです。  • IaCが目的になるのは良くないので、「自分たちがIaC管理したい！」と思うリソースから一つずつコード化していきましょう。  • 個人的にはコンソールからのリソース作成・編集・破棄を完全に禁じるのは微妙だなと思っていま
す。  ◦ ぶっちゃけコンソールからの方が操作が早くて容易なことは多々ある。  ◦ 差分ができることは悪ではありません、差分を放置してなぜその状態にあるのか皆が忘れてしまう状態なのが悪なのです。  • 私との約束を覚えていますか？ 

まとめ  • Terraformの導入は怖くないです。  ◦ 本当に怖いのはインフラが壊れたときにそれを直す術がないことです。  • IaCが目的になるのは良くないので、「自分たちがIaC管理したい！」と思うリソースから一つずつコード化していきましょう。  • 個人的にはコンソールからのリソース作成・編集・破棄を完全に禁じるのは微妙だなと思っていま
す。  ◦ ぶっちゃけコンソールからの方が操作が早くて容易なことは多々ある。  ◦ 差分ができることは悪ではありません、差分を放置してなぜその状態にあるのか皆が忘れてしまう状態なのが悪なのです。  • 私との約束を覚えていますか？  毎日、「terraform plan」を実行してくれぃ！！！󰢛 

参考文献  • 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    

PHPerもIaCを使おう！ 17年物のインフラをTerraformに大移行

PHPerもIaCを使おう！ 17年物のインフラをTerraformに大移行

More Decks by kensho

Other Decks in Technology

Featured

Transcript