data "aws_ami" "ubuntu" { most_recent = true filter { name = "name" values = ["ubuntu/images/hvm-ssd/ubuntu-trusty-14.04-amd64-server-*"] } filter { name = "virtualization-type" values = ["hvm"] } owners = ["099720109477"] } resource "aws_security_group" "test-sg-for-all" { name = "test-sg-for-all" vpc_id = "vpc-xxxxxxxx" egress { from_port = 0 to_port = 0 protocol = "-1" cidr_blocks = ["0.0.0.0/0
レビュー自動承認化と精度100%を目指して。いち早く生成AIの導入に踏み出した「ユーザーレビュー基盤」の取り組み
条件 ・イミュータブルインフラストラクチャーの実現 ・ダウンタイム0でログロストもしないような安全なデプロイ ・最小のコストで最大限のパフォーマンスを出せるAutoScalingを活用する 準備 AutoscalingGroup作成して稼働させておく（参考：Auto Scaling の使用開始 ） AutoScaling-LifeCycleHookのSNSとIAMの設定をしておく（参考：【新機能】Auto Scalingのインスタンス起動/破棄時に初期処理/終了処理を追加 – LifeCycleHook機能のご紹介） デプロイの流れ instance_idを受け取りAMIを作成する 作成したAMIからLaunchConfigrationを作成する AutoScalingGroupの設定を変更する ELBに新しいバージョンのサーバをServiceInさせる。（古いバージョンのものと同数） 新
2017-06-17: この記事はもう古いです。Terraform v0.8.x 以下を対象としています。 2017/03 にリリースされた Terraform v0.9.0 で remote config 周りの仕様が大きく変わりました。 S3 に置くファイル形式は変わってないですが、特に CLI 周りで後方互換性のない変更が入っています。例えば terraform remote コマンドが無くなっています。 詳しくは以下の公式ドキュメントを読んで下さい。 Backends - Terraform by HashiCorp Backends: Migrating From 0.8.x and Earlier - Terraform by HashiCorp というわけで、以下の記事は Terraform v0.8.x 以下を対象としたものになります。 2015-05-08 にリリースされ
Ansibleのディレクトリ構成はベストプラクティスに準拠 やりたいこと a. Terraformで作成したEC2インスタンスに対して（登録したKey Pairで） ansible-playbook を実行したい b. mysql_dbモジュールを利用して、EC2インスタンス経由でRDSインスタンスにデータベースを作成したい Provisioner的な連続実行は諦めました 本当は、VagrantのProvisionerでAnsibleを実行するような流れるような実行をしたかったのですが、諦めました。 理由は以下です。 local-execがEC2インスタンスがSSH接続できるようになる前に実行されてしまう。タイムアウトでアウト。 RDSの接続情報も欲しい => terraform apply が完全に終わってから実行したい。。 というわけで戦いの記録です。 "a. Terraformで作成
TerraformでCoreOSクラスタを構築する CoreOSはDigitalOceanやAmazon EC2，OpenStackなどあらゆるクラウドサービスやプラットフォームで動かすことができる．1つのCoreOSクラスタを複数のクラウドサービスや自社のベアメタルサーバーにまたがって構築することもできるし，それが奨励されている．また，クラスタのマシンの数はサービスの成長や負荷状況によって増減させる必要もある． このようなCoreOSクラスタの構築を簡単に，かつInfrastructure as Code的に再現可能な形で行いたい場合，HashicorpのTerraformを使うのがよさそう（個人的に試しているだけなので数百規模のマシンではなく，数十規模の話．もし膨大なマシン数になったときにどうするのがよいのか知見があれば知りたい）． 以下では，Terraformを使ってDigitalO
About Terraformを使ってblue-greenぽいことをしている事例があったので、少しアレンジして試してみました。 参考にしたリポジトリ phinze/tf-bluegreen-asg-deployment: example of a blue/green deployment with asgs 作成したもの github.com お試し方法 事前準備 AWSのアクセスキーを発行しておく。 ec2の鍵を作っておく。 環境に合わせてterraform.tfvarsの設定を修正する。 direnvを導入して環境変数を設定する。 export AWS_ACCESS_KEY_ID="XXX" export AWS_SECRET_ACCESS_KEY="YYY" export AWS_DEFAULT_REGION="ap-northeast-1" 実行する ＜注意＞サンプル用のネットワ
$ terraform usage: terraform [--version] [--help] <command> [<args>] Available commands are: apply Builds or changes infrastructure destroy Destroy Terraform-managed infrastructure get Download and install modules for the configuration graph Create a visual graph of Terraform resources init Initializes Terraform configuration from a module output Read an output from a state file plan Generate and
charity.wtf charity wtf's about technology, databases, startups, engineering management, and whiskey. I’ve been using terraform regularly for 2-3 weeks now. I have terraformed in rage, I have terraformed in delight. I thought it might be helpful to share some of my notes and lessons learned. Why Terraform? Because I am fucking sick and tired of not having versioned infrastructure. Jesus christ,
Terraform + fluentd + Docker + Puree で小さく始めるモバイル行動ログ収集基盤構築 河合 航平 2015.07.07 1273 194192628259 こんにちは。 4月から新卒駆け出しインフラエンジニアとして日々奮闘しております河合です。 "モバイル行動ログ収集基盤" を "小さく" 始めたので、以下にインフラ構築からモバイルまでの設計までをまとめたいと思います。今回このログ収集基盤を作るにあたって私自身がこれまで経験したことのない技術・ツールを利用しましたので、それらの導入についてもご紹介いたします。 導入の背景 私は英単語サプリを中心にインフラを担当しています。 英単語サプリとは、聞ける・話せる・覚えてるをコンセプトとした高校受験からTOEICまで対策できる英単語学習のサービスです。 ユーザの分析によく使われるツールの1つにGoogle Analy
HashiCorp Advent Calendar 2015の5日目の担当が空いていたので書いてみました。 クラウドを利用されているみなさんは、リージョン障害などに備えるために複数のリージョンを利用されているかと思います。 複数のリージョンに展開する際、どのような方法で行ってますでしょうか？ CloudFormation Stackを複数のリージョンで作ったり、手動でポチポチやったり、SDKやAWSCLIを使ったスクリプトを使ったり… Terraform を使えば簡単に複数のリージョンを統一的に扱うことが出来ます。 Terraform は複数のプロバイダ(AWSやGCPなど)を一つのテンプレートの中に混在することが出来ます。 また、1種類のプロバイダを複数使用することも出来るため、AWSにマルチリージョンな環境を構築できます。 AWS謹製のCloudFormationは、S3やRoute5
このエントリは 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機能を使って、可能な限り入力項目を簡潔にすれば、インフラの知識がない人でも
This repository contains best-practice infrastructures across different cloud providers, regions, environments, and operating systems. You can think of this as a library of Packer templates and Terraform modules that allow you to provision unique infrastructures by referencing the different templates and modules. We've tried to set this repository up in a way that we don't have to duplicate code,
工夫したこと リソースの分離をファイル単位で行い、使い回しができるように配慮した 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-
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
