ロケットネットでもベンチマークしてみた

何かロケットネットさんがキャンペーンで50GBのディスク容量にも関わらず年間1,000円キャンペーンをやってたので思わず釣られてみたw
いやいや、月額じゃなくて年額1,000円ですよ!これは事件です!

まぁ共用のレンタルサーバーということでVPSとも違うのであんまり自由度も無いけど、取りあえずデータのバックアップ用にでも使おうかと思って借りてみました。
念のため(というかこれが目的になってる節もありますがw)いつものようにPHPspeedをやってみたぜ!
ちなみにOSはCentOSっぽいです。

ちょっと前にやった[AWS] EC2マイクロインスタンスのベンチマークしてみたに追記する形でまとめます。

ベンチ結果

EC2 micro
EBS
EC2 small
instance-store
さくらVPS
512
ServersMan@VPS
Standard
ロケットネット
Synthetic
PHP BenchMark
3,267 1,262 2,507 1,693 3,794
Synthetic
MySQL BenchMark
13,748 5,234 11,072 5,168 6,005
Synthetic
Read/Write BenchMark
865 792 1,406 901 2,910
Real World
PHP BenchMark
2,639 1,320 4,659 3,090 4,493
Real World
PHP & MySQL BenchMark
838 994 2,179 1,287 2,054
Server BenchMark 1,415 969 2,548 1,300 2,838

正直なところ驚きました。
当然ながらVPSやら共用サーバーは当たり外れがあると思いますので、一概に断言はできませんがロケットネットのパフォーマンスはかなりスゴいです。
キャンペーン無しの値段でも初期費用1,575円、月額735円ということで一番安いため、大した性能は期待していませんでしたが、比較したやつの中ではトップクラスでした。後発有利とはいえこれは結構驚きです。
回線品質は確認してないですけどCDN的な使い方もアリかもしれないです。

おまけレベルですがsshも使えて、実際触っていても引っかかる感じが全くないのでアリだと思います。ただ、rsyncでバックアップしようと思ってたのにやっぱりrsync使えなかった(つーか初めに確認しろよオレw)ので若干ショックです><
chmodすら無くてftp経由でパーミッション変更しないといけないとかイミフw
まぁバックアップの方法は適当に考えることにしよう。

Railsも使えるっちゃ使えるみたいなのですが、いかんせんバージョンがかなり古いですねぇ。普通のホームページやらblogやらphp使ったサイトとかなら全然おkですが、ちょっと凝ったことをしようと思ったらやっぱちょっと厳しいですね。
(この辺りがPHPでサイト作る人が圧倒的に多い理由じゃ無いかといつも思う。)

まとめ

ロケットネットがオススメの人
・画像いっぱい動画もうpなホームページを作りたい人
・お手軽に独自ドメインでブログとかメールとかやってみたい人
 →ただ使い勝手的にhetemlロリポのがオススメw
・ちょっとWebアプリの作り方を勉強してみたいし、PHPだと捗るって聞いた人
・ターミナルの黒い画面が苦手なのでブラウザでイロイロ設定したい人

ロケットネットがオススメじゃない人
・容量とか別に無くてもいい人
・Railsってかなり捗るって聞いた人
・Google先生と仲良くなるにはPythonとDjangoだろって人
・サーバーをイロイロいじって勉強したい人
・735円出すのが惜しい人
 →つーか月額100円台からあるよね今。。。

ちなみに自分的にお気に入りというかオススメランキングはこんな感じ
EC2 > さくらのVPS > ロケットネット > ServersMan@VPS

ServersMan@VPSはベンチに現れていませんが、頻繁に反応が鈍くなります。ssh使っててもイライラするレベルw
今ServersMan@VPSで運用している業務アプリがあるのですが、今月末にちょっとメンテを入れるのでそのタイミングでEC2のTokyoに切り替える予定なくらいあまり気に入っていないw
まぁこの辺はOpenVZの仕様的なところも関係するのかもしれないですね。



まぁ、とりあえず一年1000円で使えるうちにから借りとけってことですw

Filed under: AWS,Internet,Linux — maesan 2:01 AM

[AWS] EBSブートについての覚え書き

エントリー[AWS] EC2マイクロインスタンスのベンチマークしてみたでも書いてましたが、EC2のマイクロインスタンスはEBSブートのAMIでしか使えません。今までinstance-storeのAMIしか使ったことが無かったので、イメージの保存〜リカバリーの勝手が分からずちょっと自分なりに調べてみたので覚え書きにする。

 

そもそもEC2って?

元々EC2ではEBSってのは無くて、instance-storeのみでサービスしてたらしいです。

AMIイメージから起動して使用する手順

  1. S3に保存されているAMIイメージを選択する
  2. クラウド上にイメージを展開する
  3. オンメモリでインスタンスが展開される。シャットダウンすると消える

