ChefでのMySQLパスワードの扱い

opscodeのリポジトリにあるMySQLのcookbookでは、rootユーザやレプリケーション用のユーザのパスワードをランダムに生成して設定している。

opscode の recipe の特徴

このランダムという点をカバーするべく、うまい仕組みが組み込まれている。

パスワードを設定するところは

node.set_unless['mysql']['server_root_password'] = secure_password

といった形で、attributeに設定されていない場合はランダムに生成するという事をして、2度目以降も同じパスワードとなるようになっている。

2回目以降も同じパスワードを保証するために、もうひとつの技が

unless Chef::Config[:solo]
  ruby_block "save node data" do
    block do
      node.save
    end
    action :create
  end
end

ここの node.save というやつ。
普通であれば、recipe(run_list)の実行がすべて完了するまではattributeがサーバに保存されないんだけど、このメソッドを使うことで、即時に保存される。これで、万が一rootのパスワードが設定されたあとのどこかでコケても、同じパスワードで設定を続けることができる(上のコードにあるようにchef-soloのときは実行されないけど)。また、masterは途中でコケたけど、スレーブはそこで設定された(であろう)であろうパスワードを使ってセットアップだけは続けることができる。

これはよく考えられた仕組みですよね。

Encrypted Data Bag

ただ、ランダムであれば推測されづらくていいかもしれないけど、好きなパスワードを設定したいし、アプリからのアクセスを考えるとすべてのサーバでアプリ用ユーザは共通にしておきたいといった要望もある。また、提供されているrecipeのままだったりattributeにそのまま設定してしまうと、平文のパスワードがattributeの一覧から確認できてしまう。

そんな時に便利なのが、Encrypted Data Bagという平文で保存したくないデータをChefに保持しておくための機構。Encrypted Data Bag を使うために必要なのはencrepted_data_bag_secretと呼ばれる共通鍵だけ。
※やってることはOpscodeのサイトに書かれていることと全く同じです。

共通鍵の作成

# openssl rand -base64 512 | tr -d '\r\n' > /etc/chef/encrypted_data_bag_secret

これをEncrypted Data Bags利用する各クライアントと共有する。共有方法は初回セットアップであれば、knifeコマンドのbootstrapで指定してあげれば良い。その方法は後ほど。

knifeコマンドで暗号化されたデータをdata bagsに保存

passwordというdata bagにmysqlという項目を作成します。ここで指定するmysqlというのは、data bagのIDとなり、これは暗号化されません。

# knife data bag create --secret-file /etc/chef/encrypted_data_bag_secret passwords mysql
[editorが開くので以下のように入力して保存]
{
  "id": "mysql",
  "user": "root",
  "pass": "your_password"
}

※EDITOR環境変数を設定していないとErrorになります。

作成したdata bagを確認してみましょう。

# knife data bag show passwords mysql
{
  "id": "mysql",
  "pass": "trywgFA6R70NO28PNhMpGhEvKBZuxouemnbnAUQsUyo=\n",
  "user": "e/p+8WJYVHY9fHcEgAAReg==\n"
}

userとpassが暗号化されて保存されています。
では、復号化して表示してみます。

# knife data bag show --secret-file /etc/chef/encrypted_data_bag_secret passwords mysql
{
  "id": "mysql",
  "user": "root",
  "pass": "your_password"
}

先程入力したものが表示されました。

Recipeから Encrypted Data Bagのデータを呼び出す

実際に recipe からdata bagの値を呼ぶには、以下のような感じにしてあげます。

共通鍵を直接指定する場合

mysql_data = Chef::EncryptedDataBagItem.load("passwords", "mysql", secret)
user = mysql_data["user"]
password =mysql_data["pass"]

共通鍵ファイルがデフォルトの /etc/chef/encrypted_data_bag_secret に配置されている場合はsecretを指定しなくてもOK

mysql_data = Chef::EncryptedDataBagItem.load("passwords", "mysql")
user = mysql_data["user"]
password =mysql_data["pass"]

