Terraform state 概論 - chroju.dev
この記事は terraform Advent Calendar 2019 - Qiita の 14 日目です。 Terraform State （以下、本記事では tfstate と呼称します）をご存知でしょうか。 Terraform を使っていて tfstate をご存知ではない人はまぁまずいないはずだとは思いますが、直接の編集が非推奨となっているためデリケートな扱いが求められる一方で、 Terraform を使っていると折に触れて立ち向かわなくてはならない憎いやつです。 Terraform を上手く使うことは、 tfstate を上手く取り扱うこととニアリーイコールだと個人的に思っています。そんな tfstate のことをいろいろとまとめてみました。ていうかまとめすぎてえらいことになったので、年末年始のお暇なときにでも読んでみてください。 全体は以下4つに分かれています。 tfstat
Terraform導入への第一歩 - BASEプロダクトチームブログ
この記事はBASE Advent Calendar 2020の3日目の記事です。 devblog.thebase.in BASE株式会社 SRE Groupの相原です。 BASEのインフラはAWS上に構築しておりいくつかのツールを使って構成管理していますが、主にEC2のサーバ設定ツールとして利用しているのが現状で、構成管理できていないAWSリソースもちらほらあります。 そこでまずはSRE Groupで使っている社内ツールや、直接サービス影響のないものをTerraformで構成管理をしてみて、ある程度運用が固まってきたら主サービスの管理もそちらに寄せていこうという方向で進んでいます。 Terraform導入にあたり最も悩んだのがtfstateの分け方とディレクトリ構成だったので、そこをメインに紹介できればと思います。 謝辞 以下の書籍と記事を非常に参考にさせていただきました。ありがとうござい
Terraform AWS Provider Version 4がリリースされました | DevelopersIO
2022/2/11に Terraform AWS Provider Version 4がリリースされました。2/22現在、もうVersion 4.2まででています。実際に触ってみて何が変わったのか確認したいと思います。 aws_s3_bucketの大規模リファクタリング 要は「aws_s3_bucketがデカくなりすぎて大変だから、細かく分けようぜ！」ということです。 御存知の通りS3は非常に多機能です。そしてTerraformではその機能の殆どをaws_s3_bucketのattributeで設定していました。 以下はaws_s3_bucketのコード例です。 resource "aws_s3_bucket" "v3" { bucket = local.bucket_name acceleration_status = "Enabled" acl = "private" cors_rul
TerraformのAWS Provider v4メジャーアップデートは破壊的変更あり - Qiita
resource "aws_s3_bucket" "mybucket" { bucket_prefix = "myname-" acl = "private" versioning { enabled = true } server_side_encryption_configuration { rule { apply_server_side_encryption_by_default { sse_algorithm = "AES256" } } } } Error: Value for unconfigurable attribute │ │ with module.common.aws_s3_bucket.mybucket, │ on ../../s3.tf line 1, in resource "aws_s3_bucket" "mybucket": │ 1: resource "
IaC化されていないリソースをdriftctlで検知する
今時の現場では、管理対象のリソースの大半はIaC(Infrastructure as a Code)化されており、 PRを契機にリソースのプロビジョニングを行うように綺麗に管理されている現場も多いかと思います。 一方で、前任のインフラ担当がリソースをIaC化せずに退職してしまったような荒れた現場や、 あるいはIaC化が浸透しきっておらず、部署によっては担当者がWebコンソールを介してリソースを作ってしまっているような現場もまだまだ存在します。 通常、そのような現場の場合、コード管理されていない野良リソースの追跡は困難を極めますが、 それを手助けするツールとして、driftctlというツールが登場しました。 driftctlとは driftctlは、IaC化されていない野良リソース——driftctlの文脈で言うところのDrift——を検知するツールです。 また、厳密には異なりますが、Ter
Terraformのディレクトリパターン集 - Qiita
AWSやGCPのみならず、GitHubやDatadog等、様々なサービスをTerraformでコード化して管理できるようになり、世はまさに大Terraform時代となりました。 そんな時代の中、人類誰もが一度はTerraformのディレクトリ構造で悩んだことがあるのではないでしょうか？ 様々なベストプラクティスが提案されてきましたが、デファクトスタンダードと言えるものが未だ登場していないイメージがあります。 背景 なかなかスタンダードな構成が決まらない背景には、以下の要因が影響していると思われます。 環境ごとの差異がどれだけあるかは人それぞれ 本番環境とステージング環境は完全に同一の構成であることが理想です。 同一の構成をとることで、ステージング環境では発生せず、本番環境でのみ発生する不具合を減らすことができるからです。 しかし、様々な理由でどうしてもステージング環境と本番環境の間に差異が
Terraformなにもわからないけどディレクトリ構成の実例を晒して人類に貢献したい - エムスリーテックブログ
こんにちは、エムスリーエンジニアリンググループの福林 (@fukubaya) です。 さいたまスーパーアリーナは、埼玉県さいたま市中央区にある多目的アリーナ。本文には特に関係ありません。 最近、Terraformを書くことが多く、知見が貯まりつつあった時にちょうどディレクトリ構成に関する記事を読んでタイミングがよかったので、 今回はTerraformのディレクトリ構造の実例を晒したいと思います。 結構固まってきたからうちのチームの構成も晒してみようかな。 | Terraformのディレクトリ構成の模索 - Adwaysエンジニアブログ https://t.co/31FMkcCJOo— Yuichiro Fukubayashi (@fukubaya) July 3, 2020 クラウド化推進 なぜ定番が決まらないのか 前提となる条件 本番環境と検証環境はほぼ同じ構成 レポジトリとtfstat
AWS CDKでプロバイダーとしてTerraformが使える！！CDK for Terraformが発表されました！！ #awscdk | DevelopersIO
AWS CDKでプロバイダーとしてTerraformが使える！！CDK for Terraformが発表されました！！ #awscdk AWS CDKがデプロイプロバイダーとしてTerraformをサポートしました！！！まだPreview版ですが、試しにVPCを作成してみました。 はじめに おはようございます、加藤です。私にとっては今年1番熱いアップデートが来ました！AWS CDKがなんとデプロイプロバイダーとしてTerraformをサポートしました！！！ ただし、今の所アルファテストステージなので、原則プロダクション環境に使うべきでありません、使う際は慎重に判断してから使用しましょう。 今まで、TerraStackIO/terrastackという同様にCDKでプロバイダーとしてTerraformを使おうとするプロジェクトはあったのですが、あまり開発は進んでいませんでした。なので、これまで
複数の Terraform state を結合する tfstate-merge を書いて20個以上の state を大統一した - 酒日記 はてな支店
あるところに、ひとつの Web サービスの本番環境が 20 個以上の Terraform state で管理されているリポジトリがありました。 おもに AWS 上で動いている、大変年代物かつ巨大なモノリスのサービスです。最初は何もコード管理されていない状態から徐々に Terraform を導入したのですが、その際に「一度に全部管理はできないから、徐々に Terraform 化していこう」という方針で管理を始めたところ… 新機能を追加するのでそのリソースを別 state で管理 改修があるのでそれらのリソースを別 state で管理 を繰り返すうちに、中に数個程度しかリソースがない state がどんどん増殖し、いつの間にやら20個以上になってしまったという状態です。ちなみにリソース定義は合計で 500 程度ありました。 さすがにここまで分割されてしまうと相互参照はできないし、VPC / S
AWSで学ぶコンテナの基礎 (0) はじめに | 外道父の匠
コンテナ。それは便利そうではあるが、面倒くさそうであり、積極的に取り入れるべきか微妙な存在。 個人的な感想としては、慣れるまでそれなりに大変・慣れれば楽しく便利。そう、つまり触ってみないと何もわからない、いつものヤツだ！細かいことはスッとばして、最低限の感触を掴むための構築手順を AWS + Terraform を用いて懇切丁寧に分解していくぞ！ 目的 AWSはチョットデキルし、コンテナに触れてみたいんだけど、何から手を付けたらいいかよくわからない。くらいのコンテナ初心者向けの内容にしていきます。コンテナ感覚を得るための具体的な構築メインなので、細かい話は飛ばし気味にいくため、ド素人向けではないです。 今回、構築するのはよくあるWEBサイトのような形をした超簡易的なコード管理とコンテナ運用で、それをAWSで表現していきます。これがスタンダードな構成だ、というわけではなく、これを１つのベース
既存のAWS環境を後からTerraformでコード化する | DevelopersIO
はじめに こんにちは、岩城です。 既存のAWS環境をTerraformでコード化する機会がありました。その際、Terraform素人であったため、コード化する流れを掴むまでに少し時間が掛かりました。 同じような方に向けて、備忘録として残しておきます。 用語解説 Infrastructure as Codeを実現するためのツール コードからインフラの構築/変更/バージョン管理を行える HashiCorp社が開発、オープンソース版とエンタープライズ版がある AWS、Azure、GCPを始めとするメジャーなクラウドプロバイダをサポートしている Providers 各クラウドの管理ツールで使わずにTerraformで管理できる AWS: Cloud Formation Azure: Resource Manager GCP: Deployment Manager コミュニティが活発でリリースが早い
Terraformの使い方 ver.2017冬 - Qiita
続きをかきました→ https://qiita.com/uraura/items/e13d883827443f27bf98 概要 TerraformでAWSのリソース管理をしていますが，(少人数でやるには1)まぁまぁ良い感じに落ちついたのでご紹介します． 以下，話を簡単にするためにTerraformでAWSのリソースを管理しているという前提で話をすすめます． 問題 Terraformは便利で，使いはじめると何でもかんでもコード化してやろう!!などと思ってしまいますが，すぐに以下のような問題にぶち当たります． コード化をすすめるとplan/applyにかかる時間が増大していく planが通ってもapplyでコケる場合がままある コード化をすすめるとplan/applyにかかる時間が増大していく コード化されてるリソースが少ないうちはあまり問題にならないのですが，時がたちコード量が増えてくると
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Terratest - インフラストラクチャテスト自動化のためのオープンソースのGoライブラリ