CloudNative Srcurity Conference 2022、アクセンチュアのエンジニアが解説するTerraformにおけるクレデンシャル管理の現実解を解説したセッションを紹介する。 CloudNative Security Conference 2022から、アクセンチュアのエンジニアが解説するインフラストラクチャー構築のためのツール、Terraformにおけるクレデンシャル管理に特化したセッションを紹介する。セッションを担当したのはアクセンチュアの崎原晴香氏だ。2021年に新卒でアクセンチュアに入社したというエンジニアでクラウド環境、特にAWSをメインにクラウドインフラストラクチャー構築に携わっているという。 「機密情報をコードに含めず環境構築するにはどうしたらいいの?」というサブタイトルが示すように、サーバーやデータベースのインスタンスをクラウド上に構築する際にどうしても
こんにちは、コンテナソリューショングループの髙井です。 今日はWSL2(Ubuntu 20.04)へのTerraformのインストールとアップグレードの方法について紹介します。 WSL2へのTerraformインストール やり方としてhomebrewを使う方法と、バイナリを直接ダウンロードしてくる方法に分かれます。 Macを使っている方であればhomebrewがなじみ深いとは思います。 なんと実はhomebrewはLinuxもサポートしています。aptと違ってsudoも必要ありません。 (今回は、homebrew自体のインストール方法は公式ページに譲ります。) さらに、Terraform用のパッケージマネージャーであるtfenvを利用する場合とそうでない場合にも分かれます。 個人的にはTerraformはアップデートが早いので、tfenvを利用する方法がおすすめです。 tfenvを利用しな
概要 自分の所属企業であるAqua SecurityがTFsecというOSSを買収しました。 blog.aquasec.com TFsecはどういうツールかというとTerraformの静的解析スキャナーです。Terraformの設定ファイルを渡すことでセキュリティに関する設定ミスを主に検知してくれます。 github.com そのアナウンスに伴い、TFsecは自分が開発している脆弱性スキャナーであるTrivyに統合されました。TrivyではTerraformに加えDockerfileやKubernetesなど、いわゆるInfrastructure as Code(IaC)の設定ミスを検知するマネージドポリシーも提供しています。他にもJSONやYAMLなど一般的なファイルフォーマットに対応しているため自分でポリシーを書くことでそれらの検知にも使えます。CloudFormationやAnsib
ベストプラクティスといいつつ、どういう風にやりたいかで変わるというのは往々にしてあります。 ベストプラクティスは求めても意味ないのでどうでもいいとして、いろんなパターンのメリット/デメリットを把握して現状に即しているのかどうかは考え続ける必要があります。 ということで、長年頭を悩ませて納得感があまりない代表が Terraform です。 今回は以下の記事を読んでて、普段やっている Terraform の構成について書いてなかったので記録として残しておきます。 blog.serverworks.co.jp TL;DR; HashiCorp社の Terraform ベストプラクティス Nebulaworks の例 なぜ Terraform の構成は難しいのか よく使っている構成 原則 terraform ファイルの記載内容 この構成で最も設計しないといけないこと 元記事の迷子 workspac
こんにちは、チェシャ猫です。 先日開催された DevOpsDays Tokyo 2021 で Infrastructure as Code のテストについて発表してきました。公募 CFP 枠です。 今回の発表は、昨年の CloudOperatorDays Tokyo 2020 での講演をほぼそのまま再現しています。内容については前回登壇時に詳細な解説記事を書いたので、こちらもご参照ください。 ccvanishing.hateblo.jp オンサイト登壇 ここしばらく、どのカンファレンスもリモート開催がデフォルトになっていましたが、今回は久しぶりに会場まで行って登壇してきました。最後にオンサイトでプレゼンしたのが 2020 年の 3 月 26 日 なので、実に 1 年ぶりです。 実際には会場で参加していたのはほぼ関係者オンリーで、各ホールに数人ずつといった程度の人数でした。ただ登壇する側とし
Ansible、Terraform、Packerで作るSelf-Hosted Kubernetes / JKD1812
I’ve been working at the internal platform team at Mercari for 3 years. In that team, we’ve developed and provided the special Terraform module, which bootstraps required infrastructure and SaaS services for building one microservice, to internal developers (See more details on Terraform Ops for Microservices). Now, this module is used by more than 400 services (since we create both development an
※この投稿は米国時間 2020 年 10 月 13 日に、Google Cloud blog に投稿されたものの抄訳です。 Google は去年、ベスト プラクティスに従って強固なクラウド基盤を迅速に構築するため役立つオープンソースのテンプレートとして、Cloud Foundation Toolkit をリリースしました。これらのモジュールは Terraform infrastructure-as-code フレームワークと、Google の Cloud Deployment Manager の両方で利用できます。 本ブログ投稿では、Cloud Foundation Toolkit Terraform のサンプル基盤 を使用して、安全なクラウド基盤を構築する方法について詳しく解説します。その次に、Terraform を使用してマイクロサービスのデモアプリケーションを基盤上にデプロイする方法
This stage executes the CFT Bootstrap module which bootstraps an existing Google Cloud organization, creating all the required Google Cloud resources and permissions to start using the Cloud Foundation Toolkit (CFT). For CI/CD Pipelines, you can use either Cloud Build (by default) or Jenkins. If you want to use Jenkins instead of Cloud Build, see README-Jenkins on how to use the Jenkins sub-module
少し前にこちらの記事でgmailfiltersというツールを知りました。 kakakakakku.hatenablog.com github.com gmailfiltersはとても良さそうなのですが、なんでもTerraformおじさん的にはTOMLよりHCLで設定を書きたいなと思ったので この土日でTerraformプロバイダーを実装してみました。 github.com Gmailのフィルタ/ラベルを設定するTerraformプロバイダー terraform-provider-gmailfilter Gmail APIでフィルタやラベルの登録/更新/削除が行えます。 例えばfoobar@example.comから来たメールをexampleラベルに振り分けるには以下のようなHCLコードとなります。 # ラベル"INBOX"を参照するためのデータソース data gmailfilter_la
envssm Docker/docker-compose で.env を使っていると本番環境のシークレットの管理がめんどうですよね。 シークレットは AWS のパラメータストアに登録して、ECS など環境変数として利用するのが一般的のようですが、一つ一つコンソールに打ち込むのは骨が折れます。 なので.env ファイルからパラメータストアの Terraform ファイルを生成するツールを作りました。 対象読者 Terraform の基本がわかっている方 docker-compose などで.env を使っている方 Terraform や Docker の使い方には触れませんのでご了承ください。 インストール
前書き Terraformの機能の中でもmoduleはworkspace(旧environment)と並んで評価が分かれる1つだと思います。 僕自身も複数の人からmoduleに否定的な意見を聞いたことがあり、実際にmoduleを使い始めた頃はあまり便利だとは感じませんでした。 しかし、公式サイトのmoduleのページ12を読んでいくうちに間違ったmoduleの使い方をしてしまっているケースが多いこと、そういったアンチパターンを実行した/目にした結果moduleが使えない・実用的ではないといった誤解を招いているケースが数多くあることに気づきました。そういったアンチパターンにならないよう気を配り数ヶ月moduleを使ってみると、moduleはとても便利で汎用性の高い機能であることに気づきます。 このモジュール機能の有用性をもっと世のterraformerに知ってほしいと思ったため、このページで
こちらは【Terraform】moduleのアンチパターンとそれに対するベストプラクティス5選 - Qiitaとは違い、特に公式サイト書かれていたわけではないけども僕が数ヶ月Terraformを使って学んだ個人的なベストプラクティス集です。 リソースへ名前をつけがたいときはthisを使う あるリソースを宣言するとき、そのリソースがモジュール内で1つしかない場合は名前の付け方に苦労します。 リソースタイプと似たような名前をつける場合、以下のように以外と選択肢がたくさんあり面倒です。 aws_ssm_parameter リソースタイプの場合 parameter ssm_parameter aws_ssm_parameter ssmparameter ssm-parameter ... またアプリケーション名などその用途で表す方法もあります。 しかし、この書き方ですとこの部分を他のアプリケーショ
こんにちわ。rwle1212です。 本記事は JAWS Days 2020 で話す予定でしたが、昨今の事情によりオンライン開催となったため、登壇予定の内容を記事にしたものになります。 登壇していれば諸般の事情により左手首を骨折したネタが使えたのですが、ブログでは伝わらないので非常に残念な思いをしております。という話はどうでも良いので本題に入ります。 50分の登壇内容なので少々長くなりますが、お付き合いください。 JAWS Days 2019で登壇した内容の振り返り昨年の JAWS Days 2019 で「Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理する」という内容で登壇しました。 まずは上のリンクに添付されているスライドを5分位で読めると思うので一読頂いて、下の文に進んで頂ければと思います。 そもそもInfrastructure as Cod
ABEJA Advent Calendar 2019 の4日目です。 こんにちわ。 最近 @rwle1212 で呟き始めました。Twitterの良い使い方がわからん。 本記事のキッカケ 過去のお話 さて、過去にこんな投稿しました。 193いいねが付いているので割と好評だったのかもしれません。しかし、 その1年半後に次のような話を JAWS Days 2019 で話しました。 それらを要約するとすると以下になります。 2017年11月: Terraform のベストプラクティスな使い方考えたよ! 2019年2月 : ごめん。疲れたわ と、疲れて終わっていたので 0.12 になり再入信 色々反省し、Terraform も 0.12 になり大きく変わったこともあり、黒魔術にしないように心がけた設計を共有します。たぶん楽になってるはず。たぶん 本題: Terraform 0.12 で心がけているこ
こんにちは、筋肉系インフラエンジニア見習いのつるべーです。 私は今、GMOペパボ株式会社でペパボカレッジという第二新卒エンジニア向け研修を受けている真っ最中です! 今回のエントリーは、私が研修中に感じた素朴な疑問を会社のコミュニケーションツールに書いたら、そこから議論が広まって、最終的にはInfrastructure as Codeという重要な概念への理解を深めることができたよ、という話です。 Infrastructure as Codeって? Infrastructure as Codeを一言で表すと「コードによりインフラの管理をすること」です。 コードで管理することのメリットとしては、 コードのバージョン管理ができる 設定変更の適用前にプルリクエストベースで確認が行える 設定の共有・再利用が容易である オペレーションミスが防げる インフラ構築の属人化が防げる などが挙げられます。 現在
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く