ここで、ユーザ名やパスワードを node['mysql']['user'] とやってしまうと、せっかく暗号化して保存されているユーザ名とパスワードが平文でattributeに登録されてしまいますので、やめたほうがいいと思います。data bagに保存されているので、次回以降に変わるという事も無いですしね。

recipe内で定義したローカル変数のままだとテンプレートに渡せないので、templateリソースの中で以下のように定義すればテンプレート内で呼び出せる。

template "hoge" do
  source "hoge.erb"
  ...
  variables(
    :user => user,
    :pass => pass
  )
end

これでめでたくattributeに平文のパスワードが登録されることなく、自分の好みのパスワードが設定出来ました。

bootstrap で encrypted_data_bag_secret を渡す

初回セットアップのサーバの場合には、validation.pemやchef_server_urlを新規クライアントに設定するために bootstrap の仕組みを利用する。この中で、encrypted data bagの共通鍵をセットアップするサーバに配置することができる。

以下のようにbootstrapファイルに書く。

(
cat <<'EOP'
<%= encrypted_data_bag_secret %>
EOP
) > /etc/chef/encrypted_data_bag_secret

encrypted_data_bag_secret など、bootstrap で使用される値などは、knifeを実行するノードのknife.rbに設定されているものが利用される。そのため、encrypted_data_bag_secretファイルの場所もknife.rbに指定しておく必要がある。

encrypted_data_bag_secret "/etc/chef/encrypted_data_bag_secret"

これで、knifeコマンドからbootstrapファイルをして初期実行をすれば、recipeを実行するクライアントでも問題なくdata bagを復号化できる。

(追記:2012-02-12 16:25) recipe内のローカル変数をテンプレートで使うための記述を追記。

knife ec2でインスタンスの初期設定(RVM+Ruby1.9.2編)

前回はnodeのchef-clientを動かすためにrbelリポジトリのRubyを使っていた。特にこだわりがなかったり、動かすシステムでRubyを使うわけじゃなければ、RPMだと楽でいいですよね。
ただ、セットアップするnodeでRubyを使いたい、RVMで複数バージョンのRubyを使いたいなんてことがある場合もあると思う。
であれば、bootstrapでインストールするRubyもRVMでインストールしちゃえばいいじゃない。

という訳で、基本的には前回と同じで、bootstrapの中身を変えればOK。セットアップ対象はCentOS6で、Ruby1.9.2をインストールしてデフォルトRubyにします。

$CHEF_REPO/.chef/bootstrap/centos6-rvm.erb を以下のように作成。

bash -c '
<%= "export http_proxy=\"#{knife_config[:bootstrap_proxy]}\"" if knife_config[:bootstrap_proxy] -%>

yum install -y gcc bison autoconf patch git curl readline-devel libxml2-devel libxslt-devel wget man

if [ ! -f /usr/local/rvm/bin/rvm ]; then
  bash -s stable < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer )
  source /etc/profile.d/rvm.sh
  rvm install 1.9.2
  rvm use 1.9.2 --default
fi

gem install ohai --no-ri --no-rdoc
gem install chef --no-ri --no-rdoc
ln -nfs $(which chef-client) /usr/bin/chef-client

mkdir -p /etc/chef

(
cat <<'EOP'
<%= validation_key %>
EOP
) > /tmp/validation.pem
awk NF /tmp/validation.pem > /etc/chef/validation.pem
rm /tmp/validation.pem

(
cat <<'EOP'
<%= config_content %>
EOP
) > /etc/chef/client.rb

(
cat <<'EOP'
<%= { "run_list" => @run_list }.to_json %>
EOP
) > /etc/chef/first-boot.json

<%= start_chef %>'

上記bootstrapテンプレートが出来上がったら、前回使用したknife ec2コマンドの -d オプションでの指定を今回作ったものに変えてあげる。

$ knife ec2 server create -G security_roup -I ami-12345678 -f t1.micro -S key-pair-name -i ~/.ssh/private-key.pem -x ec2-login-user -d centos6-rvm -r 'rolw[rails_server]' --region ap-northeast-1 -Z ap-northeast-1a

