今後ともよろしくお願いします。
oko_changのインフラ日誌
ふらふら適当に世間を生きる日々でございます
2012年1月16日月曜日
2012年1月3日火曜日
Amazon Linuxで使われてるcloud-initをCentOS6で使ってみる
新年あけましておめでとうございます。
年明け最初の更新をこんなに早くするとは自分でも驚きですが、今年もブログをゆるく継続していきたいと思います。
年明け最初の更新をこんなに早くするとは自分でも驚きですが、今年もブログをゆるく継続していきたいと思います。
さて、AWSを使用している方はAmazon Linuxに興味を持った事があると思います。
Redhat系のディストリビューションを使用していた方は操作感も近くてスイッチしやすいのではないでしょうか?
私も何度かAmazon Linuxを使用しましたが、その中でcloud-initってとても便利だなと思いました。
cloud-initはもともとUbuntuに搭載されたクラウド環境でのセットアップツールみたいですが、Amazon Linuxではこの機能が標準で移植されております。
個人的にはChefとかよりもチャラく使えるようなイメージでしょうか。。。
AWSで提供されているUbuntuやAmazon Linuxはcloud-initを使って、指定したSSH公開鍵の設置や、セキュリティアップデートなどが行われているようです。
自前でCentOSなどのAMIを作成した経験がある方はSSHの公開鍵を設置するスクリプトを使った事があると思いますが、Amazon Linuxではcloud-init経由でec2-userに公開鍵を設置しているのですね。
『なるほどー、これはCentOSでも使ってみたいですよねー』というネタです。
Redhat系のディストリビューションを使用していた方は操作感も近くてスイッチしやすいのではないでしょうか?
私も何度かAmazon Linuxを使用しましたが、その中でcloud-initってとても便利だなと思いました。
cloud-initはもともとUbuntuに搭載されたクラウド環境でのセットアップツールみたいですが、Amazon Linuxではこの機能が標準で移植されております。
個人的にはChefとかよりもチャラく使えるようなイメージでしょうか。。。
AWSで提供されているUbuntuやAmazon Linuxはcloud-initを使って、指定したSSH公開鍵の設置や、セキュリティアップデートなどが行われているようです。
自前でCentOSなどのAMIを作成した経験がある方はSSHの公開鍵を設置するスクリプトを使った事があると思いますが、Amazon Linuxではcloud-init経由でec2-userに公開鍵を設置しているのですね。
『なるほどー、これはCentOSでも使ってみたいですよねー』というネタです。
■AmazonLinuxで使用されているcloud-initのsrpmを取得する
Amazon Linuxで以下のようにコマンドを実行すると/usr/src/srpm/debug/以下にsrpmが保存されるので、これをCentOSでビルドします。
Amazon Linuxで以下のようにコマンドを実行すると/usr/src/srpm/debug/以下にsrpmが保存されるので、これをCentOSでビルドします。
# get_reference_source -p cloud-init Requested package: cloud-init Found package from local RPM database: cloud-init-0.5.15-20.amzn1 Corresponding source RPM to found package : cloud-init-0.5.15-20.amzn1.src.rpm Are these parameters correct? Please type 'yes' to continue: yes Source RPM downloaded to: /usr/src/srpm/debug/cloud-init-0.5.15-20.amzn1.src.rpm
■CentOSでcloud-initのrpmを作成する
ビルドに必要なライブラリをインストールします。
epelをyumのリポジトリに追加している方はPyYAMLとlibyamlもyumでインストールが出来ると思います。
一部specファイルを以下のように編集しています。
ビルドに必要なライブラリをインストールします。
epelをyumのリポジトリに追加している方はPyYAMLとlibyamlもyumでインストールが出来ると思います。
# yum -y groupinstall "Development Tools" "Development Libraries" && yum -y update # yum install python-devel python-configobj python-cheetah # cd /usr/local/src/ # wget ftp://ftp.iij.ad.jp/pub/linux/fedora/epel/6/i386/PyYAML-3.09-5.el6.i686.rpm # wget ftp://ftp.iij.ad.jp/pub/linux/fedora/epel/6/i386/libyaml-0.1.3-1.el6.i686.rpm # rpm -ivh libyaml-0.1.3-1.el6.i686.rpm PyYAML-3.09-5.el6.i686.rpm次に事前に転送しておいたcloud-initのsrpmをビルドします。
一部specファイルを以下のように編集しています。
# rpm -ivh --nomd5 cloud-init-0.5.15-20.amzn1.src.rpm # cd /root/rpmbuild/ # grep ^BuildRequire ./SPECS/cloud-init.spec BuildRequires: python-devel-abi # grep ^Require ./SPECS/cloud-init.spec Requires: sudo Requires: rpm Requires: yum Requires: python-configobj Requires: python-cheetah Requires: python-yaml # vi ./cloud-init.spec 21 #BuildRequires: python-devel-abi 22 BuildRequires: python-devel 25 #Requires: python-yaml 26 Requires: PyYAML # grep ^Source ./SPECS/cloud-init.spec Source0: cloud-init-%{version}.tar.gz # cd ./SPECS/ # time rpmbuild -bb --clean ./cloud-init.spec real 0m0.061s user 0m0.043s sys 0m0.017s
■インストール
作成されたcloud-initのrpmをインストールします。
specファイルを見ると分かりますが、インストールするとec2-userやsudoの設定が追加されます。
作成されたcloud-initのrpmをインストールします。
specファイルを見ると分かりますが、インストールするとec2-userやsudoの設定が追加されます。
# rpm -ivh /root/rpmbuild/RPMS/noarch/cloud-init-0.5.15-20.el6.noarch.rpm 準備中... ########################################### [100%] 1:cloud-init ########################################### [100%]
■動作確認
インストールしたインスタンスからAMIを作成し、以下のようなUserDataを指定して起動してみました。
無事にec2-userへの公開鍵登録と 指定したパッケージがインストールされていましたよ:)
インストールしたインスタンスからAMIを作成し、以下のようなUserDataを指定して起動してみました。
無事にec2-userへの公開鍵登録と 指定したパッケージがインストールされていましたよ:)
#cloud-config packages: - httpd - postfix
こんな事するならAmazon Linux使った方が(ryという突っ込みはご勘弁下さい:D
ラベル:
AWS,
CentOS,
cloud-init,
Linux
2011年12月25日日曜日
Vyattaを使ってElastic Network Interfaceの動作確認をしてみる
先日、AWSから新しいサービスElastic Network Interfaceがリリースされました。
簡単に言うとAmazon VPC内のインスタンスにNICの二枚差しが可能になるサービスなようです。
今までAWSのインスタンスはeth0しか使えなかったので、これは便利になりそうです。
VPC内のネットワーク構成の幅が大きく広がるようなサービスなので、少しだけ触ってみました。
二枚差しって事はVPC内のルーティングテーブルを使わずにVyattaとかでルーティングしたりNATしたり出来るので、それを試します。
※ちなみにこちらにあるように、今までもNAT Addressingを使ってNATをする事は出来ました。
今回テストをした構成は以下のようなイメージとなります。
Vyattaは@j3tm0t0さんが作成されたAMIを使用させて頂きました。
※ENIはManagement Consoleからも作成可能で、インスタンス起動時/起動後どちらでも追加する事が出来ます。
※インスタンス起動後にChange Source/Dest CheckをDisableにする事をお忘れなく。
■割り当てたローカルIPと同じ設定をVyatta側に設定します
まだ触り始めたばかりですが、ENIはVPCで色々なネットワークを構成出来るのでインフラエンジニア的にはとてもワクワクしますね!
簡単に言うとAmazon VPC内のインスタンスにNICの二枚差しが可能になるサービスなようです。
今までAWSのインスタンスはeth0しか使えなかったので、これは便利になりそうです。
VPC内のネットワーク構成の幅が大きく広がるようなサービスなので、少しだけ触ってみました。
二枚差しって事はVPC内のルーティングテーブルを使わずにVyattaとかでルーティングしたりNATしたり出来るので、それを試します。
※ちなみにこちらにあるように、今までもNAT Addressingを使ってNATをする事は出来ました。
今回テストをした構成は以下のようなイメージとなります。
Vyattaは@j3tm0t0さんが作成されたAMIを使用させて頂きました。
※ENIはManagement Consoleからも作成可能で、インスタンス起動時/起動後どちらでも追加する事が出来ます。
※インスタンス起動後にChange Source/Dest CheckをDisableにする事をお忘れなく。
■割り当てたローカルIPと同じ設定をVyatta側に設定します
$ configure # set interfaces ethernet eth1 address 10.2.2.200/24 # set interfaces ethernet eth1 smp_affinity auto # set interfaces ethernet eth1 speed auto # commit # run show interfaces ethernet Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down Interface IP Address S/L Description --------- ---------- --- ----------- eth0 10.2.1.200/24 u/u eth1 10.2.2.200/24 u/u [edit] # save■Vyattaで行うNATの設定を行います
# set service nat rule 10 type masquerade # set service nat rule 10 source address 10.2.2.0/24 # set service nat rule 10 outbound-interface eth0 # commit # save■確認用インスタンスAの起動直後のルーティングテーブルは以下のようになっています
# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.2.2.0 * 255.255.255.0 U 0 0 0 eth0 default 10.2.2.1 0.0.0.0 UG 0 0 0 eth0■確認用インスタンスAに以下のようなルーティングを追加してみます
# route add -net 10.2.1.0 netmask 255.255.255.0 gw 10.2.2.200■設定後のルーティングテーブルは以下のようになります
# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.2.1.0 10.2.2.200 255.255.255.0 UG 0 0 0 eth0 10.2.2.0 * 255.255.255.0 U 0 0 0 eth0 default 10.2.2.1 0.0.0.0 UG 0 0 0 eth0■インスタンスBへの疎通テストを行ってみます
# ping -c 3 10.2.1.201 PING 10.2.1.201 (10.2.1.201) 56(84) bytes of data. 64 bytes from 10.2.1.201: icmp_seq=1 ttl=63 time=31.2 ms 64 bytes from 10.2.1.201: icmp_seq=2 ttl=63 time=0.849 ms 64 bytes from 10.2.1.201: icmp_seq=3 ttl=63 time=0.863 ms --- 10.2.1.201 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 0.849/10.995/31.275/14.340 ms■インスタンスBへの経路を確認するとVyattaを経由している事がわかります
# traceroute 10.2.1.201 traceroute to 10.2.1.201 (10.2.1.201), 30 hops max, 60 byte packets 1 10.2.2.200 (10.2.2.200) 0.785 ms 0.769 ms 0.751 ms 2 10.2.1.201 (10.2.1.201) 1.088 ms 1.232 ms 1.213 ms■インスタンスAからインスタスBにアクセスしてNATが動作しているかApacheのアクセスログを見て確認してみました
# tail -f /var/log/httpd/access_log 10.2.1.200 - - [25/Dec/2011:12:00:43 +0000] "GET /index.html HTTP/1.1" 200 12 "-" "curl/7.19.7 (i386-redhat-linux-gnu) libcurl/7.19.7 NSS/3.12.9.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2"今回はインスタスAからインスタンスBでNATされていますが、NATせずルーティングのみさせた場合はNetwork ACLsも動作します。
まだ触り始めたばかりですが、ENIはVPCで色々なネットワークを構成出来るのでインフラエンジニア的にはとてもワクワクしますね!
2011年11月30日水曜日
RDSの自動停止、自動起動スクリプト(right_aws)を作る
前回から一ヶ月以上経過していて相変わらずブログの更新が滞り気味ですが、引っ越しなどをしていた訳です。
ちなみに、引越で一番大事にしたポイントはPC作業を行うための机と椅子これに限ります!
3月11日から数日は自宅でお仕事をしていたのですが、ちゃぶ台にPCとか腰が爆発しちゃいます(汗)
家で仕事したいわけじゃないですが、ブログ書いたり勉強したりする時には重宝しますよねー。
こうしてブログを書いている今も机と椅子のありがたさを実感しております。
そんな訳でこれからはブログの更新頻度がアップしないとかしないとか(汗)
今回もAWSネタなのですがRDSを使っているとどうしても一時停止が出来ない事に不便さを感じますよね。
RDSを使ってる方は既に同様の事をしているかと思いますが、私もスナップショットとリストアを組み合わせた停止/起動スクリプトを作ってみました。
パッと思いつく自動化したいポイントは以下のとおりです
- RDSのスナップショットを作成した上での停止
- 最新のスナップショットからの起動
- スナップショットからRDSをリストアした時にセキュリティグループを割り当て
- スナップショットからRDSをリストアした時にパラーメタグループを割り当て
※cronとかに登録すれば起動中、停止中を判断して自動で起動したり停止したりします。
※AWSSDK for Rubyを使いたかったのですが、RDSに未対応なのでright_awsを使っています
指定するパラーメタグループはMySQLのバージョンと合わせないとエラーになってしまいます。
また、現状ではスナップショットを削除する処理が入っていません。
入れた方が便利かなと思いつつ、どんな条件で削除するか悩み中。
スナップショットが特定の数以上になったら余分な数を消すって感じが一番事故がなさそうか。。。
ただ作っておいてなんですが、
そのうちRDSで停止がサポートされてこんなスクリプト必要なくなるんだろうなー。
2011年10月10日月曜日
Vyattaを使ってAmazon VPC内に独自NAT環境を作る
このブログでクラウド関連の話題というと、ほとんどRackspace Cloudばかりなのですが…
今回のエントリは珍しくAWSをテーマにしてみたいと思います。
Twitterを見ているとVyattaが最近アツく、個人的にも書籍を購入したのでAmazon VPCと連携させたいです。
AWSではVPCネットワークから外部へ接続するためのNATアドレッシングインスタンスが提供されておりますが、こちらをVyattaに置き換えて使ってみるという事です。
今回はNATを構成するだけですが、Vyattaは機能が豊富で様々な可能性をVPCに付け加える事が出来そうです。
ちなみに先日Vyatta社からアナウンスされた6.3のAMIはSubscription Editionということなので、今回はVyatta Core6.1のAMIを使用しています。
[ネットワーク構成]
[VPCの設定]
VPC内にはVyattaを起動する公開サブネットと、Webサーバを起動する非公開サブネットの2つを用意します。
[Vyattaインスタンスを起動]
今回はこちらのAMIを使用し、インスタンス起動後にはSouce/Dest. CheckをDisableとします。
この設定はVyattaインスタンスを起動後にインスタンスを選択して、右クリックのメニューから変更が出来ます。
VPC内でElastic IPを取得してVyattaインスタンスに割り当てる事も忘れずに!
このIPを使用してWebサーバは通信をします。
[ルートテーブル]
Management Console(VPC)のRoute Tableメニューで公開用/非公開用のルートテーブルを設定します。
公開用サブネットはデフォルトルートがインターネットゲートウェイとなり、非公開用はVyattaインスタンスのinstance-idを指定します。
[セキュリティグループ]
Vyattaに割り当てるセキュリティグループは、Webサーバからの必要な通信をブロックしなければ自由に設定可能です。
また、VPCで設定可能なネットワークACLも同じように自由に使えました。
[Vyattaインスタンスの設定]
起動したVyattaインスタンスにSSH接続し以下のような設定を行います。
それでは動作確認用に適当なインスタンスを非公開用セグメントで起動します。
インスタンス起動後は外部接続の動作確認を行い、Apacheをインストールしました。
Vyattaに割り当てたElastic IPにポート8080番を指定してアクセスすると以下のようにWebサーバに転送されました。
※おまけ
実はこの構成でVPCのDHCP Options Setを無効にしてDHCPサーバも動かそうとしたのですが、VPCもブロードキャストの通信がサポートされてないという事なので断念しました(汗)
[投入を予定していたDHCP関連の設定]
AWSが提供しているNATアドレッシングインスタンスも便利ですが、Vyattaユーザやルータの設定経験がある方はこのような構成にした方が理解しやすい部分もありそうですね。
[参考資料]
今回のエントリは珍しくAWSをテーマにしてみたいと思います。
Twitterを見ているとVyattaが最近アツく、個人的にも書籍を購入したのでAmazon VPCと連携させたいです。
AWSではVPCネットワークから外部へ接続するためのNATアドレッシングインスタンスが提供されておりますが、こちらをVyattaに置き換えて使ってみるという事です。
今回はNATを構成するだけですが、Vyattaは機能が豊富で様々な可能性をVPCに付け加える事が出来そうです。
ちなみに先日Vyatta社からアナウンスされた6.3のAMIはSubscription Editionということなので、今回はVyatta Core6.1のAMIを使用しています。
[ネットワーク構成]
[VPCの設定]
VPC内にはVyattaを起動する公開サブネットと、Webサーバを起動する非公開サブネットの2つを用意します。
[Vyattaインスタンスを起動]
今回はこちらのAMIを使用し、インスタンス起動後にはSouce/Dest. CheckをDisableとします。
この設定はVyattaインスタンスを起動後にインスタンスを選択して、右クリックのメニューから変更が出来ます。
VPC内でElastic IPを取得してVyattaインスタンスに割り当てる事も忘れずに!
このIPを使用してWebサーバは通信をします。
[ルートテーブル]
Management Console(VPC)のRoute Tableメニューで公開用/非公開用のルートテーブルを設定します。
公開用サブネットはデフォルトルートがインターネットゲートウェイとなり、非公開用はVyattaインスタンスのinstance-idを指定します。
[セキュリティグループ]
Vyattaに割り当てるセキュリティグループは、Webサーバからの必要な通信をブロックしなければ自由に設定可能です。
また、VPCで設定可能なネットワークACLも同じように自由に使えました。
[Vyattaインスタンスの設定]
起動したVyattaインスタンスにSSH接続し以下のような設定を行います。
■ホスト名の設定 $ configure [edit] # set system host-name vyatta61 # commit # exit ■時刻の設定 $ configure [edit] # set system time-zone Asia/Tokyo # commit # exit $ show date ■NAT設定(内部から外部への変換) $ configure [edit] # set service nat rule 10 outbound-interface eth0 # set service nat rule 10 source address 10.0.2.0/24 # set service nat rule 10 type masquerade # commit ■NAT設定(外部からの8080番ポートを内部へ変換) # set service nat rule 20 destination port 8080 # set service nat rule 20 inbound-interface eth0 # set service nat rule 20 inside-address address 10.0.2.100 # set service nat rule 20 protocol tcp # set service nat rule 20 type destination # commit # save ■NAT設定確認 # show service nat rule 10 { outbound-interface eth0 protocol tcp source { address 10.0.2.0/24 } type masquerade } rule 20 { destination { port 8080 } inbound-interface eth0 inside-address { address 10.0.2.100 } protocol tcp type destination }[Webサーバインスタンスの起動]
それでは動作確認用に適当なインスタンスを非公開用セグメントで起動します。
インスタンス起動後は外部接続の動作確認を行い、Apacheをインストールしました。
■NAT動作確認インスタンス起動 $ ping google.co.jp $ sudo yum -y install httpd $ sudo vi /etc/httpd/conf/httpd.conf 136 Listen 8080 $ sudo chkconfig --level 2345 httpd on $ sudo /etc/rc.d/init.d/httpd start $ sudo vi /var/www/html/index.html[ブラウザから動作確認]
Vyattaに割り当てたElastic IPにポート8080番を指定してアクセスすると以下のようにWebサーバに転送されました。
※おまけ
実はこの構成でVPCのDHCP Options Setを無効にしてDHCPサーバも動かそうとしたのですが、VPCもブロードキャストの通信がサポートされてないという事なので断念しました(汗)
[投入を予定していたDHCP関連の設定]
■DHCP設定 Amazon VPCの標準機能ではなくVyattaルータの設定で行います $ configure [edit] # set service dhcp-server shared-network-name oko_chang subnet 10.0.1.0/24 # set service dhcp-server shared-network-name oko_chang subnet 10.0.1.0/24 start 10.0.1.100 stop 10.0.1.200 # set service dhcp-server shared-network-name oko_chang subnet 10.0.1.0/24 default-router 10.0.1.254 # set service dhcp-server shared-network-name oko_chang subnet 10.0.1.0/24 dns-server 10.0.1.254 # commit # exit ■DNS設定 Amazon VPCの標準機能ではなく、Googleが提供しているルータの設定を行います $ configure [edit] # set system name-server 8.8.8.8 # commit # exit ■DNS転送設定 $ configure [edit] # set service dns forwarding listen-on eth0 # commit # exit
AWSが提供しているNATアドレッシングインスタンスも便利ですが、Vyattaユーザやルータの設定経験がある方はこのような構成にした方が理解しやすい部分もありそうですね。
[参考資料]
登録:
投稿 (Atom)