起動しているインスタンスを永続化する手順

  1. インスタンスのイメージを作成する
  2. 作成したイメージをS3にアップロードして保存する

この辺の流れはシンガポールが追加されたAmazon EC2で遊んでみた[S3編]を参考にしてください。

S3はストレージサービスと言っても普通にマウントして使うようなやり方はできなくて、httpを使ってファイルを送受信するだけのシンプルなサービス(何せSimple Storage Service → S3ですからw)なので、インスタンスからマウントできるようなストレージサービスとしてEBS(Elastic Block Storage)ってのが提供されるようになったようです。

 

EBSについて

ではS3とは別のEBSって何かってことですが、EBSを使う流れは簡単にいうとこんな感じ

EBSの使い方

  1. サイズを指定してボリュームを作成する
  2. 作成したボリュームを起動中のインスタンスにアタッチする
  3. インスタンスでアタッチしたボリュームをマウントする

ココまではイイんだけど、じゃあEBSブートって何よ?ってのが疑問になったわけ。イメージ的にはシャットダウンしても消えないインスタンスが使えるようになるんだって思って、だいたい合ってました。

EBSブートのインスタンスが起動するまでの流れ

  1. EBSブート用のAMIから起動する
  2. 自動的にEBSボリュームが作成され、イメージが展開される
  3. EBSボリュームからインスタンスが起動する
  4. 終了するとstop状態でEBSボリュームが残る (設定でterminateにもできるので注意)
  5. terminateするとEBSボリュームが消える

インスタンスの状態にはrunningとterminateとstopってのがあって、terminateするとデータ全部消えちゃいます。EBSだとterminateしても消えないのかなって思ったけど残念ながら消えます><その代わりEBSにはstopって状態が存在して、stopにしておくとスナップショットをとって保存しておけます。また、stopならそこからもう一度起動することもできます。

 

スナップショットからAMIイメージを作成してリカバリーする方法

stopにしておけばデータは消えないのですが、同じインスタンスをもう1個立ち上げたいとか誰かにオレオレAMIを公開したいとかできないし、stopのままおいておくのもなんか気持ち悪いのでどうやってEBSブートAMIを作るのか調べました。
スナップショットはManagement Consoleからでも簡単にできるのですが、AMIイメージの作成はManagement Consoleからはできず、コマンドラインインターフェースを使う必要がありました。
実際の手順はこのページ「EC2においてEBS Snapshotでバックアップを取得しそれをリカバリする方法」がスゴくわかりやすかったです。

インスタンスの情報が以下でスナップショットの名前がsnap-xxxxxxxxとすると
Root Device: /dev/sda1
Kernel ID: aki-xxxxxxxx
RAM Disk ID: ari-xxxxxxxx 

コマンドはこんな感じ

#ec2-register -n イメージ名 -d ‘イメージの説明’ –root-device-name /dev/sda1 -b /dev/sda1=snap-xxxxxxxx -a i386 –kernel aki-xxxxxxxx –ramdisk ari-xxxxxxxx

*64bitの場合はi386をx86_64に

これでMy AMIにオレオレイメージが作成されましたのでいつでもインスタンスを立ち上げることができるようになりました。

Filed under: AWS,Internet — maesan 11:30 PM

[AWS] EC2マイクロインスタンスのベンチマークしてみた

いつの間にやらEC2にsmallインスタンスの更に下のmicroインスタンスってのが使えるようになったらしいので、ちょっとやってみた。

他のサービスと比較

まずは似たようなサービスと比較してみます。
AWSの東京リージョンも最近できましたが、前からシンガポール使ってたので、それ基準で。
VPSとEC2は違うものですが、値段的に同じくらいのさくらVPSとServersMan@VPSも表に入れてみた。

  スペック 初期費用(年) 料金/時間 料金/月間
EC2 スモール
(オンデマンド)
CPU:仮想1コア
メモリ:1.7GB
ストレージ:160GB*
0 $0.095 $68.4 (約5,700円)
EC2 マイクロ
(オンデマンド)
CPU:仮想1コア
メモリ:613MB
ストレージ:従量(EBS)
0 $0.025 $18 (約1,500円)
EC2 マイクロ
(リザーブ)
CPU:仮想1コア
メモリ:613MB
ストレージ:従量(EBS)
$54 $0.01 $7.2 (約600円)
さくらのVPS
512
CPU:仮想2コア
メモリ:512MB
ストレージ:20GB
0 980円
ServersMan@VPS
Standard
CPU:仮想2コア
メモリ:512MB
ストレージ:30GB
0 980円

*ただしシャットダウンすると跡形も無く消え去ります><