しばらく待てば、はい完成。(microだとちょっと時間がかかります。)

ChefでEC2インスタンスの起動から初期設定までを行う

前回はChefのサーバとクライアントをインストールして、簡単なチュートリアルを試してみました。今回はより実践的な内容をやってみようと思います。

やること

chefとknifeを用いて、EC2インスタンスの起動と(ごく簡単な)設定を行う。

構成

• chef-server: CentOS6 on EC2 (t1.micro)
• 設定対象ノード: CentOS6 on EC2 (t1.micro)
  • knife-ec2を用いて起動〜設定までを行う対象 (chef-client)
• workstation: CentOS6 on EC2 (t1.micro)
  • knifeコマンドを実行する端末(chef-client)

CentOS6はsuz-labさんが提供している ami-46902747 をベースに、カーネル以外のパッケージを最新にして AMI 化しておいたものを用いる。

事前準備

chef-server

手順は簡単。たったこれだけ。epelのリポジトリは最初から使えるようになっているので、無問題。

# yum install couchdb erlang rabbitmq-server libxml2-devel zlib-devel.x86_64 --enablrepo=epel
# rpm -Uvh http://rbel.frameos.org/rbel6
# yum install ruby ruby-devel ruby-ri ruby-rdoc ruby-shadow gcc gcc-c++ automake autoconf make curl dmidecode --enablerepo=rbel6
# yum install rubygem-chef-server --enablerepo=rbel6
# setup-chef-server.sh

workstation (chef-client)

インストール〜初期設定

knifeコマンドを実行したり、cookbookなどの編集を行うためのchef-client。こちらも簡単。
libxml2-develとlibxslt-develはknife-ec2をインストールするために必要となる。

# rpm -Uvh http://rbel.frameos.org/rbel6
# yum install rubygem-chef --enablerepo=epel,rbel6
# yum install ruby-devel libxml2-devel libxslt-devel --enablerepo=epel,rbel6
# gem install knife-ec2
# scp user@chef-server:/etc/chef/validation.pem /etc/chef/validation.pem
# vi /etc/chef/client.rb
chef_server_url 'http://chef-server:4000'
node_name       'matetsu-work'
# chef-client

ここで通常作業する一般ユーザに切り替える。

$ knife configure
$ sudo chmod 644 /etc/chef/client.pem
$ ln -s /etc/chef/client.pem ~/.chef/matetsu-work.pem

ここで、server-webuiにログインして、登録したクライアント(matetsu-work)にadmin権限を与えておく。

Cookbookなどの準備

knife-ec2でEC2インスタンスを操作できるようにACCESS KEYなどを設定する。
~/.chef/knife.rb に以下を設定する。

knife[:aws_access_key_id] = "hoge"
knife[:aws_secret_access_key] =  "fuga"

最終的にはRailsアプリを動かすところまでやりたいので、rails-quick-startを使うことにする。とりあえずはあるものをserverに上げてしまう。ただ、この rails-quick-start のリポジトリにあるのは、Ubuntuで動かすための設定なので、CentOSの場合は変更すべきところが何点かあるが、今は気にしない。

$ git clone git://github.com/opscode/rails-quick-start.git
$ knife cookbook upload -a -o ./cookbooks/
$ rake roles
$ knife data bag from file apps radiant.json

EC2インスタンス起動時に最初に実行するコマンド群を記述したbootstrapをubuntu用から、CentOS用に作り変える。

$ cp .chef/bootstrap/ubuntu10.04-gems-qs.erb .chef/bootstrap/centos6-chef.erb[]

内容は以下のような感じ。

bash -c '
<%= "export http_proxy=\"#{knife_config[:bootstrap_proxy]}\"" if knife_config[:bootstrap_proxy] -%>

if [ ! -f /usr/bin/chef-client ]; then
  rpm -Uvh http://rbel.frameos.org/rbel6
  yum install -y rubygem-chef ruby-devel libxml2-devel libxslt-devel wget --enablerepo=epel,rbel6
