「tfstateはTerraform Cloudで管理したいな。どうやって移行すればいいんだろう。」 AWSで Terraformを使っていると、stateファイル管理用のリソース(S3やDynamoDB)が増えてきて管理が大変になることがあると思います。 そんな時はTerraform Cloudでstateファイルを管理すると楽です。 Terraform Cloudで管理することで、stateファイル管理用のリソースを自分で作成する必要がなくなります。 ちなみに、stateファイルの管理自体はFreeプランでも可能です。 今回は、stateファイルの管理をS3からTerraform Cloudに移行してみます。 やってみた 移行前(stateファイルをS3管理) 検証用にstateファイルをS3管理するパターンでAWSリソースを作ってみました。 terraform { required_
ていねいを心掛けたTerraform記事です。スクリーンショット満載でやった気になれます。 Terraformといえばクラウドリソースの作成ですが、この記事ではローカルPC上のリソース作成で済むように工夫しています。 Terraform関連の他の記事は「Terraformのきほんと応用」からどうぞ。 概要 Terraformを運用していくにはtfstateの理解が必要になってきます。tfstateはTerraformによって構築したリソースを記録するためのデータベースです。 この記事では、tfstateの中身を確認したり（テキストファイルです）、tfstateを削除した場合の挙動を確認したりします。 ゴール terraformにおけるtfstateの位置づけを理解する。 必要なもの 作業時間：15分 Terraformを実行できる環境 tfstateとは terraformで意識が向くのは
株式会社MIXIで『家族アルバム みてね』のSREをしているkohbisです。今回はTerraformのリポジトリ構成についてお話いたします。 Terraformとは TerraformとはHashiCorpが提供するIaC（Infrastructure as Code) ツールであり、HCL（HashiCorp Configuration Language）という独自の文法でクラウドやオンプレミスのインフラリソースを宣言的に定義し、管理やプロビジョニングを行うことができます。 TerraformはAPIを通じてプラットフォームやサービス上にリソースを作成します。Terraformは対象とのAPIのやり取りを「プロバイダ」と呼ばれるプラグインに依存しており、Terraformを利用する場合はまずはじめにどのプロバイダを必要とするのかを定義することになります。 プロバイダの一覧はTerraf
ちょっと変わったTerraform moduleを見つけたのでご紹介します。terraform-aws-labelです。 aws-ia/label/aws | Terraform Registry 概要 このモジュールは何もリソースをプロビジョニングしません。 モジュール利用者が使うのはモジュールのアウトプットです。 このモジュールは名前の通り、ラベル、あとタグを提供します。このモジュールの用途は一貫したリソース命名やタグ付与の実現です。 使ってみた 以下のようにモジュールを呼んでみます。 data "aws_caller_identity" "current" {} module "labels" { source = "github.com/aws-ia/terraform-aws-label?ref=v0.0.5" account = data.aws_caller_identity
目的 本物のAWSに触ることなく、Terraformのお勉強がしたい そこで、LocalStackによりローカル環境でAWSのモックを立てて、そこをTerraformでいじることにします。AWSアカウントを持っていない、料金が怖い、本物のAWS環境を壊したくない、等々の事情があっても、Terraformを使った気になることができます。 本記事は極力コマンドやYAMLを書いたりせず、GUIポチポチの割合を増やしお手軽さを重視しました。 目標・方法の概要 目標はシンプルに、Amazon S3のバケット my-tf-test-bucket を作成します。 LocalStackは、ローカル環境でAWSをエミュレートしてくれるものです[1] 。全てのAWSサービス・機能がサポートされているわけではないので注意ですが、基本的な用途では差し支えありません。 TerraformのAWSプロバイダは、もちろ
gitでコミット(commit)前にterraform fmtやtflintを実行したい時はpre-commit-terraformが便利 「ローカルでもterraform fmtやtflint・tfsecの実行を自動化したい。」 terraformにはコードのフォーマットやテストに便利なcliツールやコマンドが色々あります。 (terraform fmt、terarform validate、tfsec、tflint等) ただ、このコマンドを毎回手動で実行するのは面倒です。 CI/CDツール上で実行するのもいいですが、CIで失敗する前にローカルで気づけたらより良いですよね。 そんな時に便利なpre-commit-terraformを紹介します。 pre-commit-terraformとは pre-commitフレームワークで使用できる Terraform の git hook スクリプ
背景 terraform の tfstate の管理ですが、基本的には aws では s3 + dynamodb, gcp であれば gcs を採用することが多いです。 ただ、採用するにあたり、下記の問題があります。 tfstate の管理に関する情報をどこで管理するか tfstate の管理リソースの作成をどこで管理するか 他のプロジェクトでも相乗りしたいときにどうするか terraform cloud に任せるとしても、そのアカウント管理を誰が管理するかといった決めるポイントは多いです。 もし、GitLab で project を管理しているのであれば tfstate も GitLab で管理することを検討してはいかがでしょうか。 やってみた 0. terraform の backend の設定を書く GitLab は http backend で提供しているため、 backend に
以前「TerraformでAWSアカウントを作るのは簡単だけど削除はひと手間かかる」というブログを書きました。 タイトル通り、TerraformでAWS Organizations配下のアカウントを作成するのはaws_organizations_accountリソースを定義してterraform applyするだけなのでチョー簡単ですが、削除はaws_organizations_accountリソースを削除してterraform applyするだけではだめで、色々設定が必要になって大変だという内容です。 ですが、少し前に激アツアップデートがありました。 そしてこの簡単削除機能がTerraformでも利用可能になっていることを知ったのでレポートします。 close_on_deletion flag Terraform AWS Provider v4.9.0でaws_organizations
こんにちは、AWS事業本部コンサルティング部のたかくに（@takakuni_）です。 今回は、tfstateをローカルとS3間で移行してみようと思います。 デプロイをローカルでやっていたが、運用に入ってtfstateをS3に保存したくなったケースもあるのではないでしょうか。 私自身、もしもの時に備えて今のうちに出来るよう備忘録としてやってみようと思います。 フォルダ構成 以下のようなシンプルなフォルダ構成とファイルで、tfstateをローカルとS3間でキャッチボールしていこうと思います。 既に、terraform init,terraform applyは実行済みとします。 mv_sfstate/ |- .terraform |- main.tf |- provier.tf |- terraform.tfstate mv_tfstate/main.tf resource "aws_vpc"
技術部 SRE グループの鈴木 (id:eagletmt) です。クックパッドでは Codenize.tools を用いて様々なリソースをコードで管理してきましたが、現在では大部分が Terraform へと移行しています。Terraform の使い方等については既に沢山のドキュメントや紹介記事があるので本エントリでは触れず、なぜ Terraform へと移行しているのか、どのように Terraform を利用しているのかについて書いていきます。 Terraform 移行の理由 クックパッドでは自分と同じく SRE グループに所属している菅原 (id:winebarrel) によって開発された Codenize.tools のツール群を利用して IAM、Route 53、CloudWatch Alarm、CloudWatch Events 等をコードで管理し、いわゆる GitOps を実践
SREチームの今です。 カヤックでは、クラウドリソースの管理にはTerraformを利用することが多いです。 クラウドリソースの構成や設定をコードで管理することで、リソースの変更内容の差分をレビューできる、意図しない設定変更を発見できるなどの利点があり、SREの目的であるサービスを安定して提供する上で重要な要素の一つです。 実際の作業として、既に運用中のサービスを新たにTerraform管理下に置く場合や、多くのリソースが既にweb consoleから作成されているものをTerraform管理下に追加する場合も多いと思います。 その際にはTerraform importをする必要があります。しかし、Terraform importは単純作業とはいえ時間と手間がかかり、優先順位を下げてついつい後回しにしてしまうことも多いのではないでしょうか。 今回は、手作業でTerraform import
こんにちは！AWS事業本部コンサルティング部のたかくに（@takakuni_）です。 今回は、Visual Studio Codeの拡張機能で、「より身近」にtfsecを体験してみようと思います。 tfsecの基本的な使い方は、以下ブログをご参照ください。 結論 「ローカル」と「身近」を掛けただけです 「ローカルはVS Code、CICDパイプランはCLI」のパターンがオススメ 回避コードの追記がとても便利！ VS Code以外の拡張機能の実装も期待 やってみた 事前準備 VPC周りとセキュリティグループを作成するコードを使用します。 vpc.yaml module "vpc" { source = "terraform-aws-modules/vpc/aws" version = "3.12.0" # insert the 23 required variables here cidr
Terraformの、セキュリティスキャンツールである「tfsec」の触り部分を取り上げました。 簡単なデモもあるため、ぜひご参考にしていただければと思います。 こんにちは！AWS事業本部コンサルティング部のたかくに（@takakuni_）です。 今回は、tfsecを使用して、Terraformのセキュリティスキャンを体験してみようと思います。 結論 tfsecは、Terraformの静的なセキュリティスキャンを行うツール ローカル環境で動作可能な認証情報などを用意しなくていい tfsecとは Aqua Security社の、オープンソースツールです。 ざっくり、ご説明すると、Terraformの静的なセキュリティスキャナーです。 ローカル、CIパイプライン環境で実行できるように設計されています。 いざ実践 インストール 今回は、Macでtfsecを使用してみようと思います。 % brew
はじめにterraform validateやterraform planでは検知できないエラーを見つけるために、TFLintを利用してみました。TFLintを用いれば、例えばインスタンスタイプの誤りや命名規約違反を検知できます。 本記事では、インストールから利用方法までを記載しています。 TFLintとは？いわゆるTerraformのためのLinter。JavaScriptでいうと、ESLintのようなものです。構文やパラメータがルールに違反していないかをチェックしてくれるツールです。 環境やバージョン今回利用した環境です。 Windows10 tflint v0.34.0 tflint-ruleset-google v0.15.0 terraform v1.1.0 ※Terraformがなくてもtflintは動作するので、Terraformは必須ではない Google Cloud tf
ちゃだいん（@chazuke4649）です。 Terraformにて、「このモジュールだけライフサイクルが違う（ほとんど変更しない）」とか「このモジュールだけリソースが多すぎてplan/applyが重すぎる」等々の理由により、stateファイルを分けたい場合があると思います。 今回一部のモジュールだけ別のstateファイルで管理するために、別のディレクトリに移す機会があったのでその流れを紹介します。 やってみた 作業前のディレクトリ構造は以下の通りです。 作業前 % tree . ├── master #移動元 │ ├── scp.tf │ ├── aft.tf │ ├── backend.tf ├── master_aft #移動先 │ └── backend.tf 上記のmaster内のaft.tfに書かれている module "aft" {}だけを、master_af
こんにちは！コンサル部のinomaso(@inomasosan)です。 ECS FargateでFireLensからCloudWatch LogsやKinesis Data Firehoseへのログ出力を、Terraformでコード化したので紹介します。 検証にあたり、弊社の以下ブログを参考にしました。 そもそもFireLensって何？ FireLensは、複数のAWSサービスやAWSパートナーネットワーク(Datadog等)にログ出力することができます。 ECSタスク定義でサイドカーとして起動し、他のコンテナからログドライバーとして使用します。 コンテナイメージにはFluentdとFluent Bitを選択可能です。 今回の検証では、リソース使用率が低く、ログルータに推奨されているFluent Bitを使用します。 2021/11/6時点でFluent Bitでは、以下のAWSサービスに
こんにちは。TIGの伊藤です。この記事は秋のブログ週間2021の3日目です。 はじめに私は普段会社でクラウドをまたいでTerraformを日々書いたり、メンバーに教えたりしています。もはや俗に言うプログラミング言語を書かずにここまで全振りしてきたくらいなので、比較的自信を持ってコードを書いて仕事をしています。 特にここ最近はほぼ1からコード設計をして運用まで持っていくこともあり、「より腐りにくい、より息の長いコード」というものを考えるようになりました。Terraformだからこその「定期メンテを簡易にするためには」「より簡単に変更するためには」をひたすら突き詰めていった結果、アツい気持ちが生まれ、今回は筆を取っています。 そんな私のアツい気持ちをしたためた今回の記事ですが、可能な限り例も添えつつ、いくつか解説できればと思います。公式にも実は載っているような内容もあったりしますが、日本語の記
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
