インフラ構成ツールの「Pulumi 3.0」正式リリース。APIでPulumiを呼び出し可能、クラウドのアップデートに即時対応など
インフラ構成ツールの「Pulumi 3.0」正式リリース。APIでPulumiを呼び出し可能、クラウドのアップデートに即時対応など コードを用いてクラウドをはじめとするITインフラの構成を定義できる、いわゆるInfrastructure as Codeツールの「Pulumi」が、最新版となる「Pulumi 3.0」として正式リリースされました。 Announcing our new #CloudEngineering Platform (Pulumi 3.0)! Native providers with 100% API coverage Pulumi Packages to share #cloud components Automation API for programmatically deploying infrastructure from code Enterprise-g
こんにちは、株式会社FIXER＠名古屋オフィスの村上です。 クラウドインフラのシステム基盤構築にTerraformを採用している組織は多いですね。村上自身は特別な要件がない限り、”どのクラウドを使う場合でも” システム基盤構築にはTerraformを使いたいと考えているインフラエンジニアです。 私は、Terraformを3年間使用する中で、6つの課題に直面してきました。 このブログでは、実際の開発現場でどのような問題が起こったのか、またその問題をどのように回避、あるいは対策すべきだったのかについて、綴ってみました。 【課題１】プロジェクト始動直後にTerraform開発を開始したため、後工程で改修タスクが多発 SI案件では、クライアントが提案する調達要件RFPをもとに、ITベンダーがヒアリングを行いながら要件定義を進めていきます。 要件定義の一例として以下のようなものがあります。 クラウド
Terraformのライセンスの変更とその影響
はじめに 先日、HashiCorp社はの発表により、すべての製品といくつかのライブラリの将来のリリースについて、Mozilla Public License v2.0（MPL 2.0）からBusiness Source License（BSL、またはBUSL）v1.1への移行するがわかりました。 ただし、HashiCorpのAPI、SDK、およびほとんどの他のライブラリはMPL 2.0のままです。 BSLとは? MPL 2.0との違いは? BSLは下記のようにいくつの特徴があります: 特定の期間（通常は数年）の後に、完全なオープンソースライセンス（たとえば、Apache 2.0）に変わるライセンスである。 BSLの下でリリースされたソフトウェアは、特定の期間中は商業的に利用することが制限される。 開発者がソフトウェアの商業的価値を保護しつつ、将来的にはコミュニティに還元することを目的として
ソフトウェア開発、ITインフラ運用、そしてその境界線上にあるトピックをカバーし、特にDevOpsを実現するための自動化、テスト、セキュリティ、組織文化にフォーカスした「DevOpsDays」。ここでソフトウェアエンジニアのチェシャ猫氏が「Infrastructure as Code の静的テスト戦略」をテーマに登壇。まずはInfrastructure as Codeについてと、そのつらみから発生する“オートメーション恐怖症”を防止する方法を紹介します。 「コード化の“つらみ”をいかにうまく防ぐか」が今日のテーマ チェシャ猫氏：チェシャ猫と言います。Twitterは@y_taka_23の名前でやっているので、よろしくお願いいたします。今日は「Infrastructure as Code の静的テスト戦略」をテーマに選びました。Infrastructure as Codeはここ数年で、非常にメ
3/30 に X で Terraform がトレンド入りしていて何事かと思ったら Terraform が公式ドキュメントとしてスタイルガイドを出したようです。 Terraform Style Guide いままで Terraform のスタイルに関して信頼できるドキュメントといえば Google Cloud の Terraform を使用するためのベスト プラクティス ぐらいしか知らなかったのですが、 Terraform 公式がようやく出してくれてありがたい限りです。 これでわざわざ社内の Terraform 規約を設けずとも「公式ドキュメントに従いましょう。」の一言で済みます。 ということで一通り読んだのでまとめました。 原文だと構文の簡単な使い方なども書いてありますが以下の要約ではだいたい省略しています。 詳細は原文を読んで確認してください。 要約 スタイルガイドについて コードのスタ
こんにちは、LayerX で主にインフラを担当している高江です。 今回は、一見地味ではありますが実はとても役に立つ機能である Terraform import についてお話したいと思います。 Terraform import とは 公式サイトでは次のように説明されています。 Terraform is able to import existing infrastructure. This allows you take resources you've created by some other means and bring it under Terraform management. 要するに、AWS 等のサービスプロバイダー上に既に存在する、Terraform 管理されていないリソースの情報を取得して Terraform 管理下に置く(tfstate ファイルに import する)
TerraformのStateやModuleに関する設計 - tom-256.log
概要 名前付け 抽象度 インフラアーキテクチャ図 チーム 認証情報 変更(デプロイ)のライフサイクル DRYの誤用 コードの検索性 モジュール間の依存 アプリケーションレイヤーとの違い まとめ 概要 TerraformのStateやModuleに関する設計に関する考慮点をざっくり書く 名前付け ユビキタス言語とディレクトリ名や変数名を合わせて認知不可を下げる リソース名でなく役割・機能ベースのディレクトリ名にして認知不可を下げる プロダクトのコードネームはユビキタス言語なのでディレクトリ名にしても問題ない ModuleやStateのREADME.mdを書く https://github.com/terraform-docs/terraform-docs を使う うまく説明が書けない場合は設計に問題がある可能性がある チームメンバーが利用できるように考慮する いつどのようなときに使えばいいか
Architecture as Codeってなぁに？ 〜Infrastructure as Codeを超えて〜 - NRIネットコムBlog
こんにちは、最近Alexaに好きな音楽を伝えるとそればっか再生されて飽きてきたので、どうAlexaに伝えれば傷つかないかを考えている志水です。 「APN AWS Top Engineers/APN Ambassadors Week」の3日目の記事になります。といっても、特にTop Engineerに関係ない話をします。 Architecture as Codeという言葉をご存知でしょうか？2019年のAWSのブログでArchitecture as Codeという言葉が出て、そこから一部のマニアックな方が言及されているのですが、イマイチ浸透せず可愛そうな状況になっています。個人的には面白い概念だと思い、かつ最近Architecture as Codeの概念を継承しているサービスのAWS Copilot/AWS Amplifyが盛り上がっているため、改めてまとめようと思います。 Infrast
ZOZOTOWN マイクロサービスプロジェクトにおける継続的な改善を支えるCI/CD戦略 - ZOZO TECH BLOG
ZOZOテクノロジーズ SRE部の川崎（@yokawasa）です。ZOZOTOWNのアーキテクチャをマイクロサービスで再設計してリプレイス化を推進するチームに所属しております。 本記事では、このZOZOTOWNのマイクロサービスプロジェクトで実践している継続的インテグレーション/継続的デリバリー（以下、CI/CD）についてご紹介します。 はじめに まずはじめに、本記事に登場する中心的なキーワードであるCI/CDと、Infrastructure as Code（以下、IaC）について簡単に説明します。 IaCとは、インフラ構成をコード化して、そのプロビジョニングを自動化する手法です。コード化されたファイルはコードリポジトリで管理することが多く、また、IaCを実現するためのツールやサービスの利用が不可欠になります。 CI/CDは、その名の通り、CI（継続的インテグレーション）とCD（継続的デリ
Best practices for using the Terraform AWS Provider - AWS Prescriptive Guidance
Michael Begin, Senior DevOps Consultant, Amazon Web Services (AWS) May 2024 (document history) Managing infrastructure as code (IaC) with Terraform on AWS offers important benefits such as improved consistency, security, and agility. However, as your Terraform configuration grows in size and complexity, it becomes critical to follow best practices to avoid pitfalls. This guide provides recommended
Infrastructure as Codeに関する技術書籍を執筆しました - How elegant the tech world is...!
Overview タイトルの通りですが、技術書博5向けにInfrastructure as Code (IaC)に関する技術書を執筆しました。 gishohaku.dev 一応、僕がそれなりにAWS x IaCにどっぷり浸かっていることもあり、題材のクラウドはAWSを主軸にしています。 TerraformやPulumiに関しては、別にAWSに限らずAzureやGoogleCloud利用者の方々にも通ずる部分があると思います。 執筆に至ったモチベーション 僕自身、IaCサービスに関してはCloudFormation 数ヵ月、terraform 2年、Pulumi 8ヶ月ほど経験しており、 それぞれの特徴も知れてきたのでナレッジを形にしたいなと思い、同僚と執筆しました。 ※ちなみに、共著の同僚である@HorseVictoryはAWS Top Engineersの一人です。 クラウドネイティブな
Infrastructure as Codeにおける理想のドキュメント管理を目指して #infrastudy | DevelopersIO
インフラをコードで管理するInfrastructure as Codeだからこそ、必要なドキュメントについての考察とそれの管理方法についてLTした様子です。 「なんや、この視聴者数… 震えが来るぜ・・・」 先日開催されたInfra Study Meetup #2「VM時代の開発とCloud Native時代の開発」 - connpassにおいて、「IaCにおける理想のドキュメント管理を目指す」という内容でLTしてきましたので、その内容をお届けします。 当日は、イベント内容も登壇者も超絶豪華で、なんとリアルタイム視聴者数1000人超えということで、さすがに自分も緊張しました。まじで。 青山さんのメインテーマがKubernetesの話であり、前後それに関わるテーマが中心の中、Kubernetesもコンテナも1ミリもでてこない発表にしたのですが、IaCに関わる普遍的な考慮ポイントについて喋れたの
AWS知見共有会でTerraformのCI/CDパイプラインのセキュリティ等について発表してきました + GitHub新機能Push rulesについて - LayerX エンジニアブログ
先日2024/04/16にタイミーさんのオフィスで開催された、AWS知見共有会というイベントで発表してきました。この会のテーマは「運用のスケーラビリティとセキュリティ」ということで、私は「コンパウンドスタートアップのためのスケーラブルでセキュアなInfrastructure as Codeパイプラインを考える」というタイトルで発表してきています。 イベントの動画もあります。 私の発表は 1:43 ぐらいからです。 この発表については資料と動画を見ていただければ！という感じで特に付け加えることもなかったのですが、イベントの開催後にGitHubから発表された新機能Push rulesがとても便利で、新たなベストプラクティスとなるインパクトがあると思ったので、この記事で紹介します。 Push rulesとは つい昨日発表された機能で、現在はpublic betaという状態です。なので、仕様変更と
クラウドを扱うエンジニアにとって「Terraform」は必須ツール!? 〜エンジニアが語る技術愛 ＃05〜｜ミクシル
ホーム カルチャー クラウドを扱うエンジニアにとって「Terraform」は必須ツール!? 〜エンジニアが語る技術愛 ＃05〜 ミクシィには、探究心溢れるエンジニアがたくさん在籍しています。 その探究心は業務で扱う技術にとどまらず、趣味で書いているプログラムだったり、個人的に研究している言語だったりと、自身の気になった技術への追求も留まることを知りません。 そこで、社内のエンジニアに“好きな技術”について、思う存分に語ってもらうシリーズを始めました。 ルールはこの通り。 ・業務で使っている技術でも、使われていない技術でもOK ・あくまでも個人的な見解で ・その技術のどこが面白いのか ・愛を込めて語り尽くしてもらう 第5回目は、みてね事業部 開発グループ SREチームの清水に「Terraform」について語ってもらいました。 清水 勲（しみず いさお）Vantageスタジオ みてね事業部 開
HashiCorp、TerraformをフォークしたOpenTofuに対しコードの不正コピーを警告。OpenTofuは完全否定
HashiCorp、TerraformをフォークしたOpenTofuに対しコードの不正コピーを警告。OpenTofuは完全否定 HashiCorpは昨年（2023年）8月、Terraformを含む同社製品のライセンスを、商用利用に制限があるBusiness Source License v1.1（BSL1.1）に変更すると発表。これに反発し、ライセンス変更前のTerraformをフォークしたプロジェクトとしてLinux Foundation傘下で登場したのが「OpenTofu」です。 参考：Terraformのフォークが「OpenTofu」としてLinux Foundation傘下で正式ローンチ。OpenTFから改名 しかしHashiCorpはこのOpenTofuを歓迎するつもりはまったくなかったようです。 HashiCorpがOpenTofuにコードの不正使用を警告 HashiCorpは
Terraform はそのままだと管理が大変 みなさん IaC (Infrastructure as Code) してますか？パブリッククラウドをIaCするなら、 Terraform が便利ですね！ しかし、本格的に使い始めると、こういう問題がすぐに出てきます。 複数環境の楽な分け方を知りたい ワークスペースはなんか嫌だ とはいえ、環境間で共通するボイラープレートをどうにかしたい 環境内で適用するモジュールを細分化・分岐したいけど面倒 環境ごとに使うモジュールを切り替えたい テスト環境はAuroraではなく安いRDSにしたい モジュール(tfstate)を分割して小さい範囲で適用したい 大きなモジュールは影響範囲がわからないし、差分計算にそれなりに時間がかかってしまう 分けたモジュールを一括適用するのが面倒 モジュール間の依存関係がわからない モジュール(tfstate)間での値参照が面倒
※本記事は2022年1月22日に公開された記事の翻訳版です。 この記事は、Developer Productivity Engineering Campブログシリーズの一環として、Platform Infraチームの Daisuke Fujita (@dtan4)がお届けします。 メルカリでは、すべてのクラウドインフラを宣言的構成で管理することがプラットフォームの中核となる考え方の一つです。メインのクラウドプロバイダーはGoogle Cloud Platform（GCP）であり、HashiCorp Terraformを使用してインフラをコードとして管理しています。Platform Infraチームは、すべてのTerraformワークフローを安全に管理するための社内CIサービスを提供しています。 Terraformはリソースプロビジョニングのためにクラウドプロバイダーのクレデンシャルを必要と
Sign up for freeGet started in minutes with our cloud products TerraformInfrastructure as code provisioning
【Terraform🧑🚀】tfstateファイルの分割パターンとディレクトリー構成への適用 - 好きな技術を布教したい 😗
この記事から得られる知識 この記事を読むと、以下を "完全に理解" できます✌️ Terraformのtfstateファイルを分割する目的と、オススメの分割パターンについて (★) Terraformのリポジトリやリモートバックエンドのディレクトリ構成の設計について 記事のざっくりした内容は、以下のスライドからキャッチアップできちゃいます！ この記事から得られる知識 01. はじめに 02. なぜ tfstate ファイルを分割するのか 分割していない場合 分割している場合 分割しなくていい場合 03. tfstate ファイルの分割 分割の境界 状態の依存関係図 依存関係図とは 依存関係の表現 ▼ 依存関係の表現記法 ▼ 依存関係がない場合 ▼ 依存関係がある場合 04. tfstate ファイルに基づくその他の設計 リポジトリ 🐱 の設計 リポジトリ分割 ディレクトリ 📂 構成 リ
GCPで基本に戻って始める実践 Infrastructure as code再入門#1 - VisasQ Dev Blog
こんにちは！ 2020年2月からSREチームにJoinしました木村です! 仕事をする上での座右の銘は「明日交通事故にあってもシステムと仕事を回せるようにすること」です。 基本に戻って始める。と表題では書いていますが、私元々はAWS職人でGCPに本格的にコミットしてからまだ3ヶ月位です! なのでヒィヒィ?言いながらGCPのキャッチアップに努めているわけですが今回は過去にAWSで得たInfrastructure as Codeの知識とビザスクに入社してキャッチアップで培ったGCPの知識を元に基本に戻って始めるGCPのInfrastructure as Code再入門ということで書かせていただきます。 尚実際に書き始めたら量が膨大になってしまったのでいくつかパートに分けて 書いていきたいと思っております。 今回やること GCPのCompute Engineをスコープとして Terraformを使
こんにちは、koidです。 この記事は Gunosy Advent Calendar 2021 - Adventar の25日目の記事です。 昨日の記事は aitaさんの EKSにJupyterHubを構築した - Gunosy Tech Blog でした。 ドキュメントの更新って面倒だし忘れがち ドキュメントのメンテナンスを自動化しよう コードからドキュメントを自動生成する ツールの利用によるドキュメント生成 CIによるドキュメント生成の自動化 状態からドキュメントを自動生成する ツールの利用によるドキュメント生成 CIによるドキュメント生成の自動化 まとめ ドキュメントの更新って面倒だし忘れがち 本題です。 みなさん、Pull Requestのレビュー時に、 ドキュメント・READMEも修正お願いします！ こういったコメントをした/された経験ってありませんか？ コメントをする側としても
目的に沿ったDocumentation as Codeをいかにして実現していくか / PHPerKaigi 2021
https://fortee.jp/phperkaigi-2021/proposal/42ce8b07-6972-42bb-a2ac-96af7249cfa4 あるシステムを理解して開発を開始するとき、必要なのはInfrastructure as Codeを含むソースコードだけでは大抵の場合は不十分です。では挙動がわかるようなテストコードがあれば十分かというとそうでもありません。 いわゆる「オンボーディングの効果的な運用」「開発開始までのオーバヘッドの削減（PHPerKaigi2020で発表）」は継続的な生産性向上のためには考えなければならない要素です。 そして、上記を補完するためにしばしばドキュメントが書かれます。 私はドキュメント運用のアプローチとして「コードによる生成を含んだドキュメント運用」に興味を持っています。 私はこれを「Documentation as Code」と呼んでいま
今時の現場では、管理対象のリソースの大半はIaC(Infrastructure as a Code)化されており、 PRを契機にリソースのプロビジョニングを行うように綺麗に管理されている現場も多いかと思います。 一方で、前任のインフラ担当がリソースをIaC化せずに退職してしまったような荒れた現場や、 あるいはIaC化が浸透しきっておらず、部署によっては担当者がWebコンソールを介してリソースを作ってしまっているような現場もまだまだ存在します。 通常、そのような現場の場合、コード管理されていない野良リソースの追跡は困難を極めますが、 それを手助けするツールとして、driftctlというツールが登場しました。 driftctlとは driftctlは、IaC化されていない野良リソース——driftctlの文脈で言うところのDrift——を検知するツールです。 また、厳密には異なりますが、Ter
AWS CDKでクラウドアプリケーションを開発するためのベストプラクティス | Amazon Web Services
Amazon Web Services ブログ AWS CDKでクラウドアプリケーションを開発するためのベストプラクティス この記事では、AWS Cloud Development Kit (AWS CDK) を中心とした、大規模なチームで複雑なクラウドアプリケーションの開発を組織化するための戦略について説明します。AWS CDK では、開発者や管理者は、TypeScript、Python、Java、C#などの使い慣れたプログラミング言語を使ってクラウドアプリケーションを定義することができます。アプリケーションは、Stage、Stack、Constructに整理されており、ランタイムロジック (AWS Lambda コードやコンテナ化されたサービスなど) と、Amazon Simple Storage Service (Amazon S3) バケット、Amazon Relational D
Hidekazu Konishi - Profile / Biography | hidekazu-konishi.com
Hidekazu Konishi - Profile / Biography | hidekazu-konishi.com About Hidekazu Konishi Hidekazu Konishi is a Japan AWS Top Engineer, Japan AWS All Certifications Engineer (having passed All AWS Certification Exams), Cloud Engineer (specializing in Architecting and DevOps), Application Engineer, Prompt Engineer, and Tech Blogger. After gaining experience as an application engineer, he was assigned to
はじめに 必要に応じて検証環境の追加・削除などの管理をするのが面倒くさいので、PR作成時に検証環境を構築、PRマージ・クローズ時に検証環境を削除ができないか考えてみました。 今回の作成したGitHub Actions ワークフロー、Terraformなどはこちらのリポジトリにあります。 概要図 どのように実現したか 実現あたり、コンテナイメージのプッシュ、ECS サービスのデプロイはGitHub Actions、Terraformの実行はAWS CodeBuildで行うことにしました。 なぜTerraformの実行はCodeBuildを利用するようにしたかというと、CodeBuildはVPC内のリソース（今回の場合はAurora Serverless）にアクセスできるからです。 これによってアプリケーション、DBマイグレーション時に使用するMySQL ユーザーをTerraformで作成する
Infrastructure As Codeにおいて、コードのモジュール化により再利用性を高めることが難しいと言われている。それはなぜなのかを考察する。 Infrastructure as Codeで痛い目あった人ってだいたいやりすぎてる気がする(偏見)。過度な抽象化とか共通化、公開されているrecipeを無闇に使っちゃうみたいな。特に抽象化まわり、普通のプログラミングのつもりできれいに整理しようとするとやり過ぎになりがち— fujiwara (@fujiwara) 2020年3月30日 自分が経験したIaCアンチパターンは、例えばnginxのchefコードを再利用しようとしてnginxのパラメータを全部外部注入できるようなモジュールを作るやつですね。コストが上がり過ぎる #InfraStudy— そのっつ (Naotoshi Seo) (@sonots) 2020年4月24日 １つ目の理
Infrastructure as data in PostgreSQLInspect and provision cloud infrastructure via a PostgreSQL database Get started How IaSQL worksIaSQL is an open-source developer tool that maintains a 2-way connection between your AWS account and a PostgreSQL database. The rows in the database tables represent the infrastructure in your cloud account.
Terraformがバージョン1.0に到達、正式版に。AWSやAzure、VMwareなどマルチクラウド対応のプロビジョニングツール
Terraformがバージョン1.0に到達、正式版に。AWSやAzure、VMwareなどマルチクラウド対応のプロビジョニングツール HashiCorpがオープンソースで開発しているマルチクラウド対応のプロビジョニングツール「Terraform」がバージョン1.0に到達し、正式版となりました。 Today we are announcing the GA release of #Terraform 1.0. This marks a major milestone for interoperability, ease of upgrades, and maintenance for your automation workflows for what has become a standard for cloud provisioning. #HashiConf https://t.co/
メルペイの Infrastructure as Code について、 HashiCorp Certified: Terraform Associate を受験した SRE に聞いてみた | メルカリエンジニアリング
メルペイの Infrastructure as Code について、 HashiCorp Certified: Terraform Associate を受験した SRE に聞いてみた こんにちは。メルペイ Engineering Office チームの kiko です。先月、 HashiCorp Certified: Terraform Associate がリリースされましたね。早速 @tjun さん（メルペイ SRE, Engineering Manager ）と @keke さん（メルペイ SRE ）が受験していました。というわけで、今回はこのお二人に、試験の話とメルペイの Infrastructure as Code について聞いてみました。 サマリー メルペイでは、クラウドのリソースや Datadogのダッシュボードなど様々なことをTerraformでコード化して管理している
AWSのインフラ管理はIaC? いやちゃうちゃう。時代はInfrastructure as SQL (IaSQL)でしょ - Qiita
AWSのインフラ管理はIaC? いやちゃうちゃう。時代はInfrastructure as SQL (IaSQL)でしょAWSPostgreSQLIaCQiitaEngineerFesta2022IaSQL 概要 皆さんAWSのインフラ管理どうしてますか？ なるべくならインフラ管理は自動化。手順書も作らず、資源作成時誰でもどの環境に対し同じものを作成したいですよね。 そんな時、Infrastructure as Code（IaC)を採用し、インフラ管理をコード化するのは当たり前になってきているんじゃないでしょうか。 AWSにおけるIaCだと例えば、Cloudformationとか、AWS CDKとかTerraform等、様々です。 ただ今回は、そんなIaCの紹介・・・ではなく、全く新しい概念のInfrastructure as SQL (IaSQL) なるものについて、ご紹介したいと思いま
22/8/25 HashiTalks:Japanにて発表
「Terraformデプロイパイプラインを作るなら、どのツールが自分の組織にあっているのだろう？」 Terraformのデプロイパイプラインの実装方法は、選択肢が多くて迷ってしまいます。 この記事では、デプロイに使用できるツールをまとめてみました。 デプロイパイプラインのツール選定の参考になれば幸いです。 前提 Terraformは様々なリソースを管理することができますが、今回はAWSリソースをTerraformで管理する想定としています。 所々AWS固有の単語がでてきますが、ご了承ください。 なぜTerraformのデプロイパイプラインは必要なのか？ デプロイフローをおさらいして、デプロイパイプラインなしの運用の課題を考えてみます。 Terraformのデプロイフロー Terraformで構成管理している場合、リソースの設定変更時は以下のようなフローで行うことが多いです。 コードの編集
本記事は 【プルリクウィーク】 2日目の記事です。 💻 1日目 ▶▶ 本記事 ▶▶ 3日目 📚 はじめに Git と インフラ屋 と IaC そもそもインフラ屋が管理するコードとは？ IaC インフラ関連の設定ファイル CI/CD周りの設定ファイル PRレビューで難しいと思うこと 何を持ってOKとするか そもそも検証が難しい 網羅性が判断つかない PRレビューで意識していること 静的チェックの導入 コメントには意向を示す略語を付ける コメントがFixすればリアクションしてクローズする 対面レビューの時間を設ける リリースとの親和性が高い さいごに はじめに こんにちは、加藤です。 普段、私はインフラエンジニア（以下インフラ屋）としてシステム運用に携わっています。 最近はIaCの普及もあり、インフラチームでもプルリクエスト(以下PR)レビューを実施しているチームが多いのではないでしょうか
今回は TerraformのAWS Providerの便利機能default tagsをご紹介します。 やりたいこと 一連のリソースに同じタグを付けてタグでリソース管理をしたい時、あると思います。よくあるのが同一アカウント内に複数環境(開発/テスト/本番など)のリソースを作成するとき。また、コスト配分タグという機能を使えば、タグごとにコストをグルーピングすることができ、こちらも非常に便利です。タグの活用パターンについては以下にまとまっていますのでご確認いただければと思います。 ただ、どうやって各リソースに同じタグを設定すれば良いでしょうか。各リソースを作成時に都度都度タグの定義をしていては、抜け漏れとかタイポが発生しそうですよね。 そこでdefault tags この機能を使えば、各リソースに散らばってしまうタグ付与の設定を一元化することができます。TerraformのAWS Provid
既存のAWSリソースを簡単にTerraformに落とし込めるTerraCognita - Qiita
Saleshubでエンジニアをしております。 安田と申します。 今回はTerraCognitaというツールについて書いてみたいと思います。 AWSやGCPなどのクラウドサービスを利用されているエンジニアは多いと思います。 そしてこれらのサービスをWeb UI上で操作してアプリケーションのクラウド環境を構築している会社や個人も多いと思います。 Web UIで構築された環境。後で何やったかわからない その一方で今やクラウド環境はIaC(Infrastructure as code)で構築するのが当たり前でしょう！と言われたりします。実際、Web UIで構築された環境は、構築後時間が経つと「どうなってんだっけ、これ？」ってなったり、構築したメンバーが退職したりすると、引き継いだメンバーにとってトラップだらけのラビリンスになってしまったりします。 じゃあ、どうすればいいのか？ これに答えてくれてい
スタディスト開発ブログ 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
AWSでTerraformの実行を自動化する環境を作成しました。 github.com AWS内で閉じた形で、Terraformを使い、自動的にAWSリソースを作成する前提です。 Terraformを実行する環境はCodeBuildで用意しました。 その実現方法を紹介します。 環境作成 ディレクトリ構成 terraform-auto-apply-example直下には、自動化の環境を作成するためのtfファイル（main.tf、codebuild.tf）があります。 exampleディレクトリ内のtfファイルが自動実行の対象になります。 terraform-auto-apply-example ├── Dockerfile ├── README.md ├── buildspec.yml ├── codebuild.tf ├── docker-build.sh ├── example │
概要 今回はTerraformを使って VPC パブリックサブネットとプライベートサブネット IGW ルートテーブルおよびルーティングの設定 Elastic IP NATゲートウェイ を構築したいと思います 今回作成するインフラ構成は下記の図のようになります 前提 東京リージョンを使用 AWSを使用 main.tfとvariables.tfを設定済み ネットワークに関する基本的な知識をある程度持っている 上記のファイルをまだ作成していない方は下記の記事を参考にしてください AWSにおけるネットワークの概要について知りたい方は以下の記事を参考にしてください また、コンテナ経由でTerraformを使用すると複数ブロジェクトで使用する際にバージョンによる違いを意識せずに済みます コンテナを使用したい方はこちらの記事も参考にしてみてください ディレクトリ構成 構成は以下の通りです # -----
July Tech Festa 2021に「AWS CDKとTerraformをn個の観点で徹底比較」というタイトルで登壇しました | DevelopersIO
はじめに CX事業本部 IoT事業部の佐藤智樹です。 July Tech Festa 2021 というイベントで「AWS CDKとTerraformをn個の観点で徹底比較」というタイトルで登壇しました。 登壇資料 登壇経緯 以前のPJで両方使う機会があったのと、たまたま今回のイベントのテーマが「#今更聞けないIT技術」であり、議題として挙がった中の一つに「AWS CDKとTerraformどっち選べばいいの？」という質問がありせっかくなので話してみようと思い登壇しました。 伝えきれなかった内容 登壇時は喋りきれなかったのですが改めて知識を整理し直すと以下の2点が重要かなと思ったのでこちらに記載します。比較というよりは改めて気にした方が良いかなと思った内容です。 公式資料の再確認 どちらもツールが出始めた時期は手動で色々試している方が多く有志の方の知見がたくさんあります。しかしながら、普及
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Terraformを採用する前に知っておくべき6つの課題
Infrastructure as Codeのつらみの原因を探れ 恐怖症による負のサイクルを断ち切る“予測可能性”
Terraform 公式がスタイルガイドを出したので読んで要約した - Qiita
Terraform import のススメ 〜開発効率化編〜 - LayerX エンジニアブログ
Terraform だけだとハードモードなので Terragrunt を使おう - Qiita
TerraformモノレポCIのセキュア化 | メルカリエンジニアリング
Testing HashiCorp Terraform
面倒なドキュメント生成はCIにやらせよう - Gunosy Tech Blog
IaC化されていないリソースをdriftctlで検知する
GitHub Actions + AWS CodeBuildでPRごとの検証環境を作ってみた
Infrastructure As Codeでモジュール化が難しいのはなぜなのか - ゆううきメモ
Infra as SQL | IaSQL
ベストな Terraform ディレクトリ構成を考察してみた
Terraformのデプロイパイプラインに使用できるツールをまとめてみた | DevelopersIO
とあるインフラ屋のプルリクエストレビュー奮闘記 - NRIネットコムBlog
Terraformなら簡単に全AWSリソースに共通タグを設定できます | DevelopersIO
Terraform Cloud から GitHub Actions に移行したお話
AWSでTerraformの実行を自動化する方法 - なになれ
Terraformを使ってAWSのVPCをはじめとしたネットワークを構築しよう！ - Qiita