IBMによるHashiCorpの買収が正式に発表されました。買収価格は64億ドル（1ドル150円換算で9600億円）（HashiCorpの発表、IBMの発表）。 買収交渉が行われているとの報道が昨日から行われており、それが具体化したことになります。 HashiCorp is excited to join @IBM to continue building the platform of choice for multi-cloud automation. @armon shares his thoughts on how this serves our community, customers, partners, and product innovation: https://t.co/xBIN6FkVsE (link contains important information) p
はじめに 私が所属しているライフイズテックのデータ基盤グループで、ここ2年ほどでdbtとterraformを活用してDataOpsを進め、データ基盤の整備の生産性が向上した話をまとめます。 導入前の状況と課題 弊社のデータ基盤ではデータ基盤が綺麗に整備されていることよりも、プロダクトや事業に貢献できているかを重要と考え、まずデータを使える状態にすることを目指したサービスの導入や基盤構築を行いました。 考え方としてはこちらの DWHにおけるデータモデリングで大事にしている考え方に書かれている内容に近い考え方になります。 そのため、データモデリングの前にRedashやCRM AnalyticsというBIツール向けにデータレイクからデータマートを先に構築していました。 terraformとdbt導入前は、図のような流れで SQLでSnowflake上にDBやスキーマなどを作成 ELTサービスとし
As part of our goal to provide a comprehensive open source security solution for all, we have been consolidating all of our scanning-related efforts in one place, and that is Trivy. Over the past year, tfsec has laid the foundations to Trivy's IaC & misconfigurations scanning capabilities, including Terraform scanning, which has been natively supported in Trivy for a long time now. Going forward w
はじめに 私が所属しているライフイズテックのデータ基盤グループではSnowflakeを利用しています。 そのSnowflakeには、下記画像のようにデータベースやユーザーだけでなく、多くのリソースとその各リソースに対しての柔軟な権限設定が可能です。 今回はSnowflakeのアクセス制御にterraformを導入した背景とTerraform導入時の課題などをまとめます。 出典: アクセス制御の概要 | Snowflake Documentation 環境・バージョン情報 Terraform 1.4 snowflake provider 0.67 Terraform導入に至った背景 1. 権限の細分化 当初Snowflake内のデータや各種リソースのアクセス制御についてはGUIまたはコマンドで管理・編集していました。 Snowflakeで扱っているデータの種類や量が少なく、利用する事業部や人
はじめまして。デジタル庁ファクト＆データユニット所属、データエンジニアの長谷川です。 本記事ではデジタル庁内でデータ活用を推進するための組織と分析基盤についてご紹介します。 これまでのデジタル庁noteと比べると、技術寄りの話題が多い記事となりますが、庁内のデータ活用に興味のある方はぜひご覧ください。 デジタル庁のデータ活用組織「ファクト＆データユニット」ファクト＆データユニットとはデジタル庁の特徴の一つに、デジタル分野において各種の専門性をもつ「民間専門人材」が多く所属していることが挙げられます。 民間の専門人材は、デザイン、プロダクトマネジメント、エンジニアリングなど、領域ごとに「ユニット」と呼ばれる組織を構成しており（参考：デジタル庁 - 組織情報）、必要に応じてさまざまなプロジェクトにアサインされて業務を遂行する、人材プールのような役割を果たしています。 ファクト＆データユニットも
Saleshubでエンジニアをしております。 安田と申します。 今回はTerraCognitaというツールについて書いてみたいと思います。 AWSやGCPなどのクラウドサービスを利用されているエンジニアは多いと思います。 そしてこれらのサービスをWeb UI上で操作してアプリケーションのクラウド環境を構築している会社や個人も多いと思います。 Web UIで構築された環境。後で何やったかわからない その一方で今やクラウド環境はIaC(Infrastructure as code)で構築するのが当たり前でしょう！と言われたりします。実際、Web UIで構築された環境は、構築後時間が経つと「どうなってんだっけ、これ？」ってなったり、構築したメンバーが退職したりすると、引き継いだメンバーにとってトラップだらけのラビリンスになってしまったりします。 じゃあ、どうすればいいのか？ これに答えてくれてい
こんにちは DATUM STUDIOの梶谷です。 Snowflake では、Functional role と Access role を組み合わせたロール構成 が推奨されています。推奨されてはいるものの、組織やデータの規模が大きくなっていくと、クエリでロールをメンテナンスしていくのは、ちょっと大変ではないでしょうか。 そんな時こそ IaC ツールの出番！ということで、今回の記事では Terraform で Functional role と Access role を実装する例をご紹介したいと思います。 現実世界で人に与えられる役割や組織でのポジションに基づくロール（Functional Role）と、スキーマやテーブル等のオブジェクトに対する読み書き・使用可否に基づくロール（Access Role）をそれぞれ作成し、役割ごとに必要な権限を紐づけていくモデルです。 Functional
Terraform はそのままだと管理が大変 みなさん IaC (Infrastructure as Code) してますか？パブリッククラウドをIaCするなら、 Terraform が便利ですね！ しかし、本格的に使い始めると、こういう問題がすぐに出てきます。 複数環境の楽な分け方を知りたい ワークスペースはなんか嫌だ とはいえ、環境間で共通するボイラープレートをどうにかしたい 環境内で適用するモジュールを細分化・分岐したいけど面倒 環境ごとに使うモジュールを切り替えたい テスト環境はAuroraではなく安いRDSにしたい モジュール(tfstate)を分割して小さい範囲で適用したい 大きなモジュールは影響範囲がわからないし、差分計算にそれなりに時間がかかってしまう 分けたモジュールを一括適用するのが面倒 モジュール間の依存関係がわからない モジュール(tfstate)間での値参照が面倒
本書では、SaaS型のデータクラウド・データウェアハウスとして知られるSnowflakeの構成をInfrastructure as Code（IaC）のためのツールであるTerraformを使って簡単に管理する方法をご紹介します。 実サービスでも利用可能な実践的な構成を体系的に整理しながら、GitHub Actionsを使った安全なリソースの更新方法を取り扱います。 また、Golang-migrateを使ったテーブルの管理方法を紹介します。 【内容】 ・Terraform × Snowflake ・GitHub Actions ・Golang migrate ※執筆時点のバージョンでの紹介になるため、読者が記事の内容を再現する時にはソフトウェアが更新されている可能性がありますのでご注意ください⚠️
※本記事は2022年1月22日に公開された記事の翻訳版です。 この記事は、Developer Productivity Engineering Campブログシリーズの一環として、Platform Infraチームの Daisuke Fujita (@dtan4)がお届けします。 メルカリでは、すべてのクラウドインフラを宣言的構成で管理することがプラットフォームの中核となる考え方の一つです。メインのクラウドプロバイダーはGoogle Cloud Platform（GCP）であり、HashiCorp Terraformを使用してインフラをコードとして管理しています。Platform Infraチームは、すべてのTerraformワークフローを安全に管理するための社内CIサービスを提供しています。 Terraformはリソースプロビジョニングのためにクラウドプロバイダーのクレデンシャルを必要と
今回の記事では、AzureでIaCを実装する方法を解説します。 初心者の方に向けて、IaCとは何なのかから説明していきます。 IaCをすることによって、インフラ構築の工数を大幅に削減できます。理由は、自動化するからです。まずIaCが何なのかを説明します。 IaCとは？ まずは、IaCについての説明をします。Wikipediaでは次のように定義されております。 Infrastructure as Code（IaC） はコンピューティング・インフラ（プロセス、ベアメタルサーバー、仮想サーバーなど）の構成管理・機械処理可能な定義ファイルの設定・プロビジョニングを自動化するプロセスである。 (wikipediaより）つまり、インフラの設定をファイルに書いておいて、それを基に自動でインフラを作ることです。 AzureでIaCを実装するためにAzureでIaCを実装するためには、いくつかの方法がありま
2022/04/21_HashiCorp Virtual Strategy Day Japan Vol.2での、須藤の講演資料になります
ホーム カルチャー クラウドを扱うエンジニアにとって「Terraform」は必須ツール!? 〜エンジニアが語る技術愛 ＃05〜 ミクシィには、探究心溢れるエンジニアがたくさん在籍しています。 その探究心は業務で扱う技術にとどまらず、趣味で書いているプログラムだったり、個人的に研究している言語だったりと、自身の気になった技術への追求も留まることを知りません。 そこで、社内のエンジニアに“好きな技術”について、思う存分に語ってもらうシリーズを始めました。 ルールはこの通り。 ・業務で使っている技術でも、使われていない技術でもOK ・あくまでも個人的な見解で ・その技術のどこが面白いのか ・愛を込めて語り尽くしてもらう 第5回目は、みてね事業部 開発グループ SREチームの清水に「Terraform」について語ってもらいました。 清水 勲（しみず いさお）Vantageスタジオ みてね事業部 開
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