fi

mkdir -p /etc/chef

(
cat <<'EOP'
<%= validation_key %>
EOP
) > /tmp/validation.pem
awk NF /tmp/validation.pem > /etc/chef/validation.pem
rm /tmp/validation.pem

(
cat <<'EOP'
<%= config_content %>
EOP
) > /etc/chef/client.rb

(
cat <<'EOP'
<%= { "run_list" => @run_list }.to_json %>
EOP
) > /etc/chef/first-boot.json

<%= start_chef %>'

roleのbaseを今回必要なものだけに絞るためにコピーをする。

$ roles/base.rb roles/centos_base.rb

内容はこんな感じ。gitはgitパッケージのインストールで、build-essentialはgccなどの開発ツールパッケージのインストール。

name "centos_base"
description "Base role applied to all centos nodes."
run_list(
  "recipe[git]",
  "recipe[build-essential]"
)

ちなみに、レシピ build-essential の centos向けの設定を以下のように変えている。

when "centos","redhat","fedora"
  %w{gcc gcc-c++ make automake}.each do |pkg|
    package pkg do
      action :install
    end
  end
end

変更をserverに反映する。

$ knife cookbook upload -o ./cookbooks/ build-essential
$ rake roles

EC2インスタンスの起動から初期設定まで

準備したcookbookやroleを用いて、実際にEC2インスタンスの起動〜初期設定を行ってみる。これまた簡単。knife ec2コマンドで一発です。

$ knife ec2 server create -G [SECURITY_GROUP] -I [AMI_ID] -f [INSTANCE_KIND] -S [KEY_PAIR_NAME] -i [PRIVATE_KEY_FILE] -x [EC2_LOGIN_USER] -d [BOOTSTRAP_FILE] -r '[COMMA_SEPARATED_ROLES_OR_RECIPES]' --region [REGION_NAME] -Z [AZ_NAME]

これでAMIからEC2インスタンスを作成、bootstrapに記述された内容を実行、roleで指定されたレシピの実行が行われ、初期設定が完了した状態のノードが完成する。起動したインスタンスのIPなどは、server-webuiのnode一覧からも確認できますし、コマンド実行完了後に標準出力にも出力される。

こんな感じでコマンド一発で求める環境ができちゃうなんて、感動ですね。なんでもっと早く使っていなかったんだろう。

次は、railsアプリが動いている状態を作れるようにしたいと思います。

Chefを試す

いまさらながら、Chefを試してみる。インストール後にやっていることは、SD10月号の id:rx7 さんの記事のとおり。突然使い始めた理由は、AWS上のインスタンスの管理のため。

構成

すべてVMWare Server上の仮想マシン。ネットワークはNATで構成。

• Chefサーバ
  • CentOS6 (192.168.92.11)
• Chefクライアント
  • CentOS5 (192.168.92.131)

EPELから必要なパッケージをインストールする

# rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/x86_64/epel-release-5-4.noarch.rpm
# yum install couchdb erlang rabbitmq-server libxml2-devel zlib-devel.x86_64
# service couchdb start
# chkconfig couchdb start
# vi /etc/yum.repos.d/epel.repo
enabled=0

Chefサーバの設定

RBELリポジトリを利用してインストール

# rpm -Uvh http://rbel.frameos.org/rbel6
# vi /etc/yum.repos.d/rbel6.repo
enabled=0
# yum install ruby ruby-devel ruby-ri ruby-rdoc ruby-shadow gcc gcc-c++ automake autoconf make curl dmidecode
# yum install rubygem-chef --enablerepo=rbel6
# yum install rubygem-chef-server --enablerepo=rbel6
# /usr/sbin/setup-chef-server.sh

このままだと、rabbitmq-serverのきどうで失敗する。
ログを見てみると良くわからないが、ipv6が云々カンヌンと書かれているので、IPv6を無効にしてみる。

# vi /etc/modprobe.d/ipv6_disable.conf
options ipv6 disable=1
# vi /etc/sysconfig/network
NETWORKING_IPV6=no
# reboot

