はじめに
Pragmatic Terraform on AWS、控えめにいって神本です。
— nari@エンタメ系エンジニア (@fukubaka0825) June 1, 2019
AWSの知識がある程度ある人が、IaC入門するのに最適すぎる。
今週中にやり終わりそうなので、金曜あたりにレポ書きます。
予定より、ちょっと遅くなってしまいましたが、宣言通り書評書いていこうと思います。。
ただただ「Pragmatic Terraform on AWS」を褒めちぎるだけの記事になってしまうことをご了承ください。。
こんな人にオススメ
- AWSの知識がある程度あって、IaC(Infratecture as Code)に入門してみたい人
- 他のIaCのツール(CloudFormationとか)を使っていてterraform使ってみたい人
**AWSもIaCも全くわからん、、**だとちょっと進めるのが辛いかもしれません。
逆にAWSある程度触ったり、資格の勉強で包括的に知識を入れていたりすると、復習にもなるし
「GUIでぽちぽちやってよくわかってなかったけど、裏ではこんなリソースが出来ているのか」
と整理もできる内容になっています。
現場でAWS使ってないし全然触ってないんだよね、って人はAWS資格の勉強でもしてから取り組むといいかも知れません。
その際のおすすめ記事(宣伝):３週間でAWS認定ソリューションアーキテクト-アソシエイト-とったので、勉強法などまとめてみる - Qiita
著者様
KOS-MOS様
twitter:tmk.com
お買い求め先
【ダウンロード版】Pragmatic Terraform on AWS - KOS-MOS - BOOTH
該当本の目次
第1章 はじめに
第2章 インストール
第3章 Terraformの基本
第4章 全体設計
第5章 権限管理
第6章 ストレージ
第7章 ネットワーク
第8章 ロードバランサとDNS
第9章 コンテナオーケストレーション
第10章 バッチ
第11章 鍵管理
第12章 設定管理
第13章 データストア
第14章 デプロイメントパイプライン
第15章 SSHレスオペレーション
第16章 ロギング
第17章 構造化
第18章 Terraformベストプラクティス
第19章 AWSベストプラクティス
第20章 モジュール設計
第21章 落ち穂拾い
第22章 巨人の肩の上に乗る
1~3章でTerraformの基礎を学び、4章~16章でDocker化したWebアプリケーションをAWS上に作っていき、１７章〜２２章で大規模なシステムでのterraform運用のノウハウや基本的な設計の考え方を学んでいきます。
今から始める方は、もうTerraform 0.12.0-rc1が正式リリースされているので以下の注意点は問題ないかと思いますが、一様著者様の注意喚起のリンクを載せておきます。
『Pragmatic Terraform on AWS』のハマりどころと回避方法 #技術書典 - 憂鬱な世界にネコパンチ！
「Pragmatic Terraform on AWS」のココがすごい
1. 全てのsampleコードがgithub上に存在する
たまにソースコードの共有がない本(特に同人本）がありますが、部分的にコピペしたいときに辛い。。
しかもterraform0.11と0.12のバージョンどちら用にもサンプルコードを用意する聖人っぷり。。。徳積みすぎです。(この本の出版の時にまだ0.12が正式リリースされていなかった)
2. 読者への読みやすさへの配慮がえげつない
細かすぎて伝わらない『Pragmatic Terraform on AWS』を読みやすくする技術 #技術書典 - 憂鬱な世界にネコパンチ！に詳しく書かれているんですが、僕が特に感動したのが以下の二点です。
- 単語が途中で改行されていないので、変な煩わしさが皆無
- 表記上改行されているだけのソースを、わかりやすくつながりを矢印で表しているので、変なエラーの発生を防いでくれている
脳のリソースをコンテンツだけに集中させる工夫が随所に詰まっていて、「これ、本当に同人誌か？」となりました。
3. terraformやAWSのベストプラクティスやモジュール設計の話まで学べる(具体的なハンズオンに終始しない)
だいたいこういうハンズオン系の本は、簡単な小規模のケースを紹介して終わり、なことが多いですが、正直IaCを一人で小規模でやるってまぁそんな機会はないですよね(個人開発でそこまでやるか？って感じですし)
17章以降の設計やベストプラクティスの章では、大規模なシステムでのIaCのハマりどころから基本的な設計の考え方まで非常にわかりやすく整理されています。
なので、一回16章まで通してはいおしまい、ではなく、折にふれて読み返す本になりそうです。
(自分も技術書を出すときは、そういうものが書きたいものですね、、、でも次出すやつは具体に終始しそうだ、、笑)
4. 扱っているAWSサービスの幅広さ
目次を見ていただいたら分かる通り、基本的なWebアプリケーションに必要なインフラほぼ全般のサービスについてふれています。
基本のVPCやS3やRDSやRoute53やELBはもちろんのこと、ACMやKMS、SSMまで。極め付けに、Session ManagerによるSSHレスオペレーティングまで(これ、sshできないコンテナ運用の調査でめちゃくちゃ重宝しそうだ、知らなかった）。なかなか体系だって学習しずらいログ周りの話もまとまってます。(CloudWatch LogsやKinesis Data Firehose）
ECSによるコンテナオーケストレーションやCodePipelineでのCI/CDなんかは結構色んな本が出てきてますが、コンテナ運用するんだったら使うよね、ってサービスにまで言及しているのは痒い所に手が届きすぎて逆に嫉妬しそうです。(嘘です、本当にありがとうございます)
上記のように、terraformの学習にとどまらず、そういえば気になってたけど全然試せてなかったなと思うサービスを使うきっかけをくれる本にもなってると思います。
終わりに
触発されて、IaCについて思いを巡らせるようになった
学習を進めてく中で、terraformやCloudFormationで本当に**開発~本番全部のインフラリソース管理できてんのみんな、、、**という気持ちが少し拭えなかった。
そんな中 この発表資料を読んだりしながら、ROIを考えながら全てをIaCしなくてもいいよねと考えられると、少し気持ちが楽になると思った。(もちろん、これはなんでコード化してないんだっけみたいな部分は全体で共有しながら(これはこの本でも書いてある))
以下のような、既存のインフラからtfファイルをexportしてくれるようなツールも追いかけていく必要もあるかも。
GitHub - dtan4/terraforming: Export existing AWS resources to Terraform style (tf, tfstate)
GitHub - GoogleCloudPlatform/terraformer: CLI tool to generate terraform files from existing infrastructure (reverse Terraform). Infrastructure to Code
また、今回のAWSSummitで、CDKがインフラをymlではなくappの言語で管理できるように進化していく(pulumiと同じ思想)という話(その時のレポがこちら)があり、そういう進化をしていくとより開発チーム全体としてスムーズにIaCの意識を上げていけれそうだなと思ったりしました。
これからそういった部分も含めて、terraformやIaCを学習していきがら、プロジェクトにも積極的に取り入れていったり、知見がたまったら社内布教もしていきたいですね。
技術書書いてみたくなってしまった
申し込みました！当選したら「GoとAWS Aurora ServerlessとSAMで本格slack botを作ってみよう」的な内容で書こうかなぁと思ってます。
— nari@エンタメ系エンジニア (@fukubaka0825) June 14, 2019
技術書典7にサークル「服バカ」として参加申込をしました！ #技術書典 https://t.co/iQ5ab43fp6
前回の技術書典6が初参加(買い手側として)だったんですが、こういう本を通してある技術やトピックに踏み入れるきっかけ作りができたりするのって、素敵だなと思わされました。
ここまでのクオリティのものは作れないかも知れないですが、誰か一人のきっかけでも作れたら最高じゃんと思い次の技術書典申し込んでみました。
(でも、なんで表紙バベルの塔なんだろう、、バベルの塔のように途中で崩れない戒め、反面教師としての象徴なのだろうか（深読みしすぎ))
余談
僕自身も思っていることですが、人事にもどんどんエンジニアが発信していく組織にしていきたいと言われたので、僕自身は
— nari@エンタメ系エンジニア (@fukubaka0825) June 14, 2019
- 必ず週一でQiita Organizationに投稿する
- 社内で投稿へのリアクション がしやすい仕組みを作る
ことをやっていこうと思ってます。
前の記事でお話しした、うちの会社を**「発信していく組織にしていく」**をテーマに、自分がとりあえずやろうと思ってる施策は以下の2つです。
- 自分自身がQiitaに毎週1本は記事をあげる
- 社内で記事の投稿者へのリアクションがしやすいように、interactive message slack botを開発(例えば、ワンボタンでリアクションが取れる、次書いて欲しい記事の要望が送れる、などなど)
うちではこんなことやってますよ〜なんてことがあれば、ぜひ教えて欲しいです！
アイデアお待ちしております。