2026/8/2 栃木ゆる勉強会 https://tochigi-study.connpass.com/event/352995/ オフライン / 20名程度

Claude Codeのセッション内でTerraformを実行したいときがあります。 この際の課題として、Terraformで操作するクラウドプロバイダー(AWS,Google Cloud)やSaaSの認証情報の渡し方があります。 Claude Code経由でAWSを操作する際は工夫が必要で、DevIO上にもいくつかの記事があります。 Claude Codeで1Password管理のAWS認証情報を用いてAWSの操作をする方法 | DevelopersIO Claude Codeでスイッチロールができない場合の対応方法 | DevelopersIO 本記事ではTerraformにフォーカスして、HCP Terraformで楽に認証情報を管理してみます。 AIエージェントへの権限付与の課題とHCP Terraformによる解決 AIエージェントにTerraformで利用する強い権限を与えたく
本ガイドラインは、世の中のシステム開発プロジェクトのために無償で提供致します。 ただし、掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社は一切の責務を負わないものとします。 また、掲載している情報は予告なく変更することがございますので、あらかじめご了承下さい。 はじめに Terraformはインフラを宣言的にコード管理するツールであるが、特に大規模なシステムでは扱うリソース数が増え、必然的にTerraformコードも複雑化する傾向にある。Terraformの可読性が低下すると、作業効率の低下だけではなく影響度が大きいミスを誘発する懸念がある。 また、Terraformは活発に機能開発が継続されており新しい機能/記述方法もリリース毎に追加されている。これは嬉しい反面、新規開発者が悩むポイントも増えたと言える。関連して、チームやプロジェクトごとに設計方針
こんにちは。TIGの伊藤です。 Terraform連載2025の6日目の記事です。 2025年始から、社員の有志でTerraform設計ガイドラインを編集し、先日公開したので公開までの経緯などについて触れていきます。 公開までの経緯Future Enterprise Arch Guidelinesとして、これまでにもWebAPI設計ガイドライン、Slack利用ガイドラインなどを公開してきましたが、これらは社内に知見が溜まってきていることをきっかけに、ガイドラインとして整理して公開しています。 Terraformについても、社内の複数プロジェクトで利用されており、それぞれで工夫したこと、ケアしたポイントなどが知見として出てきていることから、社員がリファレンスとすることも含めて編集、公開することになりました。 チームにおけるガイドラインを設けることの難しさ各プロジェクト、チームでは一定のコーデ
Google CloudがApplication Design Centerという、構成図を書けばTerraformを書いて、デプロイまで行う機能をリリースしました。[1] どうやらGoogle CloudはTerraform職人を失職に追い込みたいようです。 Application Design Centerの概要 アプリケーション デザイン センターは、Google Cloud アプリケーション インフラストラクチャの設計、共有、デプロイに役立ちます。アプリケーション デザイン センターを使用すると、アプリケーション テンプレートを設計し、開発者と共有し、インスタンスをデプロイして、設計を進化させることができます。 つまりApplication Design Centerはインフラ構成図の設計・共有・デプロイを補助するツールで、アプリケーション開発者やプラットフォーム管理者が効率的に管
おそらくTerraformの.tfファイルがイメージしやすいと思いますが、.tfファイルのHCLシンタックス内に別のシンタックス(多くはヒアドキュメントで表現される複数行の文字列)を埋め込むことがあります。 私が真っ先に思い出すのがAWSのPolicyです。 resource "aws_iam_policy" "allow_dynamodb_table_post" { name = "allow_post" policy = <<-EOT { "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "dynamodb:*", "Resource": "${aws_dynamodb_table.post.arn}" } } EOT } 今ではData sourceでaws_iam_policy_document
普段 Terraform のバージョン管理ツールとして tfenv を使っている.機能面で困ることはないけど,tfenv の GitHub リポジトリを確認すると,直近数年は特にアップデートがなく,メンテナンスの観点で少し不安を感じていた💦 github.com 念のため tfenv の代替ツールを探しておこうと思って,tenv を試してみた❗️tenv は tfenv と同じように使えて,OpenTofu や Terragrunt もサポートしているという特徴がある.そして現在も活発に開発がされているようだった.tenv 以外だと tfswitch もあって少し試したけど,個人的には tenv が良さそうだった. github.com セットアップ Homebrew で簡単にセットアップできる👌 $ brew install tenv $ tenv version tenv vers
お疲れさまです。とーちです。 Terraformを使っていて「今のState fileの状態を簡単に確認したいな」と思うことはないでしょうか?私は稀にあります。 今回は、そんな悩みを解決してくれる「terraform-tui」というOSSツールをご紹介したいと思います。 とりあえずまとめ Terraform Stateをグラフィカルに可視化できる リソースの検索や詳細表示が直感的に可能 Plan/Applyもツール上から実行可能 terraform-tuiの主要機能 1. State管理の可視化 Terraform stateツリーの完全な可視化 リソース状態の詳細表示と簡単なナビゲーション ツリー構造での直感的な状態把握 2. 検索・操作機能 stateツリーとリソース定義の検索 リソースの単一/複数選択 リソースの削除機能 3. Plan/Apply機能 terraform-tuiから
きっかけ 最近、自己学習の中でterraformにてAWSリソースを構築しました。 自分でインフラ構成っぽいものは書いてみたが、いいかんじで自動生成してくれるものがないか探してみたらPluralithなるものが存在したので、使用感を確かめてみるために使ってみます。 使ってみた結果、詰まるところもあったので、メモも兼ねて記事に残しておきます。 ソースコード コードは以下のリンク先にあります。 結論 先に結論を書きますと。 α版ということもあり、実運用で使っていくのはちょっと厳しい印象があります。 個人開発あるいは、チーム人数が少なかったり、開発初期等でドキュメントに時間をあまり掛けられないときには使ってみるのはアリかなぁと個人的には思います。 Pluralithのドキュメント通りにやってみましたが、うまくいかなかいことがあったので、導入してもトラブルシューティングに工数取られそうな印象があり
人類は HCL (Hashicorp Configuration Language) で JavaScript を記述するべきなので、次世代のモダン AltJS である「JS.tf」をリリースしました。 例えば次のコードは標準出力に hello world と出力する JS.tf のプログラムです。 data "js_function_call" "hello_world" { caller = "console" function = "log" args = ["hello world"] } data "js_program" "main" { statements = [data.js_function_call.hello_world.statement] } # index.js としてファイル出力 resource "local_file" "main" { filename
ROUTE06 では GitHub の管理に Terraform を導入しました。今回はその導入の背景、実際に導入してどう変わったのか、導入方法について紹介したいと思います。 Terraform とは Terraform は、IaC(Infrastructure as Code)ツールの一種です。 インフラの設定をコードとして管理することで、設定の変更履歴が明確になり、誤った設定によるトラブルを防ぐことができます。 なぜ GitHub を Terraform で管理するのか ROUTE06 では、全社的に GitHub を使用しています。そのため、GitHub の管理は非常に重要です。 Terraform 導入前には、以下のような課題がありました。 手動での設定変更時にミスが発生する 設定変更の履歴が追いにくい 重要な変更(リポジトリの作成や Organization へのユーザー招待など
HCP Terraformのephemeral workspaces(リソース自動削除設定)がProject単位で設定できるようになりました アップデート概要 HCP Terraform/Terraform Enterpriseにはephemeral workspacesという機能があります。 この機能は、特定の日付や一定期間非アクティブなWorkspaceのリソースを自動的に削除する機能です。 例えば、「7日後に削除」と設定すると、7日後にWorkspaceでDestroy用のRunが行われリソースが削除されます。 これまでは、Workspace単位での設定が必要でしたが、今回のアップデートで、Project単位(Workspaceをまとめた単位)の設定が可能になりました。 このアップデートによって、設定漏れのリスクと設定作業の負荷が軽減されました。 例えば以下のように活用することで、組
“Platform Engineering”という私的よく見かけるが意味を調べたことのない用語No.1のトピックについて書かれた本がO'Reillyからearly releaseされているので読んでる。まだ第一部しか公開されてない。 learning.oreilly.com その中に出てくるアプリケーションチームがTerraformコードを管理することで起きがちな問題について共感したので紹介する アプリケーションエンジニアリングチームがIaaSクラウドのあらゆるものを求めるようになったとき、多くの企業は、各チームに独自のクラウドインフラストラクチャを独自の構成でプロビジョニングする権限と責任を与えることが、摩擦の少ない方法だと判断しました。 実際には、これは、構成管理とインフラストラクチャプロビジョニングに精通した、兼業のクラウドエンジニアリングチームになることを意味していました。 繰り返
しばたです。 私は普段Windows環境でTerraformを使っており、Terraformのバージョン管理には自作ツールを使っていました。 つい先日新しいバージョンマネージャーであるtenvというツールがあることを知ったので試してみることにしました。 tfenvのつらみ Terraformのバージョンマネージャーとしてはtfenvが一番メジャーかと思います。 tfenv ただ、このtfenvはシェルスクリプト(Bashスクリプト)の集合体でありWindows環境ではGit Bashでのみ動作する状況でした。 加えて2023年末ごろから開発停止状態になっていいます。 新しいバージョンマネージャー tenv 細かい経緯を正確に把握できていないのですが、今年に入りOpenTofuのコミュニティによりOpenTofu向けのtfenv派生であるtofuenvが生まれ、 tofuutils / to
この記事は毎週必ず記事がでるテックブログ "Loglass Tech Blog Sprint" の 47週目の記事です! 1年間連続達成まで 残り 6 週 となりました! はじめに ログラスのクラウド基盤でエンジニアをやっているゲイン🐰です。 ログラスではAWS上でアプリケーションを動かすためにIaCとしてTerraformを採用しています。 我々のTerraformの構成を紹介するとともに、現状の課題とリファクタリングの事例を共有できれば幸いです。 ログラスのTerraform構成 ざっくりログラスのアプリケーションにまつわるTerraform構成は以下のようになっています。 基本的にはterraform/usecaseディレクトリ配下にmoduleとして定義されています。 中身は比較的にベタでリソースが書かれており、それらをterraform/envディレクトリの各ディレクトリ内で呼
こんにちは。READYFOR 株式会社で SRE として働いている ジェダイ・パンくず🚀 と申します。 突然ですが、皆さんの現場ではインフラのテストの仕組みは導入済みですか?我々はまだ出来ていません(笑)。 READYFOR では IaaS として AWS を、IaC として Terraform を導入しているのですがコードのテスト・コードによってデプロイされた状態のテストを何かしらの仕組みを使って実践したいなぁと考え、今調査している最中です。 今回は Terraform のテストを書くツール Terratest について調べた内容を皆さんに共有したいと思っています。また AWS の状態をテストする仕組みとしてよく知られている Awspec との比較も行っていきたいと思っています。 必要になるモノ 事前に必要になるソフトウェアの一覧です。 Golang (requires version
クラウドインフラのシステム基盤構築にTerraformを採用している組織は多いですね。村上自身は特別な要件がない限り、”どのクラウドを使う場合でも” システム基盤構築にはTerraformを使いたいと考えているインフラエンジニアです。 私は、Terraformを3年間使用する中で、6つの課題に直面してきました。 このブログでは、実際の開発現場でどのような問題が起こったのか、またその問題をどのように回避、あるいは対策すべきだったのかについて、綴ってみました。 【課題1】プロジェクト始動直後にTerraform開発を開始したため、後工程で改修タスクが多発 SI案件では、クライアントが提案する調達要件RFPをもとに、ITベンダーがヒアリングを行いながら要件定義を進めていきます。 要件定義の一例として以下のようなものがあります。 クラウド・ミドルウェアの選定(事前に指定される場合もあるが、基本的に
TL;DR Add a terraform plan -light flag such that only resources modified in code are targeted for planning. This would reduce the scope of the pre-plan refresh down to the set of resources we know changed, which reduces overall plan times without the consistency risk of -refresh=false. For Terraform to know what resources were modified in code, it would store the hash of the serialized sorted attr
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く