terraformで入れ子の値を無視（ignore_change）する方法 - Qiita
ignore_changes 基本的な使い方 terraformで、特定の項目をterraformで管理したくない場合、lifecycleのignore_changesが使えます。 The lifecycle Meta-Argument - Configuration Language - Terraform by HashiCorp ドキュメントからの引用ですが、これが基本的な設定の仕方になります。 resource "aws_instance" "example" { # ... lifecycle { ignore_changes = [ # Ignore changes to tags, e.g. because a management agent # updates these based on some ruleset managed elsewhere. tags, ] }
【Terraform】AWSの既存リソースをimportする際にデフォルトのリージョンとは別のリージョンを指定する - Qiita
環境 terraform 1.3.7 provider aws 4.51.0 概要 AWS CloudFrontでは、北部バージニア（us-east-1）のACM証明書しか使えない。 そのため、デフォルトのリージョンを東京(ap-northeast-1)等、北部バージニア以外で設定している場合は、Terraformでの既存リソースimport時にも、ACM用に個別のリージョン指定が必要となる。 今回はデフォルトのリージョンが東京のケースを想定。 初期設定 provider "aws" { access_key = var.access_key secret_key = var.secret_key region = var.region assume_role { role_arn = var.role_arn } } variable "access_key" { description
Terraform職人のためのOpenTofu入門 - Qiita
この記事は クラウドワークス Advent Calendar 2023 シリーズ1 の 4日目の記事です。 はじめに 「父さんな、Terraform職人やめてお豆腐職人で食っていこうと思うんだ」と言いたいだけの @minamijoyo です。 2023年8月HashiCorpはこれまでMPL2のOSSライセンスで公開していた主要製品をBSL(Business Source License)に変更することを発表し、Terraformはv1.6.0からOSSではなくなりました。 このライセンス変更を受けて、OSS版のTerraformを求める人たちで、MPL2時点のコードベースからforkしたOpenTofuの開発が進められています。 HashiCorpのBSLは、実質的に競合他社の商用利用に制限をかけたもので、ほとんどの一般的なユーザに直接的な追加の制限はありませんが、間接的にTerrafo
Terraform だけだとハードモードなので Terragrunt を使おう - Qiita
Terraform はそのままだと管理が大変 みなさん IaC (Infrastructure as Code) してますか？パブリッククラウドをIaCするなら、 Terraform が便利ですね！ しかし、本格的に使い始めると、こういう問題がすぐに出てきます。 複数環境の楽な分け方を知りたい ワークスペースはなんか嫌だ とはいえ、環境間で共通するボイラープレートをどうにかしたい 環境内で適用するモジュールを細分化・分岐したいけど面倒 環境ごとに使うモジュールを切り替えたい テスト環境はAuroraではなく安いRDSにしたい モジュール(tfstate)を分割して小さい範囲で適用したい 大きなモジュールは影響範囲がわからないし、差分計算にそれなりに時間がかかってしまう 分けたモジュールを一括適用するのが面倒 モジュール間の依存関係がわからない モジュール(tfstate)間での値参照が面倒
Terraform で Azure AD アプリケーションをオシャレに定義しようとして諦める - Qiita
Azure AD を扱っていると、やはりどうしても Infrastructure as Code を実現したくなる瞬間が多々あります。そんな時、Terraform の Azure Active Directory Providerを用いるという選択肢は有用でしょう。 便利そうですね！ 使ってみましょう。 私の場合、Azure AD azuread_application という Resource を扱う必要があり、更に今回の用途では、Microsoft Graph API のパーミッションを付与する必要がありました。これの resource_app_id が必要そうです。Graph Explorer で見つけてみましょう。 GET https://graph.microsoft.com/beta/servicePrincipals?$filter=displayName eq 'Micro
Terraformでオレオレ証明書を作ってIaCだけでALBをHTTPS化する - Qiita
はじめに 自分のプロジェクト内部に閉じたALB配下のOSSを使うのに、インターネット経由で平文は不安！だけどローカルなものだし暗号化はしておきたいよね！でもお金はかけたくない！という時のためのオレオレ証明書作成方法。 先に言っておくとおくと、 - マネコンの画面ポチポチができる環境なのであれば、AWS Certificate ManagerのプライベートCA経由でのルート証明書発行がめちゃくちゃ簡単なので、素直にそっちを使った方が良い。どうせローカル利用であれば大した金額にはならない(ACMのプライベートCAは、Terraformではルート証明書の発行までやってくれないので、フルIaCを目指すのであればこの案は採用できない) - 自分でopensslコマンド作ってファイル作って良い環境なのであれば、その方が楽 - じゃあ何のためにやったんだよ…… という内容なので、あまり参考にはならないか
tfupdateでTerraform本体/プロバイダ/モジュールのバージョンアップを自動化する - Qiita
はじめに Terraform職人あらためシニアHCLエンジニア（？）の @minamijoyo です。 最近はHCL(HashiCorp Configuration Language)のパーサで遊んでいます。Terraformの設定をパースしていいかんじに書き換えることができるようになると夢が広がりますよね？ そんな個人的な趣味の産物として、Terraform本体/プロバイダ/モジュールのバージョン制約をいいかんじに一括で書き換えてくれる tfupdate というツールを書いたので紹介します。 これをCIとかジョブスケジューラで流せば、毎日最新版をチェックして、差分があれば自動でバージョンアップのPull Requestを生成したりできます。つまり、「ぼくのかんがえたさいきょうのTerraform版Dependabot」ができるのだ。 ※この記事は クラウドワークス Advent Cale
AWS SSOプロファイルでもTerraformやSAM-CLIを実行する方法 - Qiita
AWS SSOとAWS CLI V2 AWS CLI V2ではプロファイルにAWS SSOフォーマットを選択することができます。 AWS CLI v2 が一般利用可能となりました | Amazon Web Services ブログ [profile abc] sso_start_url = https://your-company.awsapps.com/start sso_region = us-west-2 sso_account_id = 1234567890 sso_role_name = AdministratorAccess region = ap-northeast-1 これにより秘匿情報(secret key)を ~/.aws/credentials へ書く必要がなくなりました。 それだけではなく複数のAWSアカウントをAWS SSOで集中管理している場合は個別のAWSアカ
Terraform で Newrelic の通知設定をする - Qiita
世の中にまるで 3rd party 資料がなかったので書いておく。 参考文献 Provider: New Relic - Terraform GitHub - terraform-providers/terraform-provider-newrelic: Terraform New Relic provider REST API calls for New Relic Alerts New Relic API Explorer Provider (api_key) の設定 New Relic には API Key が３種類ある: REST API Key: Account Settings > API Keys から作成 User API Key: Account Settings > Users and Roles > User > (例: sonots) > API Keys から作
TerraformでGCPのIAMをちょっとだけ上手に管理する - Qiita
背景 権限を付与する google_project_iam_member のリソースの role が配列を持てないので、複数の role を一度に設定することができません。 したがって、複数の role をあるアカウントに付与するためにはツラツラ書く必要があって、少し辛いところがあります。 参考 https://www.terraform.io/docs/providers/google/r/google_project_iam.html#google_project_iam_member-1 # create account resource "google_service_account" "sample_app_user" { account_id = "app-mgr" display_name = "app-mgr" } # add role1 resource "google_
TerraformでModuleを使おう - Qiita
Moduleとは 特定のリソースをModuleにすることで、設定の使い回しや共通化を図る事ができます どんなときに使うか 同一の設定のEC2インスタンスを複数起動する場合、Moduleを使うと簡単です。 workspaceの機能を使わずに、環境ごとにディレクトリを分けている構成をした場合は、Moduleを使用することで複数環境で同一の設定をすることができます。 ここでやること 簡単に試すことを目的にProviderはDockerを指定します。ImageとContainerをModuleにし、異なる環境でImageのタグやコンテナ名、ホストポートへのマッピングを変更する例を上げたいと思います。 実行環境 ツール Tool Version
terraformからroleにpolicyをattachするときの話 - Qiita
概要 terraformにおけるaws_iam_policyとaws_iam_role_policyの違いについて aws_iam_policyで生成したpolicyをattachする(aws_iam_policy_attachment)方が良さそう はじめに 今年の4月ごろにAWSのアカウントを作ってから、LambdaやKMSやEC2に触れてきました。 SAMを用いるとlocalでテストもしやすくて便利なので、使っていたのですが、 deployする先はcloud formationであり、cloud formationでできることはterraformでもできる場合があるという話になり、 terraformから触ってみた時にpolicy周りで混乱した話です。 詳細 policyを定義して、roleにattachするときのことです。 まずは aws_iam_policy_document で
TerraformでIAMポリシーのJSONに変数を埋めたい場合はaws_iam_policy_documentを使う - Qiita
TL;DR TerraformでIAMポリシーのJSONに変数を埋めたい場合はaws_iam_policy_documentを使えばよい サンプルコードはTerraformでKMSキー作った時に、アクセス権限の管理をIAMグループで管理する例 aws_iam_policy_documentのドキュメントはこちら => AWS_IAM_POLICY_DOCUMENT サンプル KMSのキーARNを変数参照で埋め込んだIAMポリシー作って適当なIAMユーザ/グループ/ロールに付与するtfファイルこんなかんじ data "aws_iam_policy_document" "kms_hoge" { statement { sid = "AllowUseOfTheKey" actions = [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms
tfstateを分割管理するためのTips - Qiita
はじめに この記事はterraform Advent Calendar 2019の4日目です。 Terraformのstateを分割すると享受できるメリットがある一方、stateを分割することで発生する課題もあります。そこで、Terraformのstateを分割管理する中で考慮したことをまとめます。 stateを分割する影響 メリット plan/applyが高速化する 各ステートの命名がシンプルになる（thisを使った命名がしやすい） 例えばresource "aws_security_group" "this" {} デメリット 管理するファイルが増える 同じような設定が増える どのような単位でstateを分割するか リソースのライフサイクルごとに分割すると運用が楽です。 例えば、作成後削除することのないネットワークやデータベースと、状況により台数が増減したりリソースを入れ替えるWebサ
terraformはどの単位で分割すべきか - Qiita
terraformでインフラ管理をする際のベストプラクティスとして、実行単位を細かく分けようというのがあるのですが、安全に運用するためにはどのレベルで分割を行うべきかについて考えてみました。 terraformとは AWSやGCPなどのインフラ等をコードで管理するツールです。 なぜ分割して管理する必要があるのか Terraform Best Practices in 2017 に記載がありますが、1つのtfstateファイルで多くのリソースを管理してしまうと、問題があった場合の影響範囲が大きくなってしまいます。 また、変更したい場所以外で何かしらの差分がある場合、その差分の原因を突き止めるまで更新が出来ない等いろいろ不便な状況になります。(本番環境でなんかよくわからないけど差分が出ちゃった場合それを無理やり元に戻すなんてなかなか出来ないですよね。。) だからといって、すごく細かくリソースを
Terraform - リポジトリ構造と活用範囲を考える - Qiita
はじめに Terraform に入門すると、最初に簡単な VPC を作成するまでは早いですが、実運用を見越して terraform.tfstate の管理方法について考えたり、効率的なディレクトリ構成について考えたりすると手が止まってしまいます。 入門時期を終えて、書籍『Pragmatic Terraform on AWS』 を読んで Terraform のお作法について学び直したところなので、これまで得た知見を整理するために記事を書いてみます。 書くこと Terraform の使い所 Terraform で実装したリポジトリの例とサンプルコード（一部） 書かないこと Terraform の使い方・インストール方法 Terraform の運用方法 Terraform でクラウド環境を構築するだけなら直ぐですが、「構築した環境の上で動作するアプリケーションのライフサイクルについて」や、「AW
Terraform職人入門: 日々の運用で学んだ知見を淡々とまとめる - Qiita
はじめに この記事は CrowdWorks Advent Calendar 2017 の8日目の記事です。 Terraform職人の @minamijoyo です。Infrastructure as Codeしてますか？ インフラのコード管理に Terraform を使い始めて2年ちょっと、本番環境で運用していると日々色んな学びがあるので、Terraformやってみた系の入門記事では語られない、現場の運用ノウハウ的なものを共有してみようかと思います。 Terraformを使い始めた or 使っている人が、こんなときどうするの？っていうときに参考になれば幸いです。 書き始めたら超長文になりました。概要は以下のとおりです。 公式ドキュメントを読もう tfファイルを書く技術 インデントを揃える 組み込み関数に親しむ lifecycleブロックを使う リソースの差分を無視する リソース再生成のとき
Terraform0.12 のfor_eachで幸せになれるってよ - Qiita
はじめに Terraform 0.12.6が出ました！ このリリースにより、for_eachの幅が広がりました。 具体的にどういった恩恵が授かれるのかをIAM User&Groupの作成で紹介できればと思います。 環境 以下の環境で実施します。 Cloud: AWS Terraform: 0.12.6 ツラミ Terraform を使ってIAM UserやGroupを管理していてツラミにぶち当たった人は少なからずいると思います。 それは、ユーザを追加や削除する時です。 そして見覚えがあると思います。。以下のエラー User with name X already exists. もうツラミでしかない。。 ここからは、いままでのやり方（僕の）やこれからのやり方について書いていきたいと思います。 いままで まずはこのエラーが発生する場面を体験したいと思います。 Terraformコードの作成
Terraform職人再入門2020 - Qiita
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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
terraform import したものを取り消したい - Qiita
