アプリケーションのデフォルト認証情報の仕組み | Google Cloud
フィードバックを送信 アプリケーションのデフォルト認証情報の仕組み コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 このページでは、アプリケーションのデフォルト認証情報（ADC）が認証情報を探す場所について説明します。ADC の仕組みを理解することで、ADC で使用されている認証情報と、その認証情報の検出方法を理解できます。 Application Default Credentials (ADC) は、アプリケーション環境に基づいて認証情報を自動的に検索するために Google 認証ライブラリが使用するストラテジです。認証ライブラリは、これらの認証情報を Cloud クライアント ライブラリと Google API クライアント ライブラリで使用可能にします。ADC を使用すると、Google Cloud サービスと API に対するアプリケーションの認
Terraform 1.5 で実現する config-driven なインポート作業 | はったりエンジニアの備忘録
Terraform 1.5 で追加された import ブロックと -generate-config-out フラグを組み合わせると、既存のパイプラインの中で安全にインポート作業が行えるようになります。 Hashicorp ではこのことを "config-driven import" と呼んでいます。 Terraform 1.5 brings config-driven import and checks これまでは terraform import コマンドでリソースを 1 つずつインポートし、それを定義する HCL も自分で書く必要がありました。コマンドを実行すると即座に tfstate に反映されるので、HCL がマージされるまでの間にほかの人が誤ってリソースを削除してしまう危険性がありました。そのため、チームで共同作業するリポジトリでは気軽にインポートできませんでした。 Terra
Terraform職人のためのOpenTofu入門 - Qiita
この記事は クラウドワークス Advent Calendar 2023 シリーズ1 の 4日目の記事です。 はじめに 「父さんな、Terraform職人やめてお豆腐職人で食っていこうと思うんだ」と言いたいだけの @minamijoyo です。 2023年8月HashiCorpはこれまでMPL2のOSSライセンスで公開していた主要製品をBSL(Business Source License)に変更することを発表し、Terraformはv1.6.0からOSSではなくなりました。 このライセンス変更を受けて、OSS版のTerraformを求める人たちで、MPL2時点のコードベースからforkしたOpenTofuの開発が進められています。 HashiCorpのBSLは、実質的に競合他社の商用利用に制限をかけたもので、ほとんどの一般的なユーザに直接的な追加の制限はありませんが、間接的にTerrafo
Terraform Registryで公開されているTerraform Modulesが便利だった件
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
AWSの構成図をChatGPT(GPT-4V)に読み込ませてIaCコードを生成してみた | DevelopersIO
こんにちは、つくぼし(tsukuboshi0755)です！ 最近ChatGPTがGPT-4Vを発表し、AI業界がさらに盛り上がりを見せてますね。 GPT-4Vを用いる事で、ChatGPTがユーザ側から入力された画像を読み取った上で、応答を返してくれるようになります。 GPT-4V(ision) system card この機能追加により、なんと以下のようにAWSの構成図を読み取って、IaCコードを生成できる事が話題になっていました。 本日をもって引退します pic.twitter.com/fygAQDQ5kj — 電気ひつじ(onoteru) (@teru0x1) October 13, 2023 これを見て私もGPT-4Vを試してみたくなったので、今回はChatGPTを使って、様々なAWSの構成図を入力し、どこまで正確にIaCコードを生成できるか確認してみます！ GPT-4Vを利用する際
OpenTofuに関する雑感
2023年12月4日追記。 この記事は2023年の9月下旬に書かれた記事です。 わりと反射的に書いてしまった内容も含んでるので(CNCFのリリースにもコメントを寄越していたGruntworkの関わりを見逃してたのは痛恨のミス。色んな思いがあるのはそれはそう)、本件について語るにもっと最適な方の説明を読んでいただければ幸いです。 先月行われたHashiCorp社によるソフトウェアライセンスの変更はTerraformコミュニティに衝撃を与えたことは記憶に新しい。具体的には、Terraformのライセンスが、オープンソース/フリーソフトウェアを前提としたMPL2.0から、商用利用に制限をかけられたBSLv1.1に変更された。これにより、Terraformは伝統的な意味でのオープンソースソフトウェアではなくなってしまい、ソースコードが単に利用できるソフトウェアに変わってしまったと評する人もいる。[
Terragruntでより幸せなTerraform生活を目指す
これは何？ TerraformをリファクタリングするにあたってTerragruntを利用できないか検証する機会があったので、簡単なサンプルを作ってゆるくまとめました。 Terragrunt is 何？ Terragruntは Gruntwork.io が出しているOSSであり、Terraformをより便利に扱えるようにするための薄いwrapperです。Terragruntを利用することで以下のような構成のTerraformをいい感じにリファクタリングできます。 . ├── envs │ ├── dev // 配下のディレクトリ単位でtfstateが別れている │ │ ├── iam │ │ ├── elb │ │ └── network │ └── prd // devと同じような感じで個別のリソース単位でディレクトリが存在する └── modules //
Terraform だけだとハードモードなので Terragrunt を使おう - Qiita
Terraform はそのままだと管理が大変 みなさん IaC (Infrastructure as Code) してますか？パブリッククラウドをIaCするなら、 Terraform が便利ですね！ しかし、本格的に使い始めると、こういう問題がすぐに出てきます。 複数環境の楽な分け方を知りたい ワークスペースはなんか嫌だ とはいえ、環境間で共通するボイラープレートをどうにかしたい 環境内で適用するモジュールを細分化・分岐したいけど面倒 環境ごとに使うモジュールを切り替えたい テスト環境はAuroraではなく安いRDSにしたい モジュール(tfstate)を分割して小さい範囲で適用したい 大きなモジュールは影響範囲がわからないし、差分計算にそれなりに時間がかかってしまう 分けたモジュールを一括適用するのが面倒 モジュール間の依存関係がわからない モジュール(tfstate)間での値参照が面倒
GitHub - opentofu/opentofu: OpenTofu lets you declaratively manage your cloud infrastructure.
Manifesto About the OpenTofu fork How to install Join our Slack community! Weekly OpenTofu Status Updates OpenTofu is an OSS tool for building, changing, and versioning infrastructure safely and efficiently. OpenTofu can manage existing and popular service providers as well as custom in-house solutions. The key features of OpenTofu are: Infrastructure as Code: Infrastructure is described using a h
OpenTofu
Truly open-sourceunder a well-known and widely-accepted license that companies can trust, that won’t suddenly change in the future, and isn’t subject to the whims of a single vendor. Community-drivenso that the community governs the project for the community, where pull requests are regularly reviewed and accepted on their merit.
HashiCorp adopts Business Source License
TerraformInfrastructure as code provisioning
なぜ脱OSSが増えているのか？
はじめに TerraformやVaultを開発するHashiCorpは自社製品をOSSのMPL(Mozilla Public License v2.0) から、ソースコードは公開するも一部の利用に制限があるBSL(Business Source License) への変更をアナウンスしました。 これは2018年のRedisを皮切りにMongoDBやCockroachDB、ElasticSearchなど多くのプロダクトで進められている脱OSSの流れです。商用のオープンソース[1]と言われてしまうこともある最近のこの動きの理由は何故なのか？ という点を以下の動画で解説しました。 動画中では尺の都合で端折った個所も多いので、こちらの記事の方にもまとめておきたいと思います。 OSSとは？ OSSの定義 まず、OSS（オープンソース）とはなんでしょうか？ これはRMSのフリーソフトウェアを源流とする
Terraform構成をビジュアライズできるツール Pluralithを使ってAWS構成図を自動作成してみる | DevelopersIO
CIに組み込むことで真価を発揮するツールかと思うので、Localは検証・実運用はCIといった使い分けをするのが良さそうです。 やってみた 今回はLocalで試してみます。 Pluralith CLIのインストール 利用にはユーザー登録が必要です。 以下のページからユーザー登録します。 Pluralith サインインができたら以下のページに遷移します。 Localで試したいため、Local Setupを選択します。 Download CLIでバイナリをダウンロードして、macの場合は以下のコマンドでcliを利用できるようにします。 mv pluralith_cli_darwin_amd64_v0.2.2 pluralith mv pluralith /usr/local/bin/ chmod +x /usr/local/bin/pluralith ブラウザで表示されているAPI Keyを使っ
Terraformがノーコードに。HashiCorpが「Terraform Cloud ノーコードプロビジョニング」正式リリース
Terraformがノーコードに。HashiCorpが「Terraform Cloud ノーコードプロビジョニング」正式リリース HashiCorpは、マルチクラウド対応のインフラ構成サービス「Terraform Cloud」をノーコードで設定、実行できる新機能「Terraform Cloud ノーコードプロビジョニング」を正式にリリースしたことを発表しました。 これまでTerraform Cloudでインフラを構成するには、スクリプト言語「HCL」（HashiCorp Configuration Language）を用いて構成を記述する必要がありました。 「Terraform Cloud ノーコードプロビジョニング」では、こうしたプログラミングやTerraformの専門的な知識がなくともインフラを構成することができます。 HashiCorp #Terraform Cloud no-cod
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - threatcl/threatcl: Documenting your Threat Models with HCL
Terraform Style Guide | Gruntwork Docs
CI / CD Deployment of Conditional Access Policies for a Zero Trust Architecture Framework using Terraform and GitHub Actions
Terraformでmoduleを使わずに複数環境を構築して感じた利点
CodeShield - Simplify AWS IAM Security
Terraform Registry