AWSで Immutable Infrastructure

自己紹介

• cs_sonar

• インフラエンジニア

• 趣味 = 仕事

• AWS ソリューションアーキテクト アソシエイト とった！

• Twitter @cs_sonar

• Qiita cs_sonar

• Github cs-sonar

最近の流行ワード

• Immutable Infrastructure

• Vagrant / Docker

• Chef / Puppet

• Serf

• Fluentd

• Serverspec

• sensu

最近の流れが速すぎてついていけない・・・

今日はなす事

• Immutable Infrastructure のはなし

• Immutable Infrastructure を実現するためのツールのはなし

• AWSで実際に構築した環境の構成を紹介

今日はなす事

• Immutable Infrastructure のはなし

• Immutable Infrastructure を実現するためのツールのはなし

• AWSで実際に構築した環境の構成を紹介

Immutable Infrastructureとは

• いみゅーたぶる いんふらすとらくちゃ

• 不変のインフラ (直訳)

• 構築後は手を加えず不変のものとして扱う

• なにか変更が発生するたびに新しいサーバを作って古いのは破棄

• 仮想化技術の発展により出てきた

• 本質はいつでも破棄できるインフラ (Disposable Components)

Immutable Infrastructure で何がいいの？

• サーバーが再現可能なものとなる (インフラだけでなくアプリも)

• 本番環境におけるミスが少なくなる

• 横展開(スケールアウト)が容易

• 自動化しやすくなる

• デプロイがちょっと怖くなくなる

• →本番は触らない、という不自由な制約が結果的にいい方向に向かう

デプロイ deployment

今までのデプロイ

• 管理サーバーから変更済のソースコードを配信

更新結果、デプロイ実行後に・・・

＿人人人人人人＿ ＞ 突然の死 ＜ ￣Y^Y^Y^Y^Y￣ がおこる事が多い

サーバーの変更は1台1台、手作業で修正・・・

Immutable Infrastructure deployment

• Blue-Green Deployment

• Rolling Deployment

Blue-Green Deployment

Rolling Deployment

Stateless と Stateful

• Stateless

• 状態を持たないサーバ。なくなってもいい状態で運用する

• WEBサーバ Applicationサーバなど

• Stateful

• 状態を持つサーバ

• DBサーバ ファイルサーバ など

• → Immutableにはできない

今日はなす事

• Immutable Infrastructure のはなし

• Immutable Infrastructure を実現するためのツールのはなし

• AWSで実際に構築した環境の構成を紹介

そんな装備で大丈夫か？ 問題ない。

Immutable Infrastructureを実現するツール

Immutable Infrastructure を実現させるツール

• 環境

AWS

• bootstrapping

Vagrant

• Provisioning / configuration

Chef serverspec

• Orchestration

serf

AWS (環境)

• 仮想サーバー、ストレージ、データベース等を利用できるクラウドプラットフォーム

• 仮想サーバ(インスタンス)をコピーしたり、イメージ化したり、ロードバランサを設置したり、といった操作が簡単にできる

• 仮想なので、サーバーを増やしたり消したりといった事が非常にローコストで実現できる

• Immutable Infrastructureの考え方もAWSを中心としたクラウド技術を元に考えられた

Vagrant (bootstrapping)

• 仮想環境制御ツール (VirtualBox)

• 仮想サーバーを破棄/作成をプログラマブルにできる

• vagrant-awsプラグインを使うとAWS環境の制御も可能となる

• 起動時にchef-soloを実行したり、任意のコマンドを実行したり、プラグインを追加するとserverspecの実行もできる

Chef (Provisioning / Configuration)

• サーバーの設定管理/自動構築ツール

• サーバーの構築内容を記述した「recipe」通りにサーバーを構築してくれる

• Chefの基本概念として「冪等性」を保障する

• 現在のサーバーの構築内容をコードで管理できる

(infrastructure as code)

serverspec (Provisioning / Configuration)

• サーバの状態をテストするためのフレームワーク

• 対象のサーバーがあるべき状態であるかをチェックする

• 例えば・・・

対象のサーバにApacheはインストールされているか 対象のサーバの80ポートは空いているか 対象サーバのURLに接続して任意の文言が表示されているか など

Serf (Orchestration)

• ゴシップベースプロトコルによるクラスタリングとイベントプロパゲーションツール

• Serf自体がオーケストレーションを行うわけではなくオーケストレーションを実現する為に使う

※

ここでいうオーケストレーションとは、chef等での構築後に、サーバー監視ツールの監視対象としたり、ロードバランサ配下に入れたり・・・といった作業を指す

今日はなす事

• Immutable Infrastructure のはなし