スモールはちょっと頭抜けてますが、マイクロのリザーブは初期費用入れるとだいたい980円くらいなのでさくらVPS 512やServersMan@VPS Standardとほぼぴったりな感じです。
ただ、EC2はデータの転送量に応じた料金がかかりますし、EC2のマイクロインスタンスはEBSブートのみなのでストレージ費用も別途かかります(月$0.1/GB+I/0に応じて)
そのためやっぱちょっと金額は他と比べるとかかっちゃいます。ただ、普通のVPSと違ってアクセスが集中した時でもある程度ブーストしてくれるのでその辺はクラウドの強みかなと思います。

ベンチマーク!

では皆さんも大好きなベンチマーク結果をw
ベンチマークはAWS, さくらVPS, hetemlでベンチマークしてみたと同じくPHPspeedでやってみました。
アレから時間も経ってるので、スモールとさくらVPSも再計測してみました+ServersMan@VPSも最近使い始めたのでそれもまとめてみました。

  EC2 micro
EBS
EC2 small
instance-store
さくらVPS
512
ServersMan@VPS
Standard
Synthetic PHP BenchMark 3,267 1,262 2,507 1,693
Synthetic MySQL BenchMark 13,748 5,234 11,072 5,168
Synthetic Read/Write BenchMark 865 792 1,406 901
Real World PHP BenchMark 2,639 1,320 4,659 3,090
Real World PHP & MySQL BenchMark 838 994 2,179 1,287
Server BenchMark 1,415 969 2,548 1,300

まとめ

いや、何かの間違いと思いたいのですが、EC2のsmallが一番しょぼいってどうよ?w
何かもう全部マイクロインスタンスに変えてやろうかと思ってしまったわ><
ちなみにsmallとmicroは同じAMIで、instance-storeで使ってたAMIをEBSに変換してmicroで使ってみました。
(この辺はまた別エントリーで書いてみます)
EBSブートの方がinstance-storeよりもIO性能が低いってAWSのページには書いてあったのですが、全然変わらないというかむしろ逆転している感が漂っています。。。

相変わらずさくらVPSがスゴすぎるのはいうまでもない感じですが、ServersMan@VPSが意外と健闘している感じがします。実際使ってみるとServersMan@VPSはたまに引っかかる感じというか、遅いと感じる時があるのですが、ベンチマークとってみるとあまり目立ってばらついては無かったです。

一番ばらつきが大きかったのがEC2のmicroでした。短期ブーストってAWSの説明に書いてあったけど、いざという時は瞬発力を発揮してくれるのかもしれないですね。

まぁ取りあえずさくらのVPS
使っとけば間違いは無いってことですかね?W



Filed under: AWS,Internet,MySQL,PHP — maesan 12:36 AM

AWS, さくらVPS, hetemlでベンチマークしてみた

hetemlはスゴく機能がいっぱいで使いやすくて大好きなのですが、どうも遅い。他にもAWSや、さくらVPSを使ってるのでベンチマークしてみた。

ベンチマーク方法

とりあえずPHP+MySQLの性能が図れれば一般的なwebアプリの性能が分かりやすいと思ったのでPHPspeedをやってみました。

計測対象は以下の5つです
・Local : MacOSX, Core2Duo 2.0GHz, メモリ4GB, HDD
・AWS small : EC2 smallインスタンス, Debian, シンガポール
・AWS medium : EC2 mediumインスタンス, Debian, シンガポール
・さくらVPS : Debian (カスタムOSインストール)
・heteml : OS不明

計測結果

すべて3回やって平均値です。

  Local AWS
small
AWS
medium
さくらVPS heteml
Synthetic PHP BenchMark 3,666 1,281 2,976 2,816 2,185
Synthetic MySQL BenchMark 1,615 5,613 10,028 9,281 175
Synthetic Read/Write BenchMark 1,886 798 1,950 1,784 2,053
Real World PHP & MySQL BenchMark 2,644 1,035 2,398 2,623 2,180
Server BenchMark 1,996 1,002 2,245 2,658 689

結論

イメージ的にはAWSのmediumが一番で速いのではないかと思っていて、だいたいあってる感じだったのですが、実はそれ以上にさくらVPSがかなり優秀だということがわかりました。
hetemlの遅さの原因がMySQLってのがわかりました。このへんちょっと改善してもらえれば快適になるような気がします。

まだまだサービス開始からあまり時間も経っていないので、さくらVPSが快適に使えているのかもしれませんが、コストパフォーマンスを考えてもダントツにおすすめな感じがしました。
サーバーの構築やら管理やらが苦にならないのであれば、heteml等のレンタルサーバーを借りるよりもさくらVPSSを借りて好き勝手やっちゃったほうがかなりお得な気がします。

