In a simple Terraform configuration with only one root module, we create a flat set of resources and use Terraform's expression syntax to describe the relationships between these resources: resource "aws_vpc" "example" { cidr_block = "10.1.0.0/16" } resource "aws_subnet" "example" { vpc_id = aws_vpc.example.id availability_zone = "us-west-2b" cidr_block = cidrsubnet(aws_vpc.example.cidr_block, 4,
PackerBuild and manage images as code
Terraform小ネタ集。 手元の terraform version は v1.0.7 です。 Tips & Tricks 特定のリソースだけ別のリージョンを使いたい（1つのtfのなかで複数のproviderを利用する） alias を使いましょう。 provider "aws" { region = "ap-northeast-1" } provider "aws" { # Usage (in data, resource): # provider = aws.us_east_1 alias = "us_east_1" region = "us-east-1" } 一時的にstate backendをlocalにしたい override.tf を使いましょう。 .gitignore に入れておくといいかな。 必要に応じて terraform init -reconfigure しまし
Terraform を使うとインフラの構成がコード化される、Infrastructure as Code (IoC) という利点があります。そして、Terraform をある程度使っていくと、ソフトウェア開発と同様に 「秘密情報をコードに直接書かないためにどうすれば良いか」 について考える必要が出てきます。 本記事では、Terraform で秘密情報を扱う方法や注意点など、雑多な話題について書いていきます。 なお、書いているうちに、以下のページの内容と似ているなと思ったので、なるべく違う視点からの内容を書こうと思います。 A comprehensive guide to managing secrets in your Terraform code | by Yevgeniy Brikman | Gruntwork 基本的な注意点 tf ファイルなどに秘密情報を直書きしない *.tf ファ
はじめに 在宅が始まってからやる気が出ない&職場も変わり忙しいかったと言い訳ばかりで久しぶりの投稿です。 本題ですが、最近AWS上にKubernetesをTerraformで構築するプロジェクトに参加してました。その中で秘匿情報を構築資材内から排除しようという流れになり、AWS Secrets Managerを使用することになりました。流れとしてTerraformから登録することになり調べて実装したので書き残しておきたいと思います。 環境 $ terraform --version Terraform v1.0.1 on linux_amd64 + provider registry.terraform.io/hashicorp/aws v3.48.0 資材 variable "my_secrets" { default = { key1 = "secret_value1" key2 =
Terraform の CI/CD を改善する tfcmt というツールを紹介します。 ちなみに HashiTalks JP 2021 でも紹介しています。 執筆時点で最新バージョンは以下のとおりです。 tfcmt: v3.0.0 github-comment: v4.0.1 tfnotify: v0.7.0 tfcmt は terraform plan, apply の結果を GitHub の Pull Request (以下 PR) にコメントとして通知する CLI ツールです。 態々 CI のログを見にいかなくても PR のページで結果を確認でき、 なおかつ素のログに比べて非常に分かりやすいのが特徴です。 tfnotify の Fork ですが、互換性はありません。 自分にとって不要な機能(主に GitHub 以外への通知)を削る代わりに、様々な改善を入れています。 GitHub 以
インフラのプロビジョニングを安全かつ効率的に行うツール マルチクラウドやハイブリッドクラウドの環境では、サービスやシステムごとに異なる管理方法やインターフェイスになるため、属人化や煩雑さが課題となります。 Terraformの導入により、オンプレミスやクラウドを問わず、さまざまなコンピューティングやストレージ、そしてサービスのプロビジョニングが自動化され、安全かつ堅牢な環境を実現します。 Terraformは、インフラの構成やポリシーをコード化することで、プロビジョニング、コンプライアンス、サービス等といったインフラ管理を、パブリッククラウド、プライベートデータセンタ問わず、自動化する事が可能です。インフラのコード化により、開発者がアプリケーションをビルドするのと同じ方法で、インフラをプロビジョニング、管理できます。検証、テスト、本番環境へのデプロイを自動化することで、手作業による人為的エ
マイグレーションの履歴を記録することで、マイグレーションファイル名を省略して、単に tfmigrate plan や tfmigrate apply とするだけで、未適用のマイグレーションを適用することが可能になり、よりCI/CDで使いやすくなりました。また履歴モードが有効な場合、 tfmigrate list --status=unapplied で未適用のマイグレーションファイルを列挙することも可能です。 いまのところ storage の種類は s3 と local しか使えませんが、s3 以外のクラウドストレージに保存したい場合は、現状の回避策として local ストレージを使用して一旦ローカルファイルとして保存して、tfmigrate plan / apply の前後で履歴ファイルを自前で同期することは可能です。最新の状況は上記のREADMEを参照して下さい。 tfmigrate自
terraform { required_providers { docker = { source = "kreuzwerker/docker" version = "2.15.0" } } } locals { images = [ { name = "foo", image = "alpine" }, { name = "bar", image = "debian" }, ] } resource "docker_container" "this" { # for_each = local.images ここにmapのlistを渡したいがエラーになる for_each = { for i in local.images : i.name => i } # こう書くのが正しい name = each.value.name image = each.value.image } これ te
data "aws_caller_identity" "current" {} output "account_id" { value = data.aws_caller_identity.current.account_id } 若干補足しておくと、 "${}" 自体が廃止されたわけではなく、今でも文字列の中に変数を埋め込む場合には必要ですが、式が変数の参照しか含まない場合は不要で、v0.13.4以降は冗長な書き方は警告が出ます。ちなみにv0.14のfmtはもう一歩踏み込んで、この書き方を自動で修正するようになりました。古いサンプルコードを雑にコピペできるようになってべんり。 Terraformではなく汎用的なHCLそのものの仕様を調べたいときは、 hashicorp/hcl にありますが、本稿執筆時点ではデフォルトのmasterブランチはまだHCL1であることに注意して下さい。 HCL
Terraform normally loads all of the .tf and .tf.json files within a directory and expects each one to define a distinct set of configuration objects. If two files attempt to define the same object, Terraform returns an error. In some rare cases, it is convenient to be able to override specific portions of an existing configuration object in a separate file. For example, a human-edited configuratio
はじめにこんにちは、TIG DXユニット 1の木村です。 入社以降ずっと触ってきたTerraformですが、巷ではWorkspace派だったり、module派だったり、ディレクトリ完全分離派だったり、様々な流派(プラクティス)が乱立しているのを目にします。私自身ベストな構成を模索していく中で辿り着いた結論は、ケースバイケースで全てのデザインパターンに対応できる万能なものは存在しないのかな (当たり障りないですね..)ということです。 そんなわけで、様々なTerraformの流派を紹介し、各流派がどのようなパターンに向いているのか(はたまた不向きなのか)の個人的見解をまとめてみました。 ※本記事中のサンプルコードはすべて Terraform 0.12、 provider google cloud で解説してます Terraformとは？当社過去記事に解説があります。Terraformの概要や
まずはディレクトリ構成sample/ ├── develop │ └── backend.tfvars ├── production │ ├── backend.tfvars │ └── terraform.tfvars ├── stage │ ├── backend.tfvars │ └── terraform.tfvars ├── main.tf └── variable.tfおおよそ上記構成で、 cd sample/develop terraform init -backend-config .. terraform plan .. terraform apply .. という流れで実施してきました。0.11のときでは、variable.tf をterraform.tfvars でマージしていい感じに動いていたのですが、0.12からはこの挙動が上書きに変わりました
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