再起動して、上のスクリプトを実行するとうまいこと全部起動する。

# /usr/sbin/setup-chef-server.sh
Checking RabbitMQ...
Configuring RabbitMQ default Chef user...

Starting CouchDB...

couchdb を起動中:                                          [  OK  ]
Enabling Chef Services...

Starting Chef Services...

chef-server を起動中:                                      [  OK  ]
chef-server-webui を起動中:                                [  OK  ]
chef-solr を起動中:                                        [  OK  ]
chef-expander を起動中:                                    [  OK  ]

これにて、起動完了。
と思ったら、chef-serverとchef-server-webuiが起動していない。なぜ？
しばらく調べていてもわからず、しばらくして再度 /etc/init.d/chef-server{,webui} start を実行したら普通に起動した。。。

※翌朝確認したら、また落ちていた。その時のログなのかは定かではないが、以下のメッセージが出ている。

merb : chef-server (api) : worker (port 4000) ~ Failed to authenticate. Ensure that your client key is valid. - (Merb::ControllerExceptions::Unauthorized)

関係あるのかな？
だが、今はあまり時間が無いので、とりあえず理解のために先へ進む。

Chef-clientの設定

インストール

こちらもRBELを用いてインストールする。

# rpm -Uvh http://rbel.frameos.org/rbel5
# vi /etc/yum.repos.d/rbel5.repo
enabled=0
# yum install rubygem-chef --enablerepo=epel,rbel5

サーバへのアクセス

node_nameは必ずしもhostnameと一致している必要はないが、一致させたほうが運用上は良いと思われる。今回は特に気にせず設定してしまった。

server# scp /etc/chef/validation.pem 192.168.92.131:/etc/chef/
client# vi /etc/chef/client.rb
chef_server_url 'http://192.168.92.11:4000'
node_name       'centos5'
client# chef-client

コマンド実行後に、/etc/chef/client.pemが作成され、エラーが出力されていなければ、サーバに登録されている。

knife(コマンドライン操作ツール)

knifeの初期化

