Plannning-Venue Advent Calendar 2021の3日目です。
terraformでAWSリソースを作成、管理して来た中での所感です。
何でもかんでも管理しようとすると結構めんどくさいことがあるのである程度の線引はあってもいいかな？という記事です。
その中でいくつか紹介していきたいと思います。
タグ
作ったは良いけど誰か(言及しないけど...)がタグを追加するわ消すわでtfファイルと整合性が取れなくなることが日常茶飯事でした。
都度importしても良いですが、物によってはタグ自体を管理しないという選択もアリです。
ignore_changes = "管理したくない対象"
といった書き方をしてあげれば、リソースに変更があってもterraformさんが無視してくれます。
lifecycle {
ignore_changes = [tags]
}
Lambda@Edge
CloudFontと併用するサービスですね。
basic認証を掛けたりX-Frame-Optionsヘッダを追加するあたりが定番でしょうか。
Lambda@Edgeをterraformで作成すること自体は特に問題ない(後ろ便利まである)のですが 、削除になると話が変わってきます。
結論から書くとdestroy一回では来てくれません。そもそも作成したLambda@Edgeを削除するなんてそうそう無かったりしますが...
destroyしようとするとこのように怒られます。
Error: error deleting Lambda Function (basic): InvalidParameterValueException: Lambda was unable to delete arn:aws:lambda:us-east-1:****:function:basic:2 because it is a replicated function. Please see our documentation for Deleting Lambda@Edge Functions and Replicas.
{
RespMetadata: {
StatusCode: 400,
RequestID: "39cac4e5-f28d-4160-ad76-********"
},
Message_: "Lambda was unable to delete arn:aws:lambda:us-east-1:****:function:basic:2 because it is a replicated function. Please see our documentation for Deleting Lambda@Edge Functions and Replicas."
}
原因としてはエッジロケーションに実行する関数のレプリカが存在しているからです。
レプリカがCloudFrontから外れたタイミングで削除依頼が出され、実際に削除されるまでに結構時間がかかるようです。
ということで一回destroyして、エラー吐かれた後しばらく待ってからもう一回destroyといった手順が必要になります。
Storage Gateway
詳細は以下の記事にまとめているのでざっくり書きますが、
Storage Gateway用のインスタンスがprivate subnetにある場合、
storage gatewayとして使用するためにアクティベートキーを取得するためにtfファイル群を２つ用意してapplyを2回叩く必要があります。
Route53とACM
そもそもインフラをコードで書く(Infrastructure as Code)メリットはその再現性にあります。
また、コードを書く時間とコストが発生します。
Route53やACMをterraformで作成しようとすると結構沢山のコードを書く必要があります。
全部terraaformで管理する必然性があるのであれば致し方なしですが、この２つはコードを作成するその時間に対してGUIでの作業量が非常に少ないので
これらはterraformで管理するか否かの線引がいるかなと感じています。
実際、私はこの２つに関してはほぼterraformで管理していません。
(一度作成してみましたが、これわざわざterraform化しなくても...といった状況になった事がありました)
リソース沢山一気に作るツールとして使う
個人的にはこの用途で使用することが一番多いです。
検証用の環境をVPCからEC2その他RDSやらS3と、テンプレ化しておけばいつでもapply一発で検証環境が立ち上がります。
検証が終わったらdestroyしてしまえば良いので不要リソースの消し忘れで余計なコストがかかる心配も無しです。
また、似たようなリソースを沢山作成する場合、aws cliコマンドを使ってスクリプト回すよりも利便性が高い場合もあります。
先日Storage GatewayのVMインスタンス移行をしましたが、事前に検証環境でクライアントと同じ環境をterraformで作成し。
それをクライアント環境向けにkey/sec等々帳尻合わせをして当日は一発apply、動作確認してハイ終了。ダウンタイムを大幅に短縮することが出来ました。
このような感じで、terraformにおけるInfrastructure as Codeとしての恩恵はstateの管理だけではないということですね。
まとめ
terraformは超便利!!だけど何でもかんでもterraform化すればいいってわけでもないよという記事でした。