• Immutable Infrastructure を実現するためのツールのはなし

• AWSで実際に構築した環境の構成を紹介

管理サーバーの役割

• Vagrant / Jenkins / Chef がインストールされている

(VagrantをAWS上に配置している)

• Vagrantは 「vagrant-aws」 「vagrant-serverspec」のプラグインを使用

• Jenkinsにてビルド実行を行うとvagrantを使ってサーバーを立ち上げ、chefを流し、serverspecでテストを行う

• 監視ツールとかもこのサーバーに入れている

• デプロイはCloudFormationとAuto-scaleを利用したRolling Deploy

config.vm.provider :aws do |aws, override|

aws.access_key_id = ‘xxxxxxxxxxxxxxxxxxxxxxxxx'

aws.secret_access_key = ‘xxxxxxxxxxxxxxxxxxxxxxxx'

aws.region = 'ap-northeast-1'

aws.instance_type = 't2.micro'

aws.ami = 'ami-xxxxxxxx'

aws.security_groups = ['default']

aws.keypair_name = ''

aws.ssh_host_attribute = :dns_name

override.ssh.username = 'root'

override.ssh.private_key_path = '/root/key.pem'

aws.tags = { 'Name' => ‘hogehoge' }

end

Vagrantfileの設定 (AWS)

# chef

config.vm.provision "chef_solo" do |chef|

chef.cookbooks_path = ["../../chef/cookbooks", "../../chef/site-cookbooks"]

chef.roles_path = "../../chef/roles"

chef.run_list = ["role[web]"]

end

# serverspec

config.vm.provision :serverspec do |spec|

spec.pattern = '../../spec/web/*_spec.rb'

end

Vagrantfileの設定 (Chef / serverspec)

cd /path/to/vagrantfile/

# サーバー立ち上げてchefを流し、serverspecでテスト

sudo vagrant up --provider=aws

# 立ち上げたサーバーにSSH接続していろいろする

sudo vagrant ssh --command "

(立ち上がったサーバで任意のコマンドを実行する。例えばgit pullしてプログラム配置するとか)

“

# CIの場合 立ち上げたサーバーを削除したり

sudo vagrant destroy

# AMIにする (※後述)

sudo /path/to/create_image.sh i-xxxxxx hogehoge-ami

Jenkinsのビルド(シェルで実行)の設定

#!/bin/bash -e

# usage: ./create-image.sh <instance-id> <ami-name>

export AWS_CONFIG_FILE=config

INSTANCEID=$1

AMI-NAME=$2

aws ec2 create-image --instance-id ${INSTANCEID} --name ${AMI-NAME}

立ち上げたサーバーをAMIにするスクリプト

• AWS コマンドラインインターフェイスを使用してコマンドで対象インスタンスをAMIにする

create_image.sh

ログ周りはfluentdで集約

• Fluentdで必要なログを管理サーバーに集約

• 集約したログはS3に投げたり、他のSaaSサービスに投げて監視したり

• Logentries や loggly とか

メトリクス監視 / 死活監視

• Serfで管理サーバに通知

• 通知を受け取った管理サーバはメトリクス監視/死活監視ツールの設定に該当ホストを加える。

• 該当ホストが削除されたらメトリクス監視/死活監視ツールの設定から該当ホストを外す。

• 外部SaaSサービスに投げてもいい感じ

New Relic とか Mackerel とか

AWSでのRolling Deployment

• CloudFormationでAuto-scalingを設定。

• Auto Scaling Groupのローリングデプロイ機能

• 更新時の最小グループサイズ、同時に更新するインスタンスの数、更新バッチの間の停止時間を制御しながら、ステップバイステップ方式でインスタンスを置き換えてくれる

• デプロイの実行はCloudFormationのスタックで対象AMIを指定してUpdate stackするだけ。

今日話せなかった各機能の詳細 • この構成を構築する為にはまったりした事とか詳細はQiitaで投稿してます

Jenkinsビルドの「シェルで実行」の失敗/成功を操作する http://qiita.com/cs_sonar/items/0190d68c3856b6fd6878 fluent-agent-liteとtd-agentで複数サーバーのログを集約 + chef http://qiita.com/cs_sonar/items/31bff9c14d479c94a47a fluentdで集めたログをlogentriesで監視 http://qiita.com/cs_sonar/items/3879dffec076c6a60f31 AWS cloudformationでAuto Scaling設定したらクラウド破産しかけた http://qiita.com/cs_sonar/items/a169539252b3b57ff71d vagrant-serverspec を使ってみたけどjenkinsでテスト失敗を取得できない http://qiita.com/cs_sonar/items/e2c65918a3d255dce217

以上です

• ありがとうございました