tfaction - GitHub Actions で良い感じの Terraform Workflow を構築
tfaction という、 GitHub Actions で良い感じの Terraform Workflow を構築するための Action を開発しているので紹介します。 まだ開発中という感じで未成熟(個人の AWS, GCP アカウントを使って検証しているくらい)ですが、既にそれなりに動くはずです。 tfaction とは GitHub Actions で良い感じの Terraform Workflow を構築するための Action です。 単一の Action ではなく、複数の Action で構成されています。 ここで言う Terraform Workflow とは、 terraform plan や apply を実行する一連の流れのことを指しています。 この Workflow に求める要件は組織・チームによっても異なるでしょう。 そもそも apply の自動実行は危険だから手
Patterns In Infrastructure as Code
Infra Study Meetup#1 https://forkwell.connpass.com/event/171560/
TerraformでIAM Policyを書く方法5つ | DevelopersIO
タイトル修正しました。最初「TerraformでIAM Policyを書く方法4つと失敗する方法ひとつ」というものでしたが、失敗する方法は単に私の書き方が間違ってただけでした TerraformでIAM Policyを書く方法は色々とあるので、紹介していきます。 今回は例として、こちらの公式ドキュメントに出てくる以下ポリシーを使いたいと思います。 { "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "dynamodb:*", "Resource": "arn:aws:dynamodb:us-east-2:123456789012:table/Books" } } ファイル外だし policyの中身はtfファイルに書かず、JSONファイルとして外だしします。それをfile関数を使って参照します。 fil
[レポート]Announcing Terraform 0.14 | DevelopersIO
Terraform 0.14に関してのWebinarを聴講したのでレポートします。(一ヶ月以上前のwebinarですが…) Webinar 概要 Terraform 0.14 is all about perfecting workflow. Our latest version enables practitioners to leverage more predictability and reliability in infrastructure automation. In meeting this goal, we’ve also added some key features to help organizations heavily invested in Terraform, continue to mature. Additionally, updates include
増え続けるXaaSのユーザ管理をソフトウェア化していくお話 - Timee Product Team Blog
コーポレートエンジニア（兼いろいろ）をやっている @sion_cojp です。 本当はやり遂げた状態を発表したかったのですが、道のりも長かったため、今やっていこうとしてる内容を記事にしてみました。 この記事を見てタイミーのコーポレートエンジニアに興味を持っていただけたら幸いです。 TL;DR 増え続けるXaaS、ユーザ管理、複雑化 残されない手順書 我々がやりたいこと なぜterraform？ terraformで管理していくための課題 課題を解決してみる さらにソフトウェア化できそうなところ APIがないXaaS 最後に TL;DR XaaSユーザ管理を全てterraformにしていく 名前とroleさえ設定してapplyすれば権限付与できる形式にしたい 増え続けるXaaS、ユーザ管理、複雑化 GSuite（SaaS）/ AWSやGCP（IaaS） / CircleCI（PaaS）など便
GitHub Actionsで実現する、APIキー不要でGitOps-likeなインフラCI/CD - JX通信社エンジニアブログ
※ 今はGitHub ActionsでOIDCが使えるので、本記事の内容は少し古いです。*1 現場のルール等で「インフラを触るワークロードはオンプレでしか動かしてはならない」みたいなルールがある場合には多少参考になるかと思います。 SREのたっち(@TatchNicolas)です。 JX通信社では「インフラチーム」のようなものは存在せず、開発したチームが運用までやるFull-cycleなスタイルを取っています。AWS・GCPリソースの管理も特定のメンバーが担当するのではなく、必要とする人が必要な時に作成・修正等を行います。すると、terraformなどIaCのツールを利用する場合に「今リポジトリにあるコードは実態を正しく反映しているのか」「誰かが矛盾する変更を加えていないか」という問題が発生します。 CIツール上でterraformを実行することで、問題の一部は回避できるかもしれませんが、
terraformとクラウドの状態の差分を定期的に監視する仕組みを作った話 - ITANDI Engineer Blog
はじめに イタンジSREチームの田渕です！ イタンジではクラウド管理のIaCツールとしてterraformを使っています。 terraformとクラウドの状態の差分を定期的に監視する仕組みを作ったところ、うまくワークし、かなり運用負荷が下がったため、皆様にも紹介します！ 導入の背景 terraformを理想的に運用できていれば、常にtfstateの状態とクラウドの状態が一致しているはずですが、現実はいくつかの理由で差分ができてしまうことがあります。 代表的なものは以下の3つでしょうか。 applyする際に不適切な書き方をした場合に、applyは想定通りに成功するがplanをした際に差分が出てしまう。 awsやterraform provider等の仕様変更により、今までは差分がなかった部分で差分が出てしまう。 稀に何らかの事情で手作業を行ってしまい、terraformへの反映も漏れてしまい
Mercari Microservices Platform における Terraform 0.12 対応 | メルカリエンジニアリング
Platform Group, Platform Infra Team の @dtan4 です。 現在メルカリ/メルペイのマイクロサービス基盤 (Microservices Platform) では、様々なクラウドリソース・SaaS を開発者に提供しています。これらのリソースを宣言的に管理するための手段として HashiCorp Terraform を利用しており、数百のマイクロサービスのインフラが Terraform によって管理されています。 1年以上前の話ですが、Terraform 0.12 がリリースされました。昨年後半に、我々が管理している Terraform リポジトリにおいて Terraform 0.12 対応作業を行いました。本記事では、我々の環境においてどのように Terraform 0.12 対応作業を行ったかについて説明します。 Terraform 0.12 対応の動
Amazon AthenaのPartition Projectionを使ったALBのアクセスログ解析環境をTerraformで構築する | Recruit Tech Blog
こんにちは。スタディサプリ ENGLISH SREグループの木村です。 はじめに 障害調査などでALBのアクセスログを解析したいというときが皆あると思います。 私はあります。 今回はAthenaを使ってALBのログを解析する方法と新機能で発表されたPartition Projectionを利用するとどのようなメリットがあるのか説明したいと思います。 ALBのアクセスログ ALBには標準でアクセスログを出力する機能があり、有効化することで自動でS3にアクセスログを保存することができます。 しかし、標準でアクセスログはgz形式で出力されており、通常解析するにはS3からダウンロードをしてきて、その後にgzを解凍してから、別途ツールを使って分析するなどの面倒な作業が発生してしまいます。 また、アクセスログはデータが大量になることも多く、DLして利用する場合でも一度に多くの範囲を分析するのは困難です
GitHub organizationsのメンバー管理をするTerraformを整備して、そのCIをGitHub Actionsで実現した話 - 実はhokkai7go
はじめに GitHub Enterprise(以下GHE)から github.com へと移行するのが社内のトレンドになりつつあります。renovateの利用も活発です。自分は組織横断的なSREチームにいますが、インフラだけでなくGHEや github.com のorganizationsの管理もやっています。 なぜGitHub organizationsの管理をTerraformでやろうとしたのか 本質的な作業ではないと思うものの、入退社のたびに操作を行う人が発生します。属人化したいものではないのと、他チームメンバーでも操作しやすくするためにコード管理したいとおもいました。自分の所属している組織横断的なSREチームでは、ほかチームのメンバーの増減について詳しく知らないので、各チームからチームメンバーの追加/削除のPRがほしいと考えました。つまりセルフサービス化したいと思ったということです
Atlantisを用いてPRを介したTerraformオペレーションの自動化 - Carpe Diem
背景 TerraformはInfrastructure as Codeを実現してくれるとても素晴らしいツールである一方、運用時に以下のような問題が発生します。 個々人がローカルで実行する場合のオペミス パブリッククラウドリソースを扱うクレデンシャルの管理 そのため実行環境を統一(CIと連携など)したり、GitHubでplan結果を貼ってレビュー→問題なければマージ→(自動)applyといった運用をしているチームも多いことでしょう。 しかしTerraformはplanで成功してもapplyでコケることはちょくちょくあるため、そのPRが正しい状態かどうかは実行するまで分かりません。 またCIと連携することで神権限を持ったクレデンシャルを外部サービスに預けることとなり、漏洩リスクが増大しサービスに致命的な被害をもたらす可能性もあります。 このような諸々の課題を解決していい感じに自動化してくれるの
リモートのtfstateを書き換えずに安全にterraform state mv後のplan差分を確認する手順 - Qiita
はじめに Terraformを長く運用しているとリソース名をリネームしたいというようなリファクタリングが稀によくあります。 これは terraform state mv コマンドを使うとできるのですが、このコマンドはtfstate(Terraformの状態管理ファイル)をデフォルトではその場で書き換えてしまいます。 https://www.terraform.io/docs/commands/state/mv.html しかしながらチーム開発をしている場合、 *.tf はgitでバージョン管理し、 tfstateはリモートのbackend(AWS S3とか)に保存するという管理方法が一般的です。つまり、リモートのtfstateをその場で書き換えてしまうと、masterブランチの状態と差分が出てしまいます。 tfファイル変更のレビュー前に、リモートのtfstateを書き換えずに、terraf
Terraform運用事例書きました - pixiv inside
こんにちは、インフラ部の id:sue445 です。 Terraformなにもわからないけどディレクトリ構成の実例を晒して人類に貢献したい - エムスリーテックブログ や Terraformのディレクトリ構成の模索 - Adwaysエンジニアブログ を読んで影響されたのでピクシブのTerraform運用事例を紹介しようと思います。 Terraformの採用理由 GitLabでのリポジトリ構成 Terraformのファイル構成 moduleがうまく使えたと思っている事例 GitLab CIでTerraformをいい感じにCIする テンプレートの使い方 ピクシブで実際に使っているテンプレートファイル このテンプレートでできること masterブランチ以外 masterブランチ このテンプレートファイルのポイント 最後に Terraformの採用理由 Terraformと同じようなプロビジョニン
GCP連載#6 Terraform Validatorを使って、GCPのセキュリティポリシーの自動チェックを行う | フューチャー技術ブログ
GCP連載#6 Terraform Validatorを使って、GCPのセキュリティポリシーの自動チェックを行う GCP連載の6回目です。今回はTerraform Validatorを使って、組織のセキュリティポリシーの自動チェックを継続的に行う方法を紹介します。併せて、ポリシーをコードとして管理する方法も紹介します。Policy as code です。もちろんセキュリティポリシーのみだけではなく、命名規則やリージョン制限なども扱えます。 Infrastructure as code 理想と現実Infrastructure as code (以下 IaC)、ここ最近大分一般的になってきました。弊社でも大半のプロジェクトは導入しています。3年前とかに導入するために一苦労していた時代が懐かしい.. IaCが当たり前になった今、インフラの構成管理はもう問題ないかというとそうではありません。特にプ
たぶん仕事の役に立たないTerraform v0.12の鑑賞ポイント - Qiita
ってなってて、これはもう完全に草w とか言ってたのが2018年の10月のことで、懐かしいです。 で、結局最終的なv0.11とv0.12のgitの差分がどうなったのか気になるじゃないですか。 というわけで計測してみると、これぐらいです。 [terraform@master|✔]$ git diff --shortstat v0.11.14...v0.12.0 5255 files changed, 606655 insertions(+), 1336138 deletions(-) warning: inexact rename detection was skipped due to too many files. warning: you may want to set your diff.renameLimit variable to at least 1922 and retry t
Terraform 0.12 Deep Dive: HCL Enhancements for Infrastructure as Code, Remote Plan & Apply
Sign up for freeGet started in minutes with our cloud products TerraformInfrastructure as code provisioning
Terraform Best Practices in 2017 - Qiita
2019/12/23 更新 本記事はベストプラクティスかもしれないけど複雑だったので、2020年度版（0.12対応版)として Terraform 0.12 のコードを黒魔術にしないために心がけたこと ~ 自分への戒めを込めて ~ を書きました。こちらも参照ください。 以下のブログをベースにver0.10の新機能のworkspaceや、backend、remote stateを活用してベストプラクティスを考えた。 細かい話は以下のブログを参照いただき、ver0.10に対応した内容だけ記載します。 Terraformにおけるディレクトリ構造のベストプラクティス ｜ Developers.IO サンプルコード サンプルコードを置きましたので、イメージが付かない場合は以下を見てみて下さい。 （適当に作ったので間違えてたらプルリクください） https://github.com/shogomuran
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
terraformで2つのListを特定のキーで結合したMapを作る
トップ | MEDLEY Developer Portal
GitHub - syohex/emacs-terraform-mode: Major mode of Terraform configuration file
