「JAWS-UG名古屋 プロビジョニングを語る」に参加してきました。
こんばんは、一般男性です。みなさんハッピーオートメーションしてますか??
書く書くと言いつつ前回の投稿から約1ヶ月半・・・
習慣が無いとは恐ろしいものです。時間が過ぎるスピードも。
本日は、JAWS-UG名古屋さん主催のイベントに参加&登壇してきました。
イベントページを見た瞬間、
名古屋でプロビジョニング(や自動化)の勉強会!?
CloudFormation, Terraform, Ansibleを語る!?
Ansible語っていいの!?
とテンションが上がってしまい・・・
即運営の方に連絡を取り、登壇枠を頂きました。
レポート
アジェンダ
- CloudFormation 基礎
- by JAWS-UG 名古屋 Katzさん
- CDKのお話
- by JAWS-UG 名古屋 川路さん
- 「Ansible x AWS x Windows」を組み合わせたプロビジョニング系の話
- by Ansibleユーザー会 後藤さん(わたくし)
- Terraformを使ってAWSをやってみる
- by JAWS-UG 名古屋 森 久由生さん
- Pulumiを本番投入して感じた所感
- by 株式会社エイチームライフスタイル 橋本尭明さん
- CloudFormationで始めるECSの運用性改善、なぜAnsibleをやめたのか
- by JAWS-UG名古屋 杉本さん
CloudFormation 基礎
JAWS-UG 名古屋 Katzさん
- 会場内はCloudFormation(CFn)初心者の方が多かった
- CFnを使ってよかったところは、環境をコードに落としていく過程で構成を理解することができたこと。
- CloudFormerを使えば、既存環境を「ある程度」CFn化できる
- インフラ(クラウドのリソース)はCFnで構築、OSより上はAnsibleを利用している
なるほど!と思ったことは、「コードに落とすことで構成を理解できる」という点でした。
コードに落とす過程で構成を紐解いていくため、なんとなく眺めているよりも遥かに理解が進む印象です。
もちろん、コード化するのにそれなりに時間(コスト)が掛かりますが・・・。
あまり語られないメリットだな、と思いました!
CDKのお話
JAWS-UG 名古屋 川路さん
- CDKは2018.08にリリースされたばかり
- CDKとは、AWSのリソースをプログラムで定義して、それを実行することでデプロイをするもの
- リリースされたばかりだが、2019/7/12にGAされた!
- GAされたため、今後はぶっ飛んだ更新は無さそう(安堵)
- CDKは複数のプログラミング言語(TypeScript, JavaScript, Pythonなど)に対応している
- CDKは変数の柔軟性がCFnより上、CFnは変数というよりかは「定数」
- CFnはコードレビューが辛い、デプロイして出来上がった環境を見た方が楽
- CDKは実行前に「わかりやすく」差分が見える
- cdk diff コマンドを実行する
- CDKからCFnテンプレートを出力可能
- cdk synthコマンドを実行する
CDKのことは全然知りませんでした。
複数のプログラミング言語に対応しているから、プログラミングが得意な方には有用なものだと感じました。
慣れ親しんだ言語が対応していれば、より使いやすそうですね。
CDKの登場により、開発者がよりインフラを構築、管理しやすくなったなと思います。
「Ansible x AWS x Windows」を組み合わせたプロビジョニング系の話
私のセッションです。
20分枠でしたが、ゆっくり話せば1時間は語れるようなボリュームでした。
もう少し切り取って話せばよかったなと、少々反省。
少しでも、Ansible AWX(Tower)の良さ、便利さを知っていただければな、と。
好みや組織文化、開発・運用スタイルにもよると思いますが、やはり運用していく上でGUIは便利ですし、必要だと感じています。
誰でも実行できるボタンのようにプロビジョニング(自動化)の仕組みを用意しておけば、誰でも利用可能状態、サービス化された状態を実現できます。
内容をもう少し充実させれば、ハンズオンができるシナリオかな〜〜〜、という妄想はしています。
Terraformを使ってAWSをやってみる
JAWS-UG 名古屋 森 久由生さん
- Infrastructure as Code(IaC)は安全かつ効率的にインフラを構築するもの
- Terraformが対応しているプロバイダは160ほどで、IaaSはAWS、SaaSは別のもので構成する、みたいな定義も可能
- CFnとの違い
- CFnはYAMLなどで記述するため、プログラムチックではない(どちらかといえばCLIっぽい)
- Terraformは独自言語HCLでオブジェクト指向言語っぽい書き方ができる
- Terraformのツラミ
- リリースされたばかりのサービスに対応できない・・・
- GUIでポチッとすぐにできるリソースでもコードを書かないといけない
- 独自言語ゆえに学習コストがそこそこかかる
- コードの保守が死ぬほど大変
- 独自言語であるため、久々にコードを見ると忘れている
- どこまでをTerraformに任せるかが大事で、頻繁に変更しないリソースや、作成頻度が低いものが除外してもいいかも
「安全」というのは案外、見落とされがちな点だと思っています。
人手でなんとかするのではなく、仕組みでなんとかした方がいいですよね。
Terraformは興味はあったものの、未だに手を出せていません。
Terraformのツラミにはとても共感でしました。特にコードの保守に・・・
どうすればTerraformおじさんを生まずに済むのか・・・
実際にTerraformのコードを見せてもらいましたが、一目で「これは大変だ・・・やばい・・・」と感じました。
Pulumiを本番投入して感じた所感
株式会社エイチームライフスタイル 橋本尭明さん
- 橋本さんはインフラエンジニアではなくアプリケーション開発者で、以下の理由からプロビジョニングツールを使い始めたとのこと
- インフラの知識があればもっと楽にできるのでは・・・?
- GUIポチポチをしたくない
- 再現性担保したい
- バージョン管理したい
- PulumiはTerraformやCFnと比較して、独自言語を覚えなくていい
- 独自言語を使用するツールを触りたくなかった
- 使い慣れた言語でインフラを立ち上げられることがメリット
- Pulumiを使ってよかったこと
- Webエンジニアから能動的にインフラを扱いやすくなった
開発者の方からすると、使い慣れた言語を利用できるメリットは大きいようですね。
コード化する際もそうですし、レビューする際にも読みやすそうな印象です。
組織でよく使われている言語を用いれば、より浸透しやすそうです。
Webエンジニアの方でもインフラを触りやすくなった時代、インフラエンジニアとして、今後どうしていけば価値を生み出せるのかを考えさせられる内容でした。
CloudFormationで始めるECSの運用性改善、なぜAnsibleをやめたのか
JAWS-UG名古屋 杉本さん
- サービスをAWSに移管する際にAnsibleを利用した
- 既存環境を読み解いてPlaybookを作成、その際はベンダーロックインを避けるため、マネージドサービスをコード化の対象外とした
- Ansibleで行き詰まったこと
- 知見がない状況で書いたPlaybookは冪等性は低かった
- 社内で共用してるPlaybookを変更したら、他のプロジェクトで影響が出る可能性があるため、手を出せなかった
- リファクタしたけど運用を統一できず、ルールが崩壊していた
- ECSを運用し始めた理由
- 環境差分を少なくしたかった
- 極力インフラの面倒を見たくなかった
- Docker触ってみたかった
- ECSの運用を安定化させるため、CFnのスタックテンプレートを利用した
- 新規サービスはDocker運用を前提とした開発方針にしたため、Ansibleをやめた
- カオス運用を避けるために本番環境でのAnsible利用はやめたが、コンテナではない開発環境ではAnsible利用している
あ、Ansibleやめちゃったんですかー?!(心の声)
というのは置いておいて。
開発スタイル的にも、AnsibleではなくECSで構成された環境が合うのだなと感じました。
Ansibleは多くのことができるツールですが銀の弾丸ではないので、開発スタイルや組織文化に合わせて使い分けていくことが重要だと思っています。
適材適所、というやつですね。
おわりに
初めてCodeBase Nagoyaさんにお邪魔しました。
会場もとても綺麗で、設備も充実・・・名古屋にこういった場所が増えることは、とても嬉しいことです。