Fewer MistakesCatch errors in Terraform plan output before applying changes. Ensure changes are applied before merging.
背景 Terraform で Route 53 で alias を使う際に必ず欲しい情報のはず。 課題 「zone_id 何設定するんだっけ?」の答えを知りたい。 そんな時のブックマークです。 解決 Amazon API Gateway AWS AppSync 調査中... Amazon CloudFront AWS Elastic Beanstalk Elastic Load Balancing(Application, Classic, Network) Global Accelerator 調査中... Amazon Simple Storage Service Amazon Virtual Private Cloud 調査中... 一言 一部調査中ですみません。 何も考えずに当該ドメインのホストゾーンID設定するとコケますよ。 20年以上のビジネス歴を持つインフラの専門家。セキュリ
こんにちわ。rwle1212です。 本記事は JAWS Days 2020 で話す予定でしたが、昨今の事情によりオンライン開催となったため、登壇予定の内容を記事にしたものになります。 登壇していれば諸般の事情により左手首を骨折したネタが使えたのですが、ブログでは伝わらないので非常に残念な思いをしております。という話はどうでも良いので本題に入ります。 50分の登壇内容なので少々長くなりますが、お付き合いください。 JAWS Days 2019で登壇した内容の振り返り昨年の JAWS Days 2019 で「Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理する」という内容で登壇しました。 まずは上のリンクに添付されているスライドを5分位で読めると思うので一読頂いて、下の文に進んで頂ければと思います。 そもそもInfrastructure as Cod
ChatGPT関連情報の追い方、個人・業務での使い方、サービスへの組み込み方、 ABEJAでの取り組み4例、ここ2週間のトピックなど行けるところまで
[toc] Terraformでオートスケール設定をしています。設定の記述が簡単なのが良いですね。 パッケージやOSのアップデートなどにBlue-Green Deploymentにしたいなと考えていまして、 BlueとGreenのオートスケーリンググループ(ASG)の台数を設定ファイルに外だし(variables.tfvarsなど)にしたいと考えていました。 ASGの台数はデプロイ状況によって可変であるため、スクリプトで設定ファイルを変更しようと考えていました。 しかし、Terraformの設定ファイルはHCL(HashiCorp Configuration Language)というJSON互換でありながらも形式が全く異なるため、パースをどうするかを考えていました。 Terraform及び周辺ツールのソースやドキュメントを漁りながら調べた結果、Go言語で書かれているHashicorp製のH
入門三部作ラスト www.mpon.me www.mpon.me ここまでで、簡単にTerraformの機能をおおざっぱに説明してきました。 今回は、そこそこ現実に即したインフラを作るまでの流れを追いながら、徐々にリファクタリングしていくことで実践的な考え方を身につけていきましょう。 すごく簡略化した一般的なAWSの構成を題材にします 本番に完全に即してる訳ではないけども簡略化した構成を例として、terraformでの構築、リファクタリングの過程をやっていきます。 ディレクトリ構成などに焦点を当てていきたいので、セキュリティグループなど細かいことは省いています。また、あくまでも例なのでそのまま動くコードにはなっていません。 下図のような構成です。 ロードバランサーにEC2インスタンスがそれぞれ2つずつぶらさがってるような構成。各インスタンスにはnginxとRailsアプリケーションがいるよ
全国のTerrafrom愛好家の皆様こんにちは。 技術4課の岩本です。 Terraformのプロビジョナーには非常に残念ながらAnsibleがありません。 通常であればTerraformで環境を構築後に、別途Ansible用のInventoryファイルを作成してという流れになりますが、 Inventoryファイルの作成なしにTerraform Inventoryを使って、TerraformとAnsibleを2コマンドで連携させてみました。 Terraform Inventory とは? AnsibleのDynamicInventoryをTerrafromのStateファイルから生成するプログラムです。 Terraform Inventory また、AWS以外にも DigitalOcean CloudStack VMware OpenStack Google Compute Engine S
続きをかきました→ https://qiita.com/uraura/items/e13d883827443f27bf98 概要 TerraformでAWSのリソース管理をしていますが,(少人数でやるには1)まぁまぁ良い感じに落ちついたのでご紹介します. 以下,話を簡単にするためにTerraformでAWSのリソースを管理しているという前提で話をすすめます. 問題 Terraformは便利で,使いはじめると何でもかんでもコード化してやろう!!などと思ってしまいますが,すぐに以下のような問題にぶち当たります. コード化をすすめるとplan/applyにかかる時間が増大していく planが通ってもapplyでコケる場合がままある コード化をすすめるとplan/applyにかかる時間が増大していく コード化されてるリソースが少ないうちはあまり問題にならないのですが,時がたちコード量が増えてくると
先日 Terraform 0.7 がリリースされました。 Terraform 0.7 の目玉機能は、なんと言っても既存リソースの import terraform import ではないでしょうか。全世界の Terraform ユーザが長年待ちわびていた機能がついに搭載されたことになります。 あ、あと terraform.tfstate のバージョンが 1 から 3 に上がったので後方互換性が地味に失われているのも大きいですね… さて、自分は1年以上前から既存リソースをコード化する手段として Terraforming を開発し今に至るまでメンテナンスしてきました。 github.com 現在ではそれなりの認知をいただき、リソース追加などで Pull Request も多くもらうようになりました。 そんなことをしていたので、既存リソース import の公式対応には注目している、むしろしなけ
TL;DR Terraform + GitHub + CircleCI + Atlas を用いてAWSの操作を自動化した 各ツールの役割は下記のような感じ Terraform => インフラへの変更ツール GitHub => .tfファイルのバージョン管理 CircleCI => CI、Terraformをawsに対して実行 Atlas => インフラの状態を記録するterraform.tfstateの管理 インフラの継続的デリバリー - naoyaのはてなダイアリーにて、言及されていた範囲(Route53の変更、Chefの適用)をAWSの操作全体に拡大した 背景 今までの問題点 AWSの各種操作がブラウザからポチポチ業… 手作業なので誤操作に気づきにくい。事故りやすい インフラの実構成がバージョン管理出来ていない ちなみにRoute53に関してはroadworkerを用いてコードで管理済
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く