本文の内容は、2023年3月21にNIGEL DOUGLAS が投稿したブログ（https://sysdig.com/blog/terraform-security-best-practices）を元に日本語に翻訳・再構成した内容となっております。 コードとしてのインフラストラクチャ ー(IaC) を使用する場合、Terraform はデファクトのツールです。 リソース プロバイダーに関係なく、組織はそれらすべてを同時に操作できます。 コンフィギュレーションエラーがインフラストラクチャー全体に影響を与える可能性があるため、疑いの余地のない側面の 1 つは Terraform のセキュリティです。 この記事では、Terraformを使用するメリットを説明し、いくつかのセキュリティベストプラクティスを参照しながら、Terraformを安全な方法で使用するためのガイダンスを提供したいと思います。
Retty インフラチームの幸田です。 6月に実施したマイクロサービス強化月間で公開した記事では、マイクロサービス環境を Terraform を利用して刷新した話を書きました。 engineer.retty.me この記事では前回と重複する箇所もありますが、Terraform の CI/CD にフォーカスした内容を書こうと思います。 CI を整備するにあたって意識したこと 「誰でも」かつ「安全に」利用できるように CI 上ですべての作業を完結させる Pull Request によるレビュー環境の整備 バージョンアップ作業の完全自動化 Terraform のディレクトリ構成について リポジトリの運用フロー Terraform によるリソースの追加、変更、削除 tfmigrate によるステートファイルの操作 CI で実行される job について Pull Request をオープンした時 P
この記事では、terraform-provider-mackerel で既存環境をはじめてimportするときに気になりそうな、ささやかなTipsをまとめます。 importについては、Terraformに慣れない人でもぱっと試せるように簡単な手順も記載します。 terraform-provider-mackerel とは？ Terraform Registry に Mackerel 用の Terraform Provider を公開されています。 これを利用するとMackerelのWebコンソールの設定をIaC化することができます。 mackerel.io 実際の Terraform Registry はこちらです。 既存環境をIaCに移行するにはimportを使う おそらく、既存の設定を持っている人がほとんどだと思うので、ここでは既存環境をIaCに移行することを想定したTipsを書いて
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 以
スタディスト開発ブログ Advent Calendar 2021の13日目の記事です。 こんにちは、SRE Unit の wind-up-bird です。以前、 Serverless Framework を移行しているお話を書きましたが、今回は移行シリーズ第2弾ということで、 Terraform Cloud を Terraform on GitHub Actions に移行したお話をお届けしたいと思います。 # 移行前の運用スタディストではこれまで Terraform Cloud の Team & Governance プランを契約していました。移行前の Terraform による開発の流れは、以下のとおりです。 Terraform Cloud 上で Workspace を作成し、Version control workflow を利用する。Workspace には環境変数として、 AWS
背景 Terraformでリソースをコード管理をしている場合、大抵gitでバージョン管理している terraform applyしたものがまずかった場合、どの差分によるものか、いつから発生していたものなのか、誰の実行によるものかといった情報が欲しくなる backendをgcsなどにしている場合、オブジェクトのバージョニングを有効にしていれば、いつオペレーションが実行されたかなどを追える 事故ってたケースの調査などで特に欲しい revisionの情報や実行者の情報は素のTerraformでは分からないので、何かしらの形で情報を埋め込みたい やってみたこと: makeで情報を外から与える varで外から情報を与えてみる形を考えてみました。こんな感じで変数とoutputを定義しておきます。 variable "current_revision" { description = "terrafor
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
