この記事は毎週必ず記事がでるテックブログ "Loglass Tech Blog Sprint" の 47週目の記事です！ 1年間連続達成まで 残り 6 週 となりました！ はじめに ログラスのクラウド基盤でエンジニアをやっているゲイン🐰です。 ログラスではAWS上でアプリケーションを動かすためにIaCとしてTerraformを採用しています。 我々のTerraformの構成を紹介するとともに、現状の課題とリファクタリングの事例を共有できれば幸いです。 ログラスのTerraform構成 ざっくりログラスのアプリケーションにまつわるTerraform構成は以下のようになっています。 基本的にはterraform/usecaseディレクトリ配下にmoduleとして定義されています。 中身は比較的にベタでリソースが書かれており、それらをterraform/envディレクトリの各ディレクトリ内で呼
しばたです。 私は普段Windows環境でTerraformを使っており、Terraformのバージョン管理には自作ツールを使っていました。 つい先日新しいバージョンマネージャーであるtenvというツールがあることを知ったので試してみることにしました。 tfenvのつらみ Terraformのバージョンマネージャーとしてはtfenvが一番メジャーかと思います。 tfenv ただ、このtfenvはシェルスクリプト(Bashスクリプト)の集合体でありWindows環境ではGit Bashでのみ動作する状況でした。 加えて2023年末ごろから開発停止状態になっていいます。 新しいバージョンマネージャー tenv 細かい経緯を正確に把握できていないのですが、今年に入りOpenTofuのコミュニティによりOpenTofu向けのtfenv派生であるtofuenvが生まれ、 tofuutils / to
terraform (plan|apply) in GitHub Actions | さくらのナレッジ
はじめに さくらインターネット SRE室の久保です。 今日は「terraform (plan|apply) in GitHub Actions」というタイトルで発表させていただきます。 今日発表する内容は、画像で表すと上図のようになります。誰かがPull Requestを送ると、それをもとにGitHub Actionsを動かし、Terraformのplanやapplyを動かして、自動的にTerraform管理下にあるリソースを更新してくれる、そういう仕組みを作ったという話です。 terraform (plan|apply)を実行する際のポイント Terraformのplanとapplyを実行する際のポイントとして、まず各種秘匿情報、具体的にはAPIキーなどが必要になるので、実行結果をチーム内で共有してレビューするのが結構面倒です。何らかの方法でAPIキーを共有して使うにしても、あるいは各自
Terraformモジュール構成のベストプラクティス - ENECHANGE Developer Blog
VPoTの岩本 (iwamot) です。 この記事では、Terraformモジュール構成のベストプラクティスをご紹介します。Terraformドキュメントに書かれているものですが、従わずに時間を溶かした失敗談をまじえてお伝えすることで、同じ轍を踏む方が減ることを願っています。 取り上げるのは下記のベストプラクティスです。 Module Composition（フラットなモジュールツリー） Dependency Inversion（依存性の逆転） Module Composition（フラットなモジュールツリー） Module Compositionは、モジュールをフラットに並べられるよう構成すべし、という話です。Terraformドキュメントでは下記の例が挙げられています。 module "network" { source = "./modules/aws-network" base_c
Terraformのversion 1.9が2024年の6月26日にGAになりました。1.9の新機能を見ていきましょう。 変数のvalidationで色々参照できるようになった 変数にはvalidationを実装することができます。例えば以下のようなものです。 variable "aws_account_id" { type = string description = "AWS Account ID" validation { condition = can(regex("^[0-9]{12}$", var.aws_account_id)) error_message = "Invalid AWS accountID." } } これはAWSアカウントIDが格納されるのを想定した変数です。AWSアカウントIDは必ず12桁の数字ですので、そうでない場合はエラーにしています。 上記例では c
こんにちは。イオンスマートテクノロジー株式会社（AST）でSREチームの林 aka もりはやです。 Terraformを一定以上扱ってきた方であれば terraform import コマンドを苦労しながら実行した経験があるのではないでしょうか。私自身も5年以上Terraformを扱う中で何度も terraform import を行ってきました。 一般的に terraform import では以下を行います。 実態に合わせてコードを整える 実態を指定するコマンドを組み立てる ステートファイルに取り込む 差分が出たら地道にコードを整えて terraform plan を実行する 4を繰り返して"No changes"となるまでチューニングする これらの作業はTerraform初見では難しく、個人的にTerraform中級者への登竜門として terraform import が試金石のひと
巷の Terraform Module に違和感を感じたので納得できるものを作ってみた【AWS VPC編】
今日は最近 Terraform Module に感じていた使いにくさの理由と、その克服方法について AWS VPC を構築しながら整理していきます。 世間で使われる Terraform Module に対する違和感 早速ですが、巷で使われている Terraform Module に対して感じた違和感を挙げていこうと思います。 具体例があるとよりわかりやすいかと思いますので、 terraform-aws-modules/vpc/aws を例に取りながら見ていこうと思います。
「Terraformテスト入門」というタイトルでDevelopersIO 2024 Odysseyに登壇しました #cm_odyssey #devio2024 | DevelopersIO
DevelopersIO 2024 Odyssey Day9(7/24)にて、「Terraformテスト入門」というタイトルでお話ししました。 登壇資料 おわりに Terraformのテストについてお話しました。テスト手法もツールも色々あります。 今回の発表で、ざっくりイメージつけてもらえたら幸いです。 今回紹介したほとんどのツールや機能は無料で使えます。 興味を持った方は、実際に機能やツールを触ってみてください。 今回参考にさせていただいた、以下の資料もぜひチェックしてみてください。 書籍: 詳解Terraform(9章) HashiCorp Blog: Testing HashiCorp Terraform 以上、AWS事業本部の佐藤(@chari7311)でした。
Google Workspace でも Microsoft Entra ID の PIM で Just-in-Time Access (Terraform 設定つき) #ベッテク月間 - LayerX エンジニアブログ
すべての経済活動を、デジタル化するために、すべての業務活動を、デジタル化したいコーポレートエンジニアリング室の @yuya-takeyama です。 週末は Festival Fruezinho という音楽フェスに参加し、アルゼンチンの音響派フォークシンガー・Juana Molina を観てきました。デジタルなサウンドを活用しつつも、ライブ感のあるバンドサウンドで、非常にスリリングなライブでした！ 今回の話はアナログ寄りのデジタルな気がします。 Microsoft Entra ID の PIM とは PIM (Privileged Identity Management) については、少し前に Fintech 事業部の piroshi さんが書いてくれた記事があるので、概要はそちらをご覧ください。 最小権限の原則に一歩近づく - Entra ID の "Just-in-time appli
A Hybrid Intelligence that helps you create production-ready infrastructure, using knowledge contributed by you and other DevOps experts all over the world. A Hive Mind for DevOps and cloud-native infrastructure design.
はじめに 現場でterraformソースコードのGitlab → GitHub移行にあたって、Github Actionsワークフローを組む機会がありました。 そこで、運用しやすそうなCIを組めたので、共有させていただきます。 前提/方針 GoogleCloud（以下GCP）インフラをterraform管理している。 環境はstg・prodの2つで、別々のGCPプロジェクトに構築されている。 プルリク作成時・更新時にterraform planを実行したい。 plan結果はtfcmtというツールを利用し、プルリク上に自動でコメントしてもらう。 各環境用で別々のGithub Secretsを登録している。 また、ディレクトリ構成は以下のような感じ。 src/commonはstg・prodの共通リソースです。 src/ ├ common/ │ ├ moduleA/ │ ├ moduleB/
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ログラスのTerraform構成とリファクタリングツールの紹介
新しいTerraformのバージョンマネージャー tenv を試してみた | DevelopersIO
Terraform 1.9 の新機能紹介 | DevelopersIO
terraform importで数年やってきたがImport blockの良さに気づきました
Stakpak - Design Studio for Terraform with a Copilot.
Github Actionsで複数環境のterraform planを自動化する