はじめに こんにちは、クロスイノベーション本部エンジニアリングテクノロジーセンターの徳山です。 この記事は、2025年5月20日に公開されたばかりの Terraform MCP Server をGitHub Copilot in VS Code ( 以降、Copilotと記載 ) で使用してみた体験談です。Terraform MCP Server の導入前のコード生成状況から導入内容、導入後のコード生成結果までを紹介します。 Terraform MCP Server は、 LLM (大規模言語モデル) の AIエージェントへ Terraform のプロバイダーとモジュールの検出やプロバイダーのリソース詳細情報取得などの機能を提供するMCPサーバです。 Terraform MCP Server の導入前の Copilot は、Terraform の AzureRM には存在しない架空のプロパ

概要 Terraformを使い始めて一年ほど経ったので、設計や運用上のノウハウを公開していこうと思います。 基本的にAWSを使うことが多いので、AWS寄りの話になります。 設計編 利用可能なプロバイダを調べる TerraformはAWSやGCPといったクラウドサービスをコード化できることで有名ですが、オフィシャルだけでも様々なプロバイダに対応しています。 私はAWSのほか、GitHubやDatadogをコード化して運用してます。 ネットワーク設計 サービスを構築する上で本番環境のほかに開発やステージング環境を作りますが、環境の分け方は大きく分けて次のいずれかになることが多いと思います。 1つのVPCに全ての環境を入れる 環境ごとにVPCを分ける 環境ごとにAWSアカウントを分ける 2のパターンで設計する場合、Terraformで構成を組む際はVPCをdevelopment、staging、

背景 terraformのremote stateをs3に保存する場合、terraform apply（もしくはplan）の競合を防止するため以下のようにDynamoDBも併せて設定するかと思います。 terraform { backend "s3" { bucket = "tfstate-backend" key = "tfstate" region = "ap-south-1" dynamodb_table = "terraform-lock" encrypt = true } ... } 何故AWSでは（厳密にはremote stateをs3に設定した場合では）DynamoDBを設定しないと競合を防止できないのか気になって調べたのでその内容を以下にまとめます。 2024年11月12日追記 2024/08/20 Amazon S3 が条件付き書き込みのサポートを開始しました。 これに伴

こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 今月でカミナシに入社してちょうど 1 年が経ちました。前職では 6 年間 SRE チームにいたのでプロダクト開発はブランクがありましたが、さまざまな挑戦をさせてもらっていたらあっという間に 1 年が経っていました。 カミナシのエンジニアリング組織もこの 1 年で急拡大しており、入社当初から比べると正社員のエンジニアも倍以上に増えました。 GitHub の権限管理、どうしていますか？ ところで、みなさんが所属されている組織ではどのように GitHub の権限管理を行なっていますか？ カミナシではつい先日まで、ほとんどのエンジニアが Organization の Owner 権限を持っていました。理由は、メンターになったエンジニアがニューカマーのユーザーを招待していたからです。 しかし、統制が取れていないことでいく

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 面接時に役に立つ、Terraformにおける実践的な基礎知識やベストプラクティスを学べる問題集を作ってみました。 面接形式なので、サンプルコードの記述が少なく、わかりにくい部分もあるかと思いますが、Terraformの基本的な概念の整理にお役立ていただけます。ぜひ面接の準備や知識の確認にご活用ください。 注意事項 本問題集はTerraformのv1.5.xを基準に作成されています。 本問題集は、Terraformにおける実践的な基礎知識やベストプラクティスなどを学ぶための問題集であり、全ての問題が実際の企業採用面接時に出題され