# knife configure
WARNING: No knife configuration file found
Where should I put the config file? [~/.chef/knife.rb]
Please enter the chef server URL: [http://test.mase.vm:4000] http://192.168.92.11:4000
Please enter an existing username or clientname for the API: [root] centos5
Please enter the validation clientname: [chef-validator]
Please enter the location of the validation key: [/etc/chef/validation.pem]
Please enter the path to a chef repository (or leave blank):
# ln -s /etc/chef/client.pem /root/.chef/centos5.pem

設定の確認

# knife node list
centos5

Chefのディレクトリ一式を作成する

Opscodeのgithubからディレクトリのひな形をダウンロードする。

# mkdir chef
# cd chef
# wget --no-check-certificate -O chef-repo.tar.gz http://github.com/opscode/chef-repo/tarball/master
# tar zxf chef-repo.tar.gz
# mv opscode-chef-repo-a3bec38 chef-repo

Cookbookを作る

knifeコマンドで、sampleという名前のcookbookを作成する。

# knife cookbook create sample -o ~/chef/chef-repo/cookbooks
 ** Creating cookbook sample
 ** Creating README for cookbook: sample
 ** Creating metadata for cookbook: sample
# ls chef-repo/cookbooks/sample
README.md  attributes/  definitions/  files/  libraries/  metadata.rb  providers/  recipes/  resources/  templates/

Recipeの作成～サーバへの登録

動作を確かめるために、実際にRecipeを書いてみる。

# vi chef-repo/cookbooks/sample/recipes/default.rb
template "/tmp/centos5.txt" do
    source "centos5.txt.erb"
    mode 0644
end
# vi chef-repo/cookbooks/sample/templates/default/centos5.txt.erb
Welcome to Chef!

CPU   :<%= node[:cpu][:"0"][:model_name] %>
Memory:<%= node[:memory][:total] %>
OS    :<%= node[:platform] %> <%= node[:platform_version] %>

Chef-serverへ登録してみる。
cookbookのuploadをする際に、クライアントがadmin権限を持っていないとauthorizeされないので、事前にadmin権限を付与しておく。
※server-webuiから行ったが、コマンドラインから行えるのだろうか。

# knife cookbook upload -a -o ~/chef/chef-repo/cookbooks/

Cookbookをnodeに紐付ける。

# knife node run_list add centos5 'recipe[sample]'

クライアントに反映する

先ほど登録して紐付けたcookbookを実際にクライアントに反映をする。

# chef-client
# cat /tmp/centos5.txt
Welcome to Chef!
   
CPU   :Intel(R) Core(TM) i5 CPU         650  @ 3.20GHz
Memory:514896kB
OS    :centos 5.7 

エラーが何も出なければOK。

Attributeを試す

Attributeはデフォルト値や共通値、ノード固有の値を定義するためのもの。

# vi chef-repo/cookbooks/sample/attributes/default.rb
# cat chef-repo/cookbooks/sample/attributes/default.rb
default[:memo] = "None."
# knife cookbook upload -a -o ~/chef/chef-repo/cookbooks/
# chef-client
# cat /tmp/centos5.txt
Welcome to Chef!
   
CPU   :Intel(R) Core(TM) i5 CPU         650  @ 3.20GHz
Memory:514896kB
OS    :centos 5.7
Memo  :None.

このノードにはmemoというattributeは設定されていないので、defaultで設定した「None.」が表示される。そこで、このノードのattributeを設定して見る。

# EDITOR=vi knife node edit centos5
{
  "normal": {
    "tags": [
     ],
    "memo": "This is a centos5 for chef test."
  },
  "name": "centos5",
  "chef_environment": "_default",
  "run_list": [
    "recipe[sample]"
  ]
}

# chef-client
# cat /tmp/centos5.txt
Welcome to Chef!

CPU   :Intel(R) Core(TM) i5 CPU         650  @ 3.20GHz
Memory:514896kB
OS    :centos 5.7
Memo  :This is a centos5 for chef test.

といった形で、設定したattributeが反映されていることが確認できる。

こんな感じで、簡単んなチュートリアルは完了。ここからどうやって本番運用に合わせていくかは、利用者のセンス次第ですよねorz

まずは、opscodeのgithubからとってきたcookbookを自分らの環境に合わせてカスタマイズしていくところから。

(追記:2012/02/06)
[http://blog.frameos.org/2011/07/07/chef-0-10-2-rpms-now-available-at-rbel-frameos-org/comment-page-1/#comment-1383]
ここにあるように、複数の3rd Party製rubygem-*パッケージをインストールしていると、chef-serverの起動に失敗するとのこと。新しけりゃいいってもんじゃないってことだ。

Vyatta on EC2からVPC にVPN接続をする

東京リージョンのVyatta on EC2とUS EASTのVPCとの間でVPN接続を実現する。最近ではよく試されていることだと思うが、VyattaもAWSもほとんど触ったことが無いので、仕事用の検証と練習を兼ねて。

参考にした、ここ( Amazon EC2(Vyatta)からAmazon VPCに接続してみた - log4moto )に書かれていることそのものです。Twitterでも質問に答えて下さり、本当にお世話になりました。

というわけで、設定に入っていく。

EIPの準備

VPCで利用できるVPN接続は、site-to-siteで固定IPが必要なため、予め東京リージョン側でElastic IPを準備しておく。(この時点ではEC2インスタンスを準備してある必要はない)

VPCを作成

• "Get Started creating VPC" または "Create Another VPC" ボタンから、VPCを作成する。

• 今回は、 "VPC with Public and Private Subnets and Hardware VPN Access" を選択

• 先ほどの Elastic IP の IP アドレスを Customer Gateway として設定する。

• サブネットは好みのものを指定(Customer Gatewayの内部セグメントと被らないように)。AZは特に指定しない。

• VPCの作成が始まる。

• 作成が完了すると、ルータに投入する設定をダウンロードできる。
  • 通常は、自分の利用するベンダーの機器を指定するのだが、今回は Vyatta を利用するので、Generic を指定する。ここでダウンロードしたファイルから、 http://gen-vyatta-conf.fluxflex.com/ を利用して Vyatta の設定ファイルを生成する。

• "Yes, Download" を選択すると、VPN connection IDが名前となったテキストファイルがダウンロードされる。

Vyatta用の設定を生成

• http://gen-vyatta-conf.fluxflex.com/ にアクセスし、必要な情報を入力する。

• "作成" を押すと、Vyattaに流し込むための設定ファイルとVPN経由のルーティング設定用スクリプトが生成される。

一部修正が必要な点があるので、それはその際に説明をする。EIPもリリースしたし、特に伏せる情報ではないと思うが、なんとなく伏せておいた。

Vyatta インスタンスの起動と初期設定

• AMI ID ami-0204b003 の Vyatta Core 6.3 rev.11のAMIを用いてインスタンスを作成する。

ほとんどデフォルト設定のmicro-instanceで。Name を vyatta-vpc としておく。Key-Pair新規作成か既存の最新のものを利用する(AMI中の設定で利用しているkey-pairが最新のものをさしているため)。
Security Groupはまずは、SSHのみをAnyから許可した設定で新規作成。

• インスタンスが出来上がったら、早速Elastic IPを割り当てて、ログインをする。

$ ssh -i path/to/private_key vyatta@EIP

• とりあえず、Time ZoneをJSTに変更して保存する。

$ configure
[edit]# set system time-zone Asia/Tokyo
[edit]# commit
[edit]# save
[edit]# exit

• 上で生成した設定ファイルを微修正する。
  • http://d.hatena.ne.jp/j3tm0t0/20110502/1304328905 こちらのエントリを参考に、自分の環境に合わせて修正をする。
    1. interface loopback lo に内部セグメント用のIPアドレスを追加で設定。
    2. vpn ipsec site-to-site peer * local-ip にEIPのグローバルIPが設定されているので、インスタンスの Private IP (eth0 の IP)を設定する(ここは起動のたびに変更されるため、自動化したい場合は更に手を加える必要あり)。今回は 10.152.94.170 。
    3. vpn ipsec site-to-site peer (2つめのpeer) ike group IKE2
    4. vpn ipsec site-to-site peer (2つめのpeer) tunnel 1 esp-group ESP2
    5. vpn ipsec site-to-site peer (2つめのpeer) tunnel 2 esp-group ESP2
  • 3～5はIKE2とESP2が使用されていないので、このように変更したが、意味のある変更かどうかは未検証(接続は問題なくできる)

• 設定を流し込む。

$ configure
[edit]# merge /home/vyatta/vpc2vpn.txt
Warning: file does NOT appear to be a valid config file.
Do you want to continue? [no] Y
Loading configuration from '/home/vyatta/vpn2vpc.txt'...
Merge complete.  Use 'commit' to make changes active.
[edit]# commit
[edit]# exit
(起動のたびに設定が変わるので、saveは実行しない)

• ルーティングの設定スクリプトを実行する。

# sh ./connect.sh

これで、Management Console の VPC タブにある VPN Connections の 設定した VPN ID で Tunnel 1 と Tunnel 2 が UP になっていればOK。

• Pingで IPSec のIPで疎通が出来るかどうかを確認する。

$ ping 169.254.255.1
OK!
$ ping 169.254.255.5
OK!

VPC内のサブネットとの通信を確認する

Private Subnetにインスタンスを作成

Private Subnetにインスタンスを作成して、Vyattaの内部IPと通信が出来るかどうか確認する。IPアドレスは手動で設定する(今回は 172.16.1.11)。Secrity GroupはICMPとSSHをAnyから許可。

Private Subnetの Security Group と Route Table を設定

• Security Group
  • Vyatta 内部セグメントからのAll Traficを許可(inbound)
• Route Table
  • Vyatta 内部セグメントへは vgw を経由するよう設定(MainがYesのほう)
  • 172.16.1.0/24 を Associate

Private Subnetの疎通確認

• PingでICMPの確認

$ ping 172.16.1.11
OK！

• SSHでのログイン確認
  • 秘密鍵を Vyatta に配置

$ vi .ssh/priv-key.pem
$ chmod 600 .ssh/priv-key.pem

• ログイン確認

vyatta$ ssh -i .ssh/priv-key.pem ec2-user@172.16.1.11
ip-172-16-1-11$ 
OK！

Public Subnetにインスタンスの作成

インスタンスを作成して、Vyattaの内部IPと通信が出来るかどうかの確認と、EIPを割り当ててインターネットとの通信を確認する。プライベートIPは手動で設定する(今回は 172.16.0.11)。Secrity GroupはVyattaの内部セグメントからの All Traffic を許可。

Public SubnetにElastic IPの割り当て

VPC内部から外部と通信するためには、EIPが必須。

Public SubnetのSecurity Group と Route Table を設定

• Security Group
  • Vyatta 内部セグメントからのAll Traficを許可(inbound)
• Route Table
  • Vyatta 内部セグメントへは vgw を経由するよう設定(MainがNoのほう)

Public Subnetの疎通確認

• PingでICMPの確認

$ ping 172.16.0.11
OK！

• SSHでのログイン確認(秘密鍵はprivateと共通)
  • ログイン確認

vyatta$ ssh -i .ssh/priv-key.pem ec2-user@172.16.0.11
ip-172-16-0-11$ 
OK!

• インターネットへのアクセス

$ ping www.google.co.jp
OK!

NATインスタンスの作成

Private Subnetからインターネットにアクセスするためには、Public Subnetに配置された EIP を持った NAT インスタンスにNATしてもらう必要がある。

NATインスタンスはAMIが提供されているので、それを利用する。(Amazon Images から NATで検索)

もちろん、Public Subnetに配置されるようにする。プライベートIPは 172.16.0.10 を割り当てる。Security GroupはNAT用に新たに生成(Privateからの通信を許可するようにする)。

NATインスタンスに EIP の割り当て

これ必要。

インスタンスの設定変更

NATインスタンスとして動作させるための設定。 "Change Source / Dest Chek" を Disable にする。

Private Subnetの Route Table変更

デフォルト(0.0.0.0/0)のルーティングをNATインスタンスに向けるようにする。

NATインスタンスを経由しての疎通確認

• Private Subnetからインターネットへのアクセス

$ ping www.google.co.jp
OK!

設定完了！

これであとは、Public <-> Private 間のSecurity Group設定と、Public Subnetに対する外部からのアクセスを設定すれば、問題なし！

最初に試したときに、Vyattaの内部セグメントを 10.2.0.0/16 とかにしたら、戻りパケットが来なかったので、多分AWS内部のSubnetとかぶってしまったのではないかと予測。今回のサブネット設定であれば、特に何の問題もなく設定できた。最初から通しても2～3時間くらいでできた！

こんな簡単にこんなに素敵な環境が手に入るなんて、AWSってやっぱすげーや。
ほぼ初めて触っても、簡単に環境構築ができるって素晴らしい。

という訳で、ここまで検証ができたので、すべてのインスタンスやらEIPやらVPCやらを削除します！ｗ

参考にさせていただいたページ

• Amazon EC2(Vyatta)からAmazon VPCに接続してみた - log4moto
• さくらのVPSにVyattaを入れて、Amazon VPCにVPN接続 - kikumotoのメモ帳
• vyatta で Amazon VPC に接続 - shercoの日記
• Amazon VPCに接続するためのVyatta向け設定ファイルを作成するWebツールを作ってみました - kikumotoのメモ帳

その他にも、Twitterでアドバイスしてくださった @j3tm0t0 さん、@ar1 さん、@shot6 さん、@oko_chang さん、ありがとうございました！！
(Twitter IDにリンクできない。。。)

登録してみた

とりあえず、このアカウントでちゃんと書いていこうと思う。