サービス内容で比較するとAWSとさくらVPSは似て非なるサービスで、AWSのほうが色々そろってます。個人的に一番の差と感じるのがOSのイメージをS3に保存しておける点でしょうか。
さくらVPSのOSインストールもかなり簡単で、すぐ環境は用意できるのですが、やっぱりOSイメージそのものから復帰するのとはだいぶ違いますね。
このあたりは使い道とかで変わってくるとは思いますが、まぁコスト的にさくらVPSとAWSのsmallで6倍(円高ありがとう価格で)、mediumになると10倍以上の差があるのでコストパフォーマンスは抜群でしょうね。



Filed under: AWS,PHP — maesan 5:47 PM  Comments (3)

EC2から送信したメールがspam扱いされてたのを回避するまでの記録

EC2でサイトの運営を開始したのですが、そのIPがブラック(ブロック)リストに載っててメールが届かない人がいたので、それを回避するまでのメモを残します。
ウワサには聞いていたのですが、あまりに気していなかったのはテストとかで自分とか携帯とかに普通に送れてたのでリストに載ってなかったり、こういうスパムリストってあんまり使ってないのかなと軽く考えていたからでした。
で、何で発覚したかというとフツウにメールのログに見慣れない文字列が出てきたからです

Sep 1 15:03:43 xxxxxxxx postfix/smtp[7722]: 5DA663A64F: to=, relay=mail.xxxxxx.jp[xxx.xxx.xxx.xxx]:25, delay=4.4, delays=0.05/0/4.1/0.17, dsn=4.0.0, status=deferred (host mail.xxxxxx.jp[xxx.xxx.xxx.xxx] said: 451 http://www.spamhaus.org/query/bl?ip=xxx.xxx.xxx.xxx (in reply to RCPT TO command))

spamhausだと!?
ま、とりあえずサービス開始直後にコレなわけでw
ちょっと洒落にならず急いで以下の対処方法を考えてみた
・IPをリリースして再取得してリストから離れるのを待つ
 →EC2のシンガポールのIPすべてリストに載ってるらしいから却下w
  しかもDNSの浸透の関係で即効果がでないため現実的ではない。。。
・何にせよ削除申請
 →spamhausのAWSのレンジは削除申請できない?
  どうやら自動で削除されるらしいから何にせよすぐには反映されない
  いずれにせよDNSの逆引きとかの対処が必要
・他のサーバーへのRelay
 →幸いこのドメインはGoogle Appsでメールを運用しているのでとりまgmailを使ってメール送ることにする

DNSの逆引き設定

どうやらspamhausは動的IPアドレスということでリストに載せているらしい。確かにEC2でインスタンス立ち上げてメール大量送信してインスタンス落とせば簡単にspamを送信できるし、足もつきづらいよね。
だからと言ってEC2のレンジ全部入れるなよとw
で、DNSの逆引きレコードが登録されていたら動的IPじゃないと認めてくれるっぽいのでDNS逆引きレコードを登録する必要があるわけです。
正直この判定って気休めでしかないし共用サーバーとかでは不可能だわなw
そのへんがブロックリストに載ったらどうするんだろうね?w
とりあえず以下のページからAWSに申請する
https://aws-portal.amazon.com/gp/aws/html-forms-controller/contactus/ec2-email-limit-rdns-request
これ申請する直前にメール送信数制限解除の申請してたから(もちろんまだ制限解除されていない状態)連続でやるのは気まずい気がしたが、仕方なく送信。
簡単に説明を英語で書かないといけないけど、まぁ適当な英語でおk
んでこれ反映されるまで時間かかるのでその間にSPFの登録をする

SPFの設定(value-domainの場合)

メール送信者がドメインを偽装してないよって証明するのがSPF証明ってやつなのですが、仕組みを簡単に説明するとドメインに対してこのIPアドレスとかホストとかからメールを送信しますよってのをDNSに登録することです。
ようするに
・DNSの設定である → ドメインの所有者である
・DNSにこのIPからしかメール送りませんよと宣言
・登録されていないIPからメールが送信された → ドメインの所有者ではない
→偽装メールだよ
って仕組みです。
細かい仕様とか設定方法とかは他の賢い人に任せるとして、以下の前提の場合設定はこんな感じ
・IPアドレスがxxx.xxx.xxx.xxx
・google appsでメール使ってる

txtレコードとして以下を登録
v=spf1 ip4:xxx.xxx.xxx.xxx include:_spf.google.com ~all

試しにメールを送ってヘッダ情報を確認するとReceived-Spfってのがあると思います。

Gmailを使ってメール送信

DNSの逆引きやらSPFを登録したところで、今まさに送信できない状況をすぐに解決はできないので緊急手段としてGmailを使ってメールを送信することにした。
サーバーはDebian、メールはPostfixでとりあえず動いてる状態とする
・gmailのsmtpは認証が必要なのでSASL入れる
#apt-get install sasl2-bin
#apt-get install libsasl2-modules

・/etc/postfix/main.cf にrelayhostの設定する


relayhost = [smtp.gmail.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl/passwd
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous
smtp_sasl_mechanism_filter = plain
smtp_use_tls = yes
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

・認証用のパスワードファイル作る
#echo [smtp.gmail.com]:587 xxxxxxxx@xxxxxx.com:password > /etc/postfix/sasl/passwd
#postmap /etc/postfix/sasl/passwd

パスワードが平文で入ってるので気持ち悪いから見えないように
#chown root:root /etc/postfix/sasl/passwd
#chmod 600 /etc/postfix/sasl/passwd

・Postfixを再起動する
#/etc/init.d/postfix restart
これでgmailで送信できるようになったよと
もしエラーとか拒否のときだけgmail使うようにしたかったら、


relayhost =
fallback_relay = [smtp.google.com]:587

で行けると思われます

まとめ

結局当日には逆引きもリスト解除も間に合わなかったのでgmailでメール送信する形になっちゃいました。
翌日には逆引きも反映され、spamhausのリストからも外れていました。(ホントに自動だぜw)
ついでにmapsにも登録されていたっぽいので、逆引きも反映されたので削除申請しておきました。
なんつーか気持ちは分からないでもないけど、こういうスパムリスト的なものはあまり使ってほしくないなと思いましたw
大手だとhotmailはそうだし、独自ドメインとか自前サーバーとか使ってる人の中でもspamhausを使ってる人がいて困りましたね。
もし複数ドメイン運用しているサーバーとかだったら、全部のドメインでGoogle Apps使ったり送信者登録するのも現実的ではないしまた別の方法を考えないといけないかもですねぇ。
まぁちょっと不謹慎ですが、今回は色々勉強できて面白かったですw

ホーメル スパム 20%レスソルト 340g
ホーメル 売り上げランキング: 1136
Filed under: AWS — maesan 1:42 PM

Debianにnslookupが入ってなかった

EC2でDebianのAMIを使ってたんだけど、ふとnslookupを使いたくなってコマンドいれたら入ってなかった。。。

#apt-get install dnsutils

で入った。
いつも当たり前に入ってると思ってたのが入ってなかったのでちょっと焦った。

よくわかるAmazonEC2/S3入門 ―AmazonWebServicesクラウド活用と実践 (Software Design plusシリーズ)
藤崎 正範 深海 寛信 五十嵐 学 馬場 俊彰 技術評論社 売り上げランキング: 46496
Filed under: AWS — maesan 6:28 PM

シンガポールが追加されたAmazon EC2で遊んでみた[S3編]

前回「シンガポールが追加されたAmazon EC2で遊んでみた[起動編]」ではインスタンスの起動まで説明しました。
でもこのままでは終了すると変更は破棄されてまたゼロからスタートになります。
そのため、AmazonのS3(Simple Storage Service)ってのを使います。
S3ってのは簡単にいうとクラウド化されたストレージなんだけど、サーバー等にマウントして使ったりはできなくてファイル単位で管理するシンプルなストレージサービスです。
なのでEC2とS3を連携させる場合にはEC2で使うAMIをOSのイメージとしてS3に保存しておき、起動させるときにOSイメージを呼び出してインスタンスを起動するって感じに使います。
とりあえずAWSにログインしてダッシュボード開いて「Amazon S3」タブ開く

するとS3を使ってオブジェクトを保存するためにはバケットを作れって書いてあるので「Create Bucket」を押します。Bucketってのは日本語的にバケツの意味ですが、S3的にはフォルダの親玉な感じです。BucketにFolderを作ってその中にファイルを格納するようなイメージです。
「Create Bucket」を押すとBucket名とRegionを選択するダイアログが出ます。

今回はシンガポールで遊ぶのが目的なので「Singapore」を選んで適当なBucket名を付けて「Create」します。今回はBucket名を「maesan」にしました。
すると左のBucketsの所に作成したBucketが表示されます。
そのBucketを選択すると右側にWindowsのエクスプローラーみたいな感じのがあるのでそこで「Create Folder」を押してフォルダを作ります。
今回はFedoraのイメージを保存しようと思いますので適当に「fedora001」って名前で作ってみました

でココマデできたら次はインスタンスを起動してEC2のツールを使って保存します。
インスタンス内でEC2のコマンドラインツールを使わないといけないのですが、それにはX.509証明書とか必要になります。
なのでAWSの「Account」から「Security Credentials」のページへ行きます。
・右上あたりの「Account Number」ってのをメモ
ページ中程に「Access Credentials」ってのがあるので、
・Access Keysをメモ
・Secret Access Keyの「Show」も押してメモ
次に「X.509 Certificates」タブを開いて「Create a new Certificate」をクリック

するとダウンロード用のダイアログがでるのでどっちも保存する
cert-xxxx.pemってファイルとpk-xxxx.pemってファイル

んでコレをさっき起動したインスタンスに転送する
説明は以下と仮定して
・Key Pairs → maesan.pem
・Private Key → pk-xxx.pem(ほんとはもっと長い)
・ X.509証明書 → cert-xxx.pem(ほんとはもっと長い)
・インスタンスのpublic DNS → ec2-xx-xx-xx-xx.ap-southeast-1.compute.amazonaws.com
ターミナルから以下のコマンドを実行する。Windowsの場合はWinSCPとかそのへん使ってください><

>scp -i maesan.pem pk-xxx.pem root@ec2-xx-xx-xx-xx.ap-southeast-1.compute.amazonaws.com:/root
>scp -i maesan.pem cert-xxx.pem root@ec2-xx-xx-xx-xx.ap-southeast-1.compute.amazonaws.com:/root

んでインスタンスにsshでログインする

>ssh -i maesan.pem root@ec2-xx-xx-xx-xx.ap-southeast-1.compute.amazonaws.com

色々カスタマイズしてS3に保存したい状態になったらまずEC2のツールを使ってOSのイメージ(AMI)を作成する–userのとこにはメモっといたAccount Number入れる

#ec2-bundle-vol -d /mnt –privatekey pk-xxx.pem –cert cert-xxx.pem –user xxxx-xxxx-xxxx -r i386

結構時間かかるのでしばらく待つ。
-rは32bitなら i386、64bitなら x86_64を指定します。
ちょっとイラってするくらい時間かかるかも。。。

Copying / into the image file /mnt/image…
Excluding:
/sys
/proc
/sys/fs/fuse/connections
/dev/pts
/proc/sys/fs/binfmt_misc
/dev
/media
/mnt
/proc
/sys
/mnt/image
/mnt/img-mnt
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.021742 s, 48.2 MB/s
mke2fs 1.40.4 (31-Dec-2007)
NOTE: rsync with preservation of extended file attributes failed. Retrying rsync
without attempting to preserve extended file attributes…
NOTE: rsync seemed successful but exited with error code 23. This probably means
that your version of rsync was built against a kernel with HAVE_LUTIMES defined,
although the current kernel was not built with this option enabled. The bundling
process will thus ignore the error and continue bundling. If bundling completes
successfully, your image should be perfectly usable. We, however, recommend that
you install a version of rsync that handles this situation more elegantly.
Bundling image file…
Splitting /mnt/image.tar.gz.enc…
Created image.part.00
Created image.part.01
Created image.part.02
Created image.part.03
Created image.part.04
Created image.part.05
Created image.part.06
Created image.part.07
Created image.part.08
Created image.part.09
Created image.part.10
Created image.part.11
Created image.part.12
Created image.part.13
Created image.part.14
Created image.part.15
Created image.part.16
Created image.part.17
Created image.part.18
Created image.part.19
Created image.part.20
Created image.part.21
Created image.part.22
Created image.part.23
Created image.part.24
Created image.part.25
Created image.part.26
Created image.part.27
Created image.part.28
Created image.part.29
Created image.part.30
Created image.part.31
Created image.part.32
Created image.part.33
Created image.part.34
Created image.part.35
Created image.part.36
Created image.part.37
Created image.part.38
Created image.part.39
Created image.part.40
Created image.part.41
Created image.part.42
Created image.part.43
Created image.part.44
Created image.part.45
Created image.part.46
Created image.part.47
Created image.part.48
Created image.part.49
Generating digests for each part…
Digests generated.
Unable to read instance meta-data for product-codes
Creating bundle manifest…
ec2-bundle-vol complete.

んでイメージ出来上がったらS3に転送
–access-keyと–secret-keyにはさっきメモたやつ入れる

#ec2-upload-bundle –bucket maesan/fedora001 –manifest /mnt/image.manifest.xml –access-key xxxx –secret-key xxxx

Uploading bundled image parts to the S3 bucket maesan …
Uploaded image.part.00
Uploaded image.part.01
Uploaded image.part.02
Uploaded image.part.03
Uploaded image.part.04
Uploaded image.part.05
Uploaded image.part.06
Uploaded image.part.07
Uploaded image.part.08
Uploaded image.part.09
Uploaded image.part.10
Uploaded image.part.11
Uploaded image.part.12
Uploaded image.part.13
Uploaded image.part.14
Uploaded image.part.15
Uploaded image.part.16
Uploaded image.part.17
Uploaded image.part.18
Uploaded image.part.19
Uploaded image.part.20
Uploaded image.part.21
Uploaded image.part.22
Uploaded image.part.23
Uploaded image.part.24
Uploaded image.part.25
Uploaded image.part.26
Uploaded image.part.27
Uploaded image.part.28
Uploaded image.part.29
Uploaded image.part.30
Uploaded image.part.31
Uploaded image.part.32
Uploaded image.part.33
Uploaded image.part.34
Uploaded image.part.35
Uploaded image.part.36
Uploaded image.part.37
Uploaded image.part.38
Uploaded image.part.39
Uploaded image.part.40
Uploaded image.part.41
Uploaded image.part.42
Uploaded image.part.43
Uploaded image.part.44
Uploaded image.part.45
Uploaded image.part.46
Uploaded image.part.47
Uploaded image.part.48
Uploaded image.part.49
Uploading manifest …
Uploaded manifest.
Bundle upload completed.

ダッシュボードのS3からファイルが転送されたか確認します。

で、最後にこのイメージでインスタンスを起動できるようにAMIとして登録します。
ダッシュボードの「AMIs」をクリックして「Register New AMI」をクリックするとAMIのパスを指定するダイアログが出ます。

ココで「バケット名/フォルダ名/image.manifest.xml」を入れて「Register」を押して完了です。
これでいつでもダッシュボードの「AMIs」で「Owned By Me」にこのAMIが登録されるのでいつでもインスタンスを起動することができます。
お疲れさまでした〜
シンガポールが追加されたAmazon EC2で遊んでみた[登録編]
シンガポールが追加されたAmazon EC2で遊んでみた[起動編]

Amazon EC2/S3/EBS クラウドコンピューティングによる仮想サーバ構築
清水 正人 ソシム 売り上げランキング: 226726
Filed under: AWS — maesan 1:16 AM  Comments (1)

シンガポールが追加されたAmazon EC2で遊んでみた[起動編]

前回「シンガポールが追加されたAmazon EC2で遊んでみた[登録編]」でAWS+EC2の登録までいけましたので、今回はとりあえずインスタンスを起動してスゲーするまでを説明しますね。
まずはAmazon Web ServicesからAWS Management Consoleにログインしてみましょう。

今回はシンガポールで遊びたいので左上の「Region」を「Asia Pacific」にしてから真ん中あたりの「Launch Instance」を押すとウィザードが始まります。
初めにAMI(Amazon Machine Image)を選択します。
AMIってのは簡単にいうとEC2で起動できるOSイメージのことです。今回は簡単に起動させてスゲーしたいだけなのでfedoraのLAMP Web Starterを選択します。

次にインスタンスのタイプを選びます。
今回はインスタンスの数は1個、場所はどこでも、インスタンスタイプを「Small」にします。
「Launch Instances」と「Request Spot Instances」が選択できますが、通常使用する場合は従量課金になる「Launch Instances」でイイと思います。
「Continue」を押して次へ

Kernel IDやRAM Disk IDとか選べますがとりあえずデフォルトで問題なし。
ちょっと遊ぶだけなのでMonitoringもオフでおkです。コレ別途お金かかるっぽいですしw
んで「Continue」を押して次へ

次に暗号鍵を設定します。
既にKey PairをCreateしている場合は「Choose from your existing Key Pairs」でそれを選択して「Continue」、もし作っていない場合や、別のKey Pairにしたい場合は「Create a new Key Pair」します。

次にセキュリティー(ファイアーウォール)の設定します。
デフォルトで「Create a new Security Group」になってると思います。今回はSSHとHTTPがあればとりあえずおkなので、それに適当な名前をつけて「Continue」します。
もしここでSSH開けてなかったら全く手も足も出なくなっちゃうので必ずSSHは開けておきましょう。一回間違ってSSH開けずに進めたら起動後何もできずシャットダウンしか出来なかった悲しい出来事がありましたのでw

ちなみにコレ任意のポート開けたい時は、ダッシュボードのSecurity Groupのところでやります。
最後に最終確認で「Launch」を押すとインスタンスが起動します!

でダッシュボードに戻ると「Instances」に今起動したインスタンスが確認できます。

今回の目的はとりあえず起動してスゲーすることなのでブラウザでアクセスしてみる
インスタンスの情報でpublic DNSってところに書いてあるホスト名でアクセス
http://ec2-xxx-xxx-xxx-xxx.ap-southeast-1.compute.amazonaws.com みたいなの
今回選んだAMIだといきなりapacheとか立ち上がってるので

phpinfo キタ━━━━(゚∀゚)━━━━ !!!!!
で、まぁお金も勿体無いのですぐ止めてもいいのですが、せめてSSHでの接続方法を説明します
ダッシュボードのインスタンスを右クリックして「Connect」を選ぶと説明が出ます。

keyのファイル(xxxx.pem)のパーミッションを400にしてsshに-iオプションをつけて接続します。
例:
/Users/maesan/Download にmaesan.pemってキーファイルがある場合で
インスタンスのpublic DNSがec2-xxx-xxx-xxx-xxx.ap-southeast-1.compute.amazonaws.comの場合

$cd /Users/maesan/Download
$chmod 400 maesan.pem
$ssh -i maesan.pem root@ec2-xxx-xxx-xxx-xxx.ap-southeast-1.compute.amazonaws.com

とりあえずrootのパスワードは必ず変更するように!

#passwd
Changing password for user root.
New UNIX password: パスワード入れる!
Retype new UNIX password: もっかい入れる!
passwd: all authentication tokens updated successfully.

これで色々とサーバーの設定とかできますよと。
インスタンスを止めるにはダッシュボードのインスタンスを右クリックで「Terminate」すれば終了します。
またはsshでログインしてるのであればたいていのLinuxのディストリの場合
#shutdown -h now
で終了します。
StatusがTerminatedになってたらシャットダウン完了です。

ちなみにTerminateしてしまうと、このリストに残ってるインスタンスは起動できませんw
リストに残りますが、そのうち勝手にリストから消えますのでご安心を
もしインスタンスに設定した内容を永続的に保持したい場合はS3というサービスを使う必要があります。コレはまた次回に〜

Amazon EC2/S3クラウド入門
Amazon EC2/S3クラウド入門
posted with amazlet at 10.07.18
学びing 秀和システム 売り上げランキング: 249105
おすすめ度の平均: 3.5

2 内容が古く、これだけでは説明不足2 入門書です4 Amazonを使ってクラウドビジネスを始めたいと思う人におすすめ3 情報収集が面倒な方にはちょうどよいです5 すぐに試したい人におすすめ

Filed under: AWS — maesan 12:02 AM

シンガポールが追加されたAmazon EC2で遊んでみた[登録編]

前からAmazonのEC2が気になってたのですがUSって遠いし遅いんじゃね?とか思ってたので手を出してませんでした。
で、この春にAsia Pacificとしてシンガポールが追加されたので俄然興味が出てきた!
ちょうど最近シンガポールがらみの仕事のネタが増えてきましたのでちょうどイイタイミングかなと思いちょっと遊んでみた。
今回はEC2の登録まで〜
とりあえずAmazon Web Serviceのページに行って「Sign Up Now」する

フツウにメールアドレスいれて「I am a new user.」にチェックでSign inする。

多分コレAmazon.co.jpとかで買い物するアカウントとは無関係と思われる。
名前とメールアドレスとパスワードいれて「Create account」する

んで住所とか入れる
前さんはAddress Line 2も使って入力してたんだけど、何回やっても正しい住所じゃねぇとか怒られたので無理矢理Address Line 1に詰め込んで登録した。。。

とりあえずアカウントの登録はこれでおk

次にEC2の登録を行ないます。EC2のページに行きまして、「Sign Up For Amazon EC2」押してさっき作ったアカウントでSign inします。

するとEC2の課金額がずらずらと表示されます。

このページの一番下にクレジットカード情報を入力するフォームがあるので入力して「Continue」します。

もしAmazon Web Serviceのアカウントの名義と違うクレジットカードを使う場合はカード名義を登録する必要があります。
通常は同じだと思いますので「Use This Address」で

最近は電話で本人確認が必要なサービスが多いですが、AWSも本人確認のために電話認証があります!

アカウント登録時の電話番号がデフォルトで入っているのですが、国際電話なので電話番号のアタマの0をとっておいてください。
例:090-xxxx-xxxx → 90-xxxx-xxxx
んで「Call Me Now」するとすぐにアメリカの電話番号から電話がかかってきますw
当然英語ですが、生身の人間じゃ無いのでまぁそんなに緊張せずに。
PINを入力してください的な事を言われます。画面が以下の感じに変わってると思いますので、この4桁のPINを電話で入力します。

正しくPINを入力すると本人確認おkとなり、自動的に画面が更新されます。「Continue」をクリック

「Complete Sign Up」をクリック

最後にこの画面になってメールが届いて完了です。

お疲れさまでした〜
シンガポールが追加されたAmazon EC2で遊んでみた[起動編]

AmazonCloudテクニカルガイド ―EC2/S3からVPCまで徹底解析―
李 昌桓 インプレスジャパン 売り上げランキング: 35706
Filed under: AWS — maesan 3:50 PM
 iTunes Store(Japan)
 iTunes Store(Japan)
 iTunes Store(Japan)
 iTunes Store(Japan)
 iTunes Store(Japan)