どうもどうも乙カレー様です。桑野です。 びっくりするほどブログ書いてなくてびっくりしてます。半年書いてないやん。 Terraformを使っていたりするんですが、最近EC2のAutoScaleを入れようとして辛いことがあったりしたのでちょっとまとめてみます。 Terraform Terraformは言わずとも知れたHashicorpさんのプロダクトですね。 インフラ構築をコード化してGithub等でレポジトリ管理することによって履歴管理や、プルリクエストベースの構築ができるのが売りだったりします。 TerraformでのAutoScale時のハマりどこ 端的にいうとこの2つです。 Terraform経由で実行した際のLaunchConfiguration（イカLC）とAutoScalingGroup（イカASG）の削除の順番が逆 LC内のuser_data更新で一網打尽になる Terrafo
HashiCorp 並びに HashiCorp Products である Atlas, Vagrant, Packer, Serf, Consul, Terraform, Vault, Nomad, Otto 等に関する Advent Calendar です。
このエントリは 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機能を使って、可能な限り入力項目を簡潔にすれば、インフラの知識がない人でも
前回の記事ではDockerとECSを使ったAWS上でのInfrastructure as codeについて言及しましたが、サーバリソースの構成管理についてはAWSのマネージメントコンソールから手動で行わないといけなかったり、コンテナを用いたアプリケーション構成を強制され、従来の単純なインスタンス構成ができないという問題点がありました。前回の記事はこちら。 後者については、今後コンテナを活用したインフラ構成が普通になっていくことで許容されていくかもしれませんが、普通にインスタンスを立ててインフラを構築している方にとってはInfrastructure as codeをやりたいためにコンテナを前提としたサーバ構成に変更しなくてはいけないなんて、正直気が進まないと思います。 そこで本記事では、今インフラ界隈で非常に強い影響力を持っているHashicorpのプロダクト、PackerとTerrafor
AWS Partner Network (APN) Blog AWS CodeDeploy Deployments with HashiCorp Consul The following is a guest post from Cameron Stokes, Solutions Engineer at AWS DevOps Competency Partner HashiCorp. AWS CodeDeploy automates code deployments to Amazon Elastic Compute Cloud (Amazon EC2) and on-premises instances, allowing developers to customize deployment steps as needed per their application requiremen
Serfの足りない機能を補うConsul 前回の記事の復習になりますが、Serf（https://serfdom.io）の主要な役割は、オーケストレーション（自動的に複数のサーバなどのインフラ上で処理すること）と、クラスタ上のメンバ管理です。 Serfを単純なツールとして見た場合は、オーケストレーションを簡単に行える便利なツールと言えるでしょう。しかし、実際の運用シーンを考えますと、次のような弱点が浮かび上がります。 メンバ管理はSerfエージェント間の通信正常性が基準であり、アプリケーションやミドルウェアの状況に応じた自動処理が行えない（サーバは稼働しているが、ウェブサーバやデータベースが停止するような状況） 何らかの状態を保持する仕組みがないので、冗長化の仕組みは自分で考慮する必要がある Serfクラスタとの通信には独自のCLIかAPIを使う必要があり、他のツールとの親和性が低い これ
はじめに こんにちは、中山です。 最近業務の中でAWS CodeDeployを使っています。AWS上でアプリケーションのデプロイを自動化する上でとても便利なサービスです。 私は完全に習うより慣れろ派の頭なので実際に手を動かさないとなかなか新しいサービスを覚えられません。という訳で、今回はCodeDeployを使ったイミュータブルなBlue/Greenデプロイメントの検証環境をTerraformで構築してみました。 構成図 構成図は以下の通りです。 構成図の解説 2つのASG(Blue/Green)を作成 そのうち1つのASGをELBに紐付ける(最初はBlue) アプリケーションのリリース時にCodeDeploy経由でGreenへデプロイ ELBの紐付け先AutoScaling GroupをGreenに付け替える アプリケーションのリリース毎にASGを作成してデプロイ、その後ELBの振り分け
お久しぶりです。tjinjinです(╹◡╹) 最近じめじめしていますね。梅雨あけると夏ですよ！！夏アニメが始まりますよ！！ ということで、PV見た感じの私のおすすめは六花の勇者です！”りっか”ではなく”ろっか”です！ AWS環境のコード化 弊社ではAWS環境の構築を管理コンソールでの温かみのある作業やRakeTaskで行ってきましたが、サービスを新規で立てるのに時間がかかるという課題があり、AWS環境もコード化したいという思いがありました。インフラチーム内で検討した結果、 名前がかっこいい コードが読みやすいということで一部サービスでterraformを採用し始めています。 terraformを使って行く中で、何点か壁にぶち当たったので情報共有できればと思います。 terraformとは？ 一言で表すとインフラ構成をコード化することのできるツールというところでしょうか。みんな大好きHash
「Vagrant」って何ぞ？（・o・）：Vagrant開発者 Mitchell Hashimoto氏に聞いた 仮想の開発環境作成ツールとして人気が高まっている「Vagrant（ベイグラント）」。その開発者であるMitchell Hashimoto（ミッチェル ハシモト）氏が来日するとの情報を聞き、2013年7月12日、VOYAGE GROUPで行われたミートアップに駆け付けた。 「Vagrant」とは Vagrantとは、違う環境に移行可能な開発環境を簡単に構築・管理し、配布することができる開発環境作成ツール。「ほんの数行書くだけで開発用の仮想マシンを構築できる」という優れものだ。 Vagrantのビジョンは、「開発者とシステム管理者にとって最高の『開発フロー』を提供すること」。Vagrantをダウンロードして「vagrant up」と入力し、実行するだけでそれが可能となる。 システム管理
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く