2022/04/21_HashiCorp Virtual Strategy Day Japan Vol.2での、須藤の講演資料になります
リクルートのAWS基盤におけるTerraform運用_実践的な取り組みと組織づくり / HashiCorpVirtualStrategyDay_sudo
2022/04/21_HashiCorp Virtual Strategy Day Japan Vol.2での、須藤の講演資料になります
Terraform import のススメ 〜開発効率化編〜 - LayerX エンジニアブログ
こんにちは、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に便利機能を提供するラッパーツールTerragruntの紹介 | DevelopersIO
はじめに こんにちは、中山です。 先日GitHubのトレンドを見ていたところ、面白そうなツールを発見しました。Terragruntというものです。これはTerraformのラッパーツールで、いろいろと便利な機能を提供してくれます。今回このツールを利用してみたのでエントリにまとめます。 Terragruntは何を解決するために作られたのか 作者の方のブログ(Add Automatic Remote State Locking and Configuration to Terraform with Terragrunt)や、GitHubのREADMEに詳しく書かれていますが、以下の2つの問題を解決するためのツールです。 リモートステートの有効化忘れ ロック機能 以下それぞれについて説明します。 リモートステートの有効化忘れ Terraformは拡張子に .tfstate が付くファイル(ステー
Terraformのログ出したい - Qiita
なんかドキュメントになくてどうやってんだろと思ってたら、ここにあった。環境変数設定したら出せるらしい。 $ cat terraform.log 2015/02/24 14:57:41 [INFO] Terraform version: 0.3.6 2015/02/24 14:57:41 Detected home directory from env var: /Users/akuwano 2015/02/24 14:57:41 [DEBUG] Discoverd plugin: atlas = /Users/akuwano/homebrew/bin/terraform-provider-atlas 2015/02/24 14:57:41 [DEBUG] Discoverd plugin: aws = /Users/akuwano/homebrew/bin/terraform-provid
Terraforming で既存のインフラを Terraform 管理下におく - Qiita
Terraform は、主にインフラをスクラッチから構築する際に有用なツールです。 ですが、いま動いている既存のインフラに Terraform を導入したい、既存のインフラを Terraform で管理したいと思う方もいるのではないでしょうか。 今回は、Terraforming を使って既存のインフラを Terraform で管理できるようにする方法を紹介します。 Terraforming とは Terraforming は、AWS の API を叩いて既存のインフラリソースから Terraform のコードを生成するツールです。 兄弟分に、DNSimple 用の Terraforming::DNSimple があります。 インストール RubyGems として公開されているので、
DMM inside
なぜDMMがweb3に参入したのか。Seamoon Protocolが目指す新たなエンタメ体験の未来とは
Terraformにおけるディレクトリ構造のベストプラクティス | DevelopersIO
はじめに こんにちは、中山です。 Terraformを使用していく中で、どのようなディレクトリ構造(tfファイルの配置方式)がベストなのかと考えたことはありませんか。私自身いろいろと試している最中なのですが、現時点で私が考えるベストプラクティスをご紹介します。 ディレクトリ構造 いきなりですが、以下のとおりです。 ├── Makefile ├── README.md ├── app.tf ├── bastion.tf ├── cloudfront.tf ├── db.tf ├── elasticache.tf ├── elb.tf ├── envs │ ├── dev │ │ ├── main.tf │ │ └── variables.tf │ ├── prd │ │ ├── main.tf │ │ └── variables.tf │ └──
TerraformのコードをCircleCI経由でデプロイさせる | DevelopersIO
はじめに こんにちは、中山です。 何番煎じか微妙なところではあるのですが、今回TerraformとCircleCIを連携させてみたので一本エントリを書きます。TerraformのコードをGitHubで管理しておき、プッシュしたらCircleCIでTerraform実行というパターンです。 構成図 今回のエントリには直接関係しないのですが、Terraformで作成されるシステムは以下の通りです。一般的なWebシステムによくある構成にしてみました。 コード GitHubに上げておきました。ご自由にお使いください。 knakayama/terraform-circleci-demo ディレクトリ構造 以下の通りです。 terraform-circleci-demo/ ├── Makefile ├── README.md ├── app.tf ├── bastion.tf ├── circle.y
Terraform管理の取捨選択は運用で状態が変わるかどうかで決めると良い - tehepero note(・ω<)
2016 - 06 - 07 Terraform管理の取捨選択は運用で状態が変わるかどうかで決めると良い 今のプロジェクトではTerraformを使って AWS 上のインフラを構築しているのですが、1年程運用して向いてるケース、そうではないケース等が明確になってきました。 今一度Terraformとは Terraform とは Hashicorp 社のプロダクトで、インフラを管理・構築・破棄をコードベースで行うことができ、まさにInfrastructure as Codeを地で行くような OSS プロダクトです。 AWS だけではなく、その他多くのIaaS/PaaS/ SaaS といったサービスの構成をコードで構築することが可能になります。最近はDockerの管理もサポートしていたり、 GitHub のチームや リポジトリ までもが管理できたりします。 全てが運用に即したものではない Te
チームによる継続運用を意識したAWS環境におけるTerraformの活用 - LIVESENSE ENGINEER BLOG
概要 背景 複数人数で一つの環境をコードで管理する場合の移行期と運用期の特性 移行期 運用期 Terraformの採用理由 実際の運用 ディレクトリ構成 stateファイルの配置 環境の定義 tfvarsによる切り替え 環境固有のリソース定義 GitHubのPRフロー よかったこと・課題 よかったこと 課題 概要 どうも。篠田です。 「特定の"インフラ担当"・"開発メンバー"」や「古の記憶」に頼らず、『開発メンバー全員が拡張や移行作業を気軽にできるインフラ』を実現するために、私のチームで採用しているTerraformを使ったAWS環境運用フローをご紹介いたします。 Terraformで移行および運用するフローにしたことで、構成全体に対する変更の柔軟性が高まり、コードがあることで運用および拡張期において設計の変更や手戻りを恐れずに開発を進められるようになりました。 次は概要図です。 背景 先
S3 + CloudFront + Aws Certificate Manager + Route53 + Middleman + terraformを使ってHTTPS対応した静的Webを100円/月で構築する - Qiita
variable "name" { default = "bucket-name.here" } resource "aws_cloudfront_origin_access_identity" "sample" { comment = "${var.name}" } resource "template_file" "sample_s3_policy" { template = "${file(concat(path.module, "/sample_s3_policy.json.tpl"))}" vars { bucket_name = "${var.name}" origin_access_identity = "${aws_cloudfront_origin_access_identity.sample.id}" } } resource "aws_s3_bucket" "samp
物理サーバを選定する際のポイント – Eureka Engineering – Medium
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
Terraform moduleあるある - tkak's tech blog
このエントリは HashiCorp Advent Calendar 2015 - Qiita 10日目の記事です。今回はTerraformのmodule機能に関する知見をご紹介します。 moduleとは？ module "consul" { source = "github.com/hashicorp/consul/terraform/aws" servers = 3 } moduleは、Terraform resourceを抽象化するためのものです。よく使うパラメータをmodule内に隠蔽して入力項目を減らしたり、複数のresourceをまとめたり、tfファイルの見通しを良くするために使います。 生のresourceを使ってTerraformの設定ファイルを書くのには、ある程度インフラの知識が必要です。module機能を使って、可能な限り入力項目を簡潔にすれば、インフラの知識がない人でも
Terraform: AWSマルチリージョンな環境を構築してみる | ただのメモ
HashiCorp Advent Calendar 2015の5日目の担当が空いていたので書いてみました。 クラウドを利用されているみなさんは、リージョン障害などに備えるために複数のリージョンを利用されているかと思います。 複数のリージョンに展開する際、どのような方法で行ってますでしょうか？ CloudFormation Stackを複数のリージョンで作ったり、手動でポチポチやったり、SDKやAWSCLIを使ったスクリプトを使ったり… Terraform を使えば簡単に複数のリージョンを統一的に扱うことが出来ます。 Terraform は複数のプロバイダ(AWSやGCPなど)を一つのテンプレートの中に混在することが出来ます。 また、1種類のプロバイダを複数使用することも出来るため、AWSにマルチリージョンな環境を構築できます。 AWS謹製のCloudFormationは、S3やRoute5
ヌーラボのインフラ運用最前線 2015 〜Terraform による AWS の構成の自動化〜 | 株式会社ヌーラボ(Nulab inc.)
工夫したこと リソースの分離をファイル単位で行い、使い回しができるように配慮した Backlogチーム以外でも利用できるようになるべくAWSリソース単位でファイルを分割しておき組み合わせるだけでリソースが構成できるように配慮しました。 ファイル構成例を記載していますがterraform applyを実行したときに全ファイル読み込んですべてのリソースを作成してくれます。 depends_on設定をしておくと各リソースの依存関係を制御できすべてのリソースをいっきに作成することが可能です。 . ├── config.tf ├── terraform.tfstate ├── terraform.tfstate.backup ├── user_data │ └── api.tpl ├── variables.tf ├── vpc-db-instance.tf ├── vpc-db-subnet-
Terraform + GitHub + CircleCI + Atlasを利用してAWSの操作を自動化した - Glide Note
TL;DR Terraform + GitHub + CircleCI + Atlas を用いてAWSの操作を自動化した 各ツールの役割は下記のような感じ Terraform => インフラへの変更ツール GitHub => .tfファイルのバージョン管理 CircleCI => CI、Terraformをawsに対して実行 Atlas => インフラの状態を記録するterraform.tfstateの管理 インフラの継続的デリバリー - naoyaのはてなダイアリーにて、言及されていた範囲(Route53の変更、Chefの適用)をAWSの操作全体に拡大した 背景 今までの問題点 AWSの各種操作がブラウザからポチポチ業… 手作業なので誤操作に気づきにくい。事故りやすい インフラの実構成がバージョン管理出来ていない ちなみにRoute53に関してはroadworkerを用いてコードで管理済
Terraform + fluentd + Docker + Puree で小さく始めるモバイル行動ログ収集基盤構築 | PSYENCE:MEDIA
Terraform + fluentd + Docker + Puree で小さく始めるモバイル行動ログ収集基盤構築 河合 航平 2015.07.07 1273 194192628259 こんにちは。 4月から新卒駆け出しインフラエンジニアとして日々奮闘しております河合です。 "モバイル行動ログ収集基盤" を "小さく" 始めたので、以下にインフラ構築からモバイルまでの設計までをまとめたいと思います。今回このログ収集基盤を作るにあたって私自身がこれまで経験したことのない技術・ツールを利用しましたので、それらの導入についてもご紹介いたします。 導入の背景 私は英単語サプリを中心にインフラを担当しています。 英単語サプリとは、聞ける・話せる・覚えてるをコンセプトとした高校受験からTOEICまで対策できる英単語学習のサービスです。 ユーザの分析によく使われるツールの1つにGoogle Analy
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「それ、どこに出しても恥ずかしくないTerraformコードになってるか？」 / Terraform AWS Best Practices
terraform-community-modules