![](https://blog.rurineko.com/wp-content/uploads/2022/04/terraform_overview-e1469271902599-940x535.png)
今は、どこの案件に行っても、だいたい、Ansible使えますか?とか
Cloudformation使えますか?とかTerraform使えますか?って絶対聞かれます。
過去、Ansibleは使った事があって、結構なれてくると便利だとは思っていたけど
なんか、ymlファイルに癖があって、なかなかそれになれるまで凄く苦労しました。
で、最近Cloudが流行ってますよね? 手で構成を作る事ももちろん出来ますが
結局ですよ、同じ構成でVPC切ったつもりにしてても、typoなどで
設定差異が発生したりするんですよ。
で?どうするのって?
そこで、でてくるのが冒頭にも書いた通りのTerraformとか、CloudformationとかAnsibleですね。
コードでかけば、例えば、本番のVPC定義をまるっとコピーして
VPC名やセグメントでバッティングする項目だけ変更すれば、基本的には同じ構成になりますよね?
さらに、AWSの既存構成をまるっとコードに落とせるOSSもある
AWSの構成全体を、定義するのは流行としては、Terraformが多いみたいです。
よって、まずは、テスト的に作成したAWSのVPC環境をTerraform形式のファイルに
設定を落とし込むTerraformerというツールがOSSで配布されているようなので
それをまず使って、まるっとAWS環境の定義ファイルをこっちに持ってきてみます。
まずは、そこまでを直近やってみます。
そして、構成図をサクッと自動生成するツールもOSSである
CloudmapperというOSSのツールがある。
下記の様な物を自動生成するツールみたいだ。
これも、さっきのterrformにあわせて自動生成するように設定しておきたい。
テスト環境でテストしてみようと思う。
![](https://blog.rurineko.com/wp-content/uploads/2022/04/ideal_layout-940x647.png)
だいたいこのような事が出来れば、まあ、インフラ運用は楽になるんではないかと思われる。
ただ、大前提は!?
何でもそうですが、仕組みを作る上で、要件がまとまっていることは大前提。
特にインフラは、通信要件や運用の為の要件がまとまっていないと
いくら良い物を作ろうとしても絶対に作れないし
付け焼き刃で作っても、それが意図した構成かどうか?全く分からない事態が発生する。
よって、例えば、プロダクトを会社ごと買ってきて、その内部仕様なんかが全く無い
状況に置いて、これをインフラを刷新して、新たな物を作り出すなんて事は
Terraformがいくらいいからといっても不可能な事という事になります。
例を出すと、サブネットどうやって切りましょう?
分からないので、こちらとこちら切っておきますね。
この時点で、もはやセキュリティホールにないうる構成の第一歩を踏み出します。
RDSってどこからアクセスされます?
普通は、バックセグメントをきって、そこはインターネット側からのアクセスは
遮断して作るが定説ですが、いやー、どうしてもね、端末からDBつつきたいんですよって
要件があるとするじゃないですか?
サービスを提供する上で、それは流石に脆弱性の固まりじゃないですかね?
結局、そうしなくていい方法を考えないと、結局これで作り出した場合でも
そこにインターネットゲートウェイをサブネットに入れて、外部通信させたり
しなきゃ運用がまわないってなると、なにやってるんだか?ってなりますよね?
今後は特に!?
今までが、インフラは手で構築するのが当たり前の世界だったが、
これからは、インフラもコード化の波が容赦なく押し寄せてきている。
同じ構成のインフラを手で作るのは難しい、コードで作るのは複製して
IPやセグメントなど、バッティングしないように修正して、
ドライランして、問題がないようならデプロイして終わりという事になるのだろうか?
とりあえずは、terrform使った事がないので、とりあえずはそこからですね。
手持ちのAWS環境でテストして行きつつ、動作の確認をしていこうと思います。