こんにちは、プラットフォーム開発グループ SREチームの西川 (@taxin_tt) です。 皆さんTerraform使ってますか? 弊社では既存サービスのマイクロサービス化を進めており、GCPベースのインフラはTerraformを利用して整備するようにしています。 一方で、サービス数の増加などに比例してtfファイルのコード量も増えていき、ディレクトリ構成や個別のリソースの定義などマイクロサービスのインフラ整備において負担になる部分があり、昨年末からSREチーム主導でリファクタリングを行っています。 今回は、そのリファクタリングの背景や進め方についてお話しできればと思います。 (本記事は、Terraform v1.3系を前提にしています。) リファクタリング後のTerraformのディレクトリ構成は下記をベースにしているので、下記の記事も合わせてどうぞ。 tech.visasq.com リ

これは「「はじめに」の Advent Calendar 2021」17日目の記事です。 ECSのタスクは環境変数をパラメータストアやシークレットマネージャーの値を起動時に設定出来る機能があります。 具体的な手順は、いつものクラメソさんの記事を参考にしてください。 運用時の問題 シークレット系の情報の管理とアプリケーションで必要な環境変数をあわせる時に、いくつか問題が発生します。 次のようなECSサービスがあったとします。 (※色々省略しているのでこのまま動きません) resource "aws_ecs_cluster" "example" { name = example-api } resource "aws_ecs_task_definition" "example" { family = "example" execution_role_arn = aws_iam_role.exam

resource "aws_ecs_cluster" "foo" { name = "foo" } resource "aws_ecs_task_definition" "web" { family = "web" container_definitions = jsonencode([ { name = "web" image = "example/web:1.2.3" cpu = 128 memory = 512 essential = true portMappings = [ { containerPort = 80 hostPort = 80 } ] } ]) } resource "aws_ecs_service" "foo" { name = "web" cluster = aws_ecs_cluster.foo.id task_definition = aws_ecs_ta

こんにちは。クラメソのスジェです。 ほとんどのサービスにはベストプラクティス（=best practices）というのがあります。 そのサービスを利用する際、このベストプラクティスを守るとより効率的に性能を100%活用することができます。 もちろんterraformにもこのようなベストプラクティスがあります。 今回はこのベストプラクティスについて整理してみました。 参考資料 本記事は下記の資料を参考にして作成しました。 本記事ではほとんどのプロジェクトに活用できる程度の項目を紹介しています。つまり、ベストプラクティスについて軽く説明している感じなので、詳細な内容までは上記の資料をご参照ください。 また、紹介した資料以外にもベストプラクティスを調べてみたら、たくさんの資料がありますので、そちらもあわせて確認することをお勧めします。 読む前に 実際にベストプラクティスをプロジェクトに適用しよう

以前「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

2022/04/21_HashiCorp Virtual Strategy Day Japan Vol.2での、須藤の講演資料になります

タイトルままですが、私の環境（以下に記載）でTerraformの plan apply destroy を行うと以下のようなエラーが起こることが頻発していました。 環境 PC M1 Mac OS: Big Sur Terraform tfenv terraform: v1.1.7 エラー内容 Error: Failed to load plugin schemas │ │ Error while loading schemas for plugin components: Failed to obtain provider schema: Could not load the schema for provider │ registry.terraform.io/hashicorp/aws: failed to instantiate provider "registry.terrafor

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 以

こんにちは。TIGの伊藤です。この記事は秋のブログ週間2021の3日目です。 はじめに私は普段会社でクラウドをまたいでTerraformを日々書いたり、メンバーに教えたりしています。もはや俗に言うプログラミング言語を書かずにここまで全振りしてきたくらいなので、比較的自信を持ってコードを書いて仕事をしています。 特にここ最近はほぼ1からコード設計をして運用まで持っていくこともあり、「より腐りにくい、より息の長いコード」というものを考えるようになりました。Terraformだからこその「定期メンテを簡易にするためには」「より簡単に変更するためには」をひたすら突き詰めていった結果、アツい気持ちが生まれ、今回は筆を取っています。 そんな私のアツい気持ちをしたためた今回の記事ですが、可能な限り例も添えつつ、いくつか解説できればと思います。公式にも実は載っているような内容もあったりしますが、日本語の記

2021年9月30日AWS Dev Day Online Japanの登壇資料 動画はこちら: https://www.youtube.com/watch?v=0IQ4IScqQws

terraformで Cloudfront に WAF2 を使って特定のパスやAPIにIP制限をする terraformでWAF２を使ってやるやり方が割と最近対応したので備忘録的なあれ /admin/* と /api/admin/* にIP制限をするサンプル IP sets と Regex pattern setsを作成 resource "aws_wafv2_regex_pattern_set" "admin-path" { name = "admin-path-set" scope = "CLOUDFRONT" provider = aws.east regular_expression { regex_string = "^\\/?admin.*$" } } resource "aws_wafv2_regex_pattern_set" "admin-api-path" { name

バランサーとEC2 デプロイフロー Terraformで実装 前提 ディレクトリ構成 CodeDeploy 必要なリソースのインポート ①インポートしたリソースの定義 ②デプロイアプリケーションとデプロイグループの作成 CodePipeline ①IAMロール作成とポリシーアタッチ ②S3バケット作成 ③パイプライン作成 aws_codestarconnections_connectionリソースについて 入出力アーティファクトについて まとめ 最後に こんにちは。バックエンドエンジニアの高橋です。 あるプロジェクトで実装したCodeDeployとCodePipelineを使ったデプロイをTerraform化したので、その実装例を紹介したいと思います。 バランサーとEC2 今回はバランサーに複数のウェブサーバがぶら下がっていてそこにインプレースデプロイする構成とします。 デプロイフロー C

ECSを触っていて今まで難しいと思ったことを雑にまとめておく。 ECSを仕事で運用するときに必要な知識が多すぎる。こんなの社内に1人AWSマスターいないと無理だ...— 神速 (@sinsoku_listy) 2021年8月10日 タスクロールとタスク実行ロールの違い ECSを長く触っているのに、いつも混乱する。 タスクロール コンテナ内の権限 S3やSESなどの権限をつける タスク実行ロール コンテナ外の権限 ECRやParameter Storeの権限をつける ECSのデプロイ時に静的ファイルが404になる ECSを触った初期に遭遇した。 詳細は以下のQiitaの記事が分かりやすい。 参照: ECSのデプロイ時に一定確率で静的ファイルが404になる問題を回避する 回避する方法はいくつかある。 静的ファイルをS3に置く CodeDeployの OneAtATime を使う CodeDep

概要 自分の所属企業であるAqua SecurityがTFsecというOSSを買収しました。 blog.aquasec.com TFsecはどういうツールかというとTerraformの静的解析スキャナーです。Terraformの設定ファイルを渡すことでセキュリティに関する設定ミスを主に検知してくれます。 github.com そのアナウンスに伴い、TFsecは自分が開発している脆弱性スキャナーであるTrivyに統合されました。TrivyではTerraformに加えDockerfileやKubernetesなど、いわゆるInfrastructure as Code（IaC）の設定ミスを検知するマネージドポリシーも提供しています。他にもJSONやYAMLなど一般的なファイルフォーマットに対応しているため自分でポリシーを書くことでそれらの検知にも使えます。CloudFormationやAnsib

技術 1 課の水本です。 最近 Terraform のリファクタリングを行っているのですが、ベストプラクティス迷子になっています。 HashiCorp でも明確な方針は打ち出していない為、Terraform を利用する各プロジェクトで方針を決めているのが現実のようです。 今回は私が出会ってきた問題と、それについての対応、見解を書き連ねていきます。 あくまでも私が思ったことですので、「こうしたほうがいいよ！」というネタも募集しています。 workspace 使うのか使わないのか問題 結論として、私自身は workspace という機能を知ったものの、使うことは考えませんでした。 Terraform では workspace という個別のエリアを設けることが可能で、これを prod や staging と命名し作成しておくと、完全に環境を分離できるというメリットがあります。 ただしデメリットと