背景 権限を付与する 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_
こんにちは。BASE BANK 株式会社 Dev Division にて、 Software Developer をしている東口(@hgsgtk)です。 TL;DR AWS のマネージド脅威検出サービスである Amazon GuardDuty を有効化する場合、全リージョンに対して設定することが推奨される Amazon GuardDuty を全リージョンで有効化し、検出した内容を Slack に通知するまでの構成を説明・それを実現する具体的な Terraform コードを解説する 記事公開時点で terraform-provider-aws が AWS Chatbot に対応していないため、一部 Console 画面で作成する 当記事のサンプルコードはこちらにて公開している Amazon GuardDuty / AWS Chatbotとは Amazon GuardDuty(略:GuardD
サーバーレスでピタゴラスイッチ。どうも、かわしんです。イベントをサーバレスで繋げてピタゴラスイッチを作るのって案外楽しいもんですね、GUI コンソールで作ってる限りは。 さて、今回は AWS Batch のジョブ実行が失敗した時に Slack に通知する機能を作りたかったのですが、断片的な記事しか見当たらなかったのでこの記事でまとめようと思います。また、今回はインフラ構築ツールとして Terraform を使います。 多分、断片的な記事を普通に繋げてると動かないハマりポイントがあるので、後学の為に注意喚起するという目的もあります。 全体のアーキテクチャ 全体の流れはこんな感じでイベントを繋げていきたいと思います。 Batch -> CloudWatch -> SNS -> Lambda -> Slack AWS Batch ではジョブの状態が変わるたびにイベントが発生します。 CloudW
Moduleとは 特定のリソースをModuleにすることで、設定の使い回しや共通化を図る事ができます どんなときに使うか 同一の設定のEC2インスタンスを複数起動する場合、Moduleを使うと簡単です。 workspaceの機能を使わずに、環境ごとにディレクトリを分けている構成をした場合は、Moduleを使用することで複数環境で同一の設定をすることができます。 ここでやること 簡単に試すことを目的にProviderはDockerを指定します。ImageとContainerをModuleにし、異なる環境でImageのタグやコンテナ名、ホストポートへのマッピングを変更する例を上げたいと思います。 実行環境 ツール Tool Version
全て書くと以下のようになります。 output "instance_ip_addr" { value = aws_instance.server.private_ip description = "The private IP address of the main server instance." sensitive = true depends_on = [ # Security group rule must be created before this IP address could # actually be used, otherwise the services will be unreachable. aws_security_group_rule.local_access, ] } 補足ですが、valueはlist形式でもOKです。 他のModuleの値を参照する O
概要 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 で
HashiCorp Advent Calendar 2015の4日目の担当がいらっしゃらないようでしたので、最近試したことでも書いておこうかと思います。検証が不十分な部分があるかと重いますがご容赦下さい(現在12/4 23:25です) 前日はk1LoW - QiitaさんのTerraformで簡単なところからいろいろ試してみた報告(tfファイル付き) - Qiitaという記事でした。Terraformの知見が増えてきて嬉しいですね。 さて、この記事ではタイトル通りTerraformを使ってIAMロールをEC2の付与することをご紹介します。 IAMロールとは EC2インスタンスからawsのAPIを叩こうと思った時に気になるのが、credentialの扱いかと思います。AWSにはIAMロールという機能があり、その機能をEC2インスタンスに付与することでcredentialファイルを自分で用意し
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
Hands-on: Try the Import Terraform Configuration tutorial. Terraform can import existing infrastructure resources. This functionality lets you bring existing resources under Terraform management. Note: Terraform v1.5.0 and later supports import blocks. Unlike the terraform import command, you can use import blocks to import more than one resource at a time, and you can review imports as part of yo
インフラエンジニアの寺岡です。 前回Terraformに既存リソースをインポートする方法として 以下の記事でterraform importコマンドをご紹介しました。 Terraformで既存のインフラリソースをインポートする方法 この記事のまとめにも記載していますが importコマンドで書き換えてくれるのはtfstateのみであり tfファイルはtfstateとの差分を見ながら自力で書いていく必要があります。 数が多ければ途方もない時間がかかりそうです、これは困った。 そんな皆さんに朗報です。 terraformerというツールがOSSとして公開されています。 https://github.com/GoogleCloudPlatform/terraformer CLI tool to generate terraform files from existing infrastructu
本日は、Terraformを使っていて、tfstateと実際のリソースに差分が生じてしまった際の修正方法を紹介します。 稼働中で作り直しができないリソースなので、tfstateに手動で変更した状態を取り込むことにしました。 起きたことと、解決までの流れは以下のようになります。 terraform plan を実行すると予期せぬ差分(.tf に記述していない)が発生Manegement Consoleと .tf ファイルを比較し、terraformで管理するリソースに手動で変更が加わっていることを特定Management Console側のリソースを、 terraform import で tfstate に反映させるtfstateに合わせて、.tfファイルの記述を修正terraform plan を実行し、Management Console と差分がなくなったことを確認tfstateとは
はじめに この記事はterraform Advent Calendar 2019の4日目です。 Terraformのstateを分割すると享受できるメリットがある一方、stateを分割することで発生する課題もあります。そこで、Terraformのstateを分割管理する中で考慮したことをまとめます。 stateを分割する影響 メリット plan/applyが高速化する 各ステートの命名がシンプルになる(thisを使った命名がしやすい) 例えばresource "aws_security_group" "this" {} デメリット 管理するファイルが増える 同じような設定が増える どのような単位でstateを分割するか リソースのライフサイクルごとに分割すると運用が楽です。 例えば、作成後削除することのないネットワークやデータベースと、状況により台数が増減したりリソースを入れ替えるWebサ
terraformでインフラ管理をする際のベストプラクティスとして、実行単位を細かく分けようというのがあるのですが、安全に運用するためにはどのレベルで分割を行うべきかについて考えてみました。 terraformとは AWSやGCPなどのインフラ等をコードで管理するツールです。 なぜ分割して管理する必要があるのか Terraform Best Practices in 2017 に記載がありますが、1つのtfstateファイルで多くのリソースを管理してしまうと、問題があった場合の影響範囲が大きくなってしまいます。 また、変更したい場所以外で何かしらの差分がある場合、その差分の原因を突き止めるまで更新が出来ない等いろいろ不便な状況になります。(本番環境でなんかよくわからないけど差分が出ちゃった場合それを無理やり元に戻すなんてなかなか出来ないですよね。。) だからといって、すごく細かくリソースを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く