EC2で利用可能なWindows Server 2003を日本語化してみる
2009-02-16 01:47 | IT | 2 コメント »EC2上で利用できるWindowsサーバーが英語版ということもあって、日本語化したAMIイメージをいつでも利用できるようにしてみました。
なんだかものすごく長くなってしまったので、最初に目次を用意しておきます。
(目次の生成にTable of Contents Generatorプラグインを利用。これは便利。)
目次
まずはWindows Server 2003を立ち上げる
イメージ一覧を表示
イメージを選ぶ
今回はBasic Microsoft Windows Server 2003(Microsoft Windows 2003 R2 Data Center edition 32bit)を選択します。
鍵ファイルを生成
「windows」という名前を付けています
生成完了
生成が完了すると、「設定した名前.pem」というテキストファイルが自動的にダウンロードされます。
外部アクセス制限(ファイアーウォール)
windows用の設定なので3389ポートのみをオープンにした「windows_default」という名前のsecurity groupを作成します。
最終設定
インスタンス数(今回は1)とインスタンスタイプ(今回はsmall)を選びます。
インスタンスが起動しました。
インスタンス起動中のステータス
インスタンスはstarting→pending→runningの順でステータスが移り変わります。
Administratorパスワードを取得
EC2のシステムでランダムに生成されたAdministratorパスワードが指定した鍵ファイルを使って暗号化(encrypt)されているので、復号化(decrypt)して取得します。
Windowsのインスタンスを選んで、Passwordをクリックします。
ただし、インスタンス起動直後はパスワード生成と暗号化がまだ完了していないので、2、3分待ちます。
正常に生成が終わっていれば、この画面が表示されます。
Private Keyにテキストエリアに該当する鍵情報(今回はwindows.pemファイルの中身)をペーストします。
鍵が一致すれば復号化されたパスワードが表示されるので、記憶します。
リモートデスクトップで接続
接続の前に
既にIPアドレスがわかっているので接続できますが、「Conect」をクリックすることで、接続方法のヘルプが確認できます。
しかも、「OPTION 1: Shortcut File」にあるshortcut fileをダウンロードすることで、簡単に接続ができます。
リモートデスクトップで接続
リモートデスクトップを起動し、インスタンスのリモートホスト名を入力、接続します。
証明書で警告がでますが、無視して進めます。
無事接続できれば、ログオンダイアログが表示されます。
さっき記憶したAdministratorパスワードを入力し、ログオンします。
ログオンできれば、デスクトップが表示されます。
ちなみにMacの場合は
Microsoft純正のMac版リモートデスクトップがリリースされているので、そちらをダウンロードして利用しましょう。
試してみましたが、なんの問題も無く接続できました。
Mactopia Japan : Microsoft Remote Desktop Connection Client for Mac 2
いよいよ日本語化
日本語化するにはWindows Serverのメディア(CDのデータ)が必要になりますが、デフォルトのC、Dドライブには入っていません。
スナップショット
しかし、AmazonがスナップショットイメージとしてCDのデータを提供してくれているので、EBSを経由して利用します。
まず、インスタンスのZoneを確認しておきます。今回の場合は、「us-east-1b」でした。
EBSを利用してEドライブを作成
ELASTIC BLOCK STORE > Volumes > Create Volumeをクリックします。
ディスクサイズは 2G、ゾーンは先ほど控えたインスタンスと同じゾーンを選びます。
(ここでインスタンスと違うゾーンを選んでしまうと接続できなくなります。)
snapshotで、Windows 2003 R2 Datacenter 32-bitを選びます。(違うOSを利用している場合は該当するsnapshotを選びます。)
選択したsnapshotのIDと同じIDが一番下のテキストボックスに入力されたことを確認します。
(ここが空欄のままだと空のボリュームが作成されてしまいます。)
statusがavailableになったら利用するボリュームにチェックをして、Attach Volumeをクリックします。
接続先のインスタンスとデバイス(Windowsの場合はあまり関係ないですね。)を選びます。
ステータスがin-useになれば、接続が完了です。
インスタンスのWindowsへ戻ってみると、自動的にEドライブが認識されています。
ディレクトリ構成はこんな感じです。
Regional and Language Options
いよいよ、日本語化の設定です。
Regional and Language Optionsを実行します。
まずLanguagesタブにある日本語(東アジア圏の言語)をインストールするためのチェックボックスにチェックを入れます。
Advancedタブの設定も日本語(Japanese)にしておきます。
OKを押すと、CD-ROMを要求されます。
ここで先ほどのドライブを指定します。今回の場合は、E:¥Disk1¥i386になります。
ファイルのコピーが始まります。
全てコピーが終わった後、再起動します。
再起動の確認は?
再起動をするとコネクションが切れてしまうので、再起動したかどうかはOutputを見るとわかります。
再起動後、システムが正常に動いていれば「Windowos is Ready to use」というログが確認できるはずです。
ちなみにログをよく見てみると、ローカライズする前と後で日付の出力フォーマットが変わっています。
日本語の確認
再起動後、タスクバーの右下に言語切り替えが表示されています。
フォーマットの設定を日本語してみると、きちんと日本語で表示されます。
日本語の入力もできるようにキーボードの設定をします。
ブラウザーを立ち上げてみると。
このブログも化けずに表示されました。
日本語の入力も問題なしです。
日本語化したインスタンスをイメージ化(再利用)する
せっかく日本語化したので、いつでも利用できるようにイメージ化しようと思います。
起動中のインスタンスを選んで「Bundle」ボタンをクリックします。
自分のアカウントでアクセスできるS3のバケット名とファイル名を設定します。
設定に問題が無ければ、すぐにイメージ作成がはじまります。
Bundle Tasksをクリックすると、bundleの進行が確認できます。
ステータスは、bundling→storing→completeと変化します。
Windowsはデータが重いので結構時間がかかります。
complete後、EC2にAIMとして登録します。
左上にあるRegister as AMIボタンはアクティブにならない(不具合?)ので、登録したいイメージの行の上で右クリックするとポップアップメニューで「Register as an AMI」が表示されるので、こちらから登録します。
マニフェストファイルのパスを確認します。
登録されました。
登録すると、自分のAMI一覧にWindowsマークのついたAMIが表示されます。
EC2のコマンドラインと AWS Management Consoleを比べてみた
2009-02-07 02:09 | IT | コメントをする »AWS Management Consoleを実際に触ってみました。
今まではJavaベースのコマンドツール入れて(その前にJRE入れて)、コマンド叩いてはtypoしてイライラを募らせていたわけですが、それを解消する素晴らしいツールです。
まだBeta版ですが、*かなり* 完成度が高いです。
操作に全く疑問を抱かせない情報設計と洗練されたUI、そして安定的なシステム。素晴らしい。
今回は、コマンドでいうこれはConsoleでいうどういう操作?を比べてみました。
良く使うコマンドのみですが。
https://console.aws.amazon.com/ec2/
ec2-describe-images(Alias=ec2dim)
S3上に登録されているインスタンス化可能なイメージ一覧を取得するコマンド
Consoleでは左メニュのAMIsをクリックするだけで一覧がでます。
しかも、イメージの種類(Amazon謹製イメージ、公開イメージ、個人イメージ、自分のイメージ、アーキテクチャ別)で選べる上、
OS(CentOS,Debian,Fedora,Gentoo,Open Solaris,Red Hat,SUSE,Ubuntu,Windows)も合わせて検索できます。
これは便利ですね。
例)公開イメージの中からCentOSを選んだ状態
ec2-register(Alias=ec2reg)
S3上にあるイメージファイルをEC2に登録するコマンド
ConsoleではAMIsから上部メニュにある「Register New AMI」をクリックすると、ダイアログウィンドウがでるので、S3上にあるマニフェスト(xml)ファイルを指定します。
ec2-add-keypair(Alias=ec2addkey)
ログイン用の暗号キーを生成、登録するコマンド
Consoleでは、「Key Pairs」→「Create Key Pair」と進めていくと、秘密鍵の名前を聞くダイアログがポップアップします。
名前を入れ「Create」を実行すると、実行結果の表示と秘密鍵のダウンロードが始まります。
ec2-delete-keypair(Alias=ec2delkey)
生成済みのログイン用の暗号キーの登録を削除するコマンド
Consoleでは、「Key Pairs」→削除したいキーを選択→「Delete」→「Yes, Delete」で完了です。
ec2-run-instances(Alias=ec2run)
登録済みイメージからインスタンスを起動するコマンド
ダッシュボードトップから、「Launch Instances」をクリック
Launch Instancesから起動したいイメージを選び、「Select」をクリック
KeyPairもFirewallもすでに設定済みの場合は、一気に起動設定の項目まできます。
起動するインスタンス数、インスタンスの種類、利用するキー、Firewallのグループをすべて選び、「Launch」
無事起動すると、完了画面が表示されます。
ec2-authorize(Alias=ec2auth)
外部からどのポートにアクセスを許可するのか設定するコマンド
「Security Groups」を開くと、すでに設定済のものがあれば一覧が表示されます。
右上のリストを選ぶと、右下に詳細設定画面が表示され、ここで設定できます。
許可リストなので、LinuxでWebサーバーならば、22番と80番を許可したリストを作って「web_on_linux」などと名前を付けて用意しておくと便利かもしれません。
許可リストは複数作成してAND条件で複数指定できるようなので、linux_defaultで22番/webで80番と作って2つをセットする使い方が美しいですね。
ec2-terminate-instances(Alias=ec2kill)
起動中のインスタンスを停止するコマンド
Instancesを選び、インスタンス一覧から停止したいインスタンスをチェックし、「Terminate」をクリック
確認ダイアログがポップアップするので、「Yes, Terminate」を実行。
あーもう絶対コマンド使わなくなるな。
Amazon CloudFrontを体験してみた
2008-12-15 01:30 | IT, エントリー | コメントをする »遅くなりましたが、CloudFrontを体験してみました。
実験の前に参考サイト
CloudFrontの設定方法や、ダウンロードのベンチマークなどは以下のサイトを参考にしましょう。(と丸投げ)
- AmazonS3上のファイルを国内でも高速配信可能なAmazon CloudFrontリリース : Media Technology Labs (MTL) : メディアテクノロジーラボ ブログ
- Amazonの従量課金制CDNサービス「Amazon CloudFront」を使う方法 – RX-7乗りの適当な日々
実験の方法
今回やりたかったことは、ブラウザーを使って普通にブラウジングをしてみて、体感を測ることです。
- HTMLファイル 1
- JSファイル 5
- CSSファイル 2
- 画像ファイル 25
合計33ファイル、163KBのページを表示して、ページがロードされる具合を体感してみました。
EC2単体で体感実験
まずは、全てをEC2のスモールインスタンス上にアップした状態で体感。
Apacheは2.2.9、設定はrpmのデフォルト。KeepAliveはOFF。
やはりもっさり感は否めません。(4.6秒)
CloudFrontで体感実験
では1のHTML以外をS3にアップロードして、CloudFront経由で体感してみます。
これは明らかに速い(1.16秒)。EC2の場合は「ただいま画像1つ1つをロードしてます」って感じで画像が描画されるまでもたもたしていましたが、CloudFront経由の場合はページのロードと同時に画像も描画されました。
Etagもきっちり返してくれるので2回目以降のアクセスには304が返ってきますし、gzipを利用したhttp圧縮も行われているので、cssやjsなどのテキストファイルは効率よく転送されるはずです。
ただし、最初のアクセス時はキャッシュサーバーにデータが届いていないため、キャッシュする為にS3サーバーからの転送時間が加わるので、もっさり感を感じます。2回目はX-Cacheヘッダーが上画像のように変わります。
まとめ
実に簡単な体感実験ですが、CloudFrontの実力は歴然でした。
イメージサーバなどの用途で静的なファイルを負荷分散をするサーバーを立てるケースを想定すると、アクセス急増時にロードバランサー配下のリアルサーバーを増やしたり、静的なファイルを共有する、もしくは分散する仕掛けを用意したり、トラッフィクに注意したり、メンテナンスと運用にかかる時間と人のリソースは、想像に難しくありません。
上記のような心配が必要なサービスを運用している会社さんの場合は、当然既にakamaiなどのCDNを利用していると思いますが、それでもファイル転送元のリアルサーバーは持っている必要があります。
CloudFrontの場合は、配信元サーバーがS3なので、そこのリソースも気にしなくて済みます。
社内でかかるメンテナンスコスト(ベンダー保守、社内保守・監視、対応)、電気代、帯域代、ラック代、サーバー代など様々なコストを考えると、すべて込み込みで1GB/30円っていうのはかなり魅力的ではないでしょうか。
EC2用にCentOS5.2のAMIを作ってみた
2008-12-01 01:33 | IT, エントリー | 3 コメント »CloudFrontで生まれ変わるか
EC2は日本からだと相変わらず帯域がもっさりしているんですが、Amazon CloudFrontがリリースされて、利用方法を工夫すれば、まともに使えるのでは?と俄然注目です。
CloudFrontはS3上に配置したファイルを展開するCDNで、しかもキャッシュサーバーが日本国内にもあるので、静的なコンテンツはCloudFrontで配信、動的なコンテンツはEC2で配信と分散すれば体感はだいぶ速くなるんじゃないでしょうか。
Amazon Machine Image(AIM)を作る
その実験に先立って、いざという時に安心して使えるEC2用のイメージを持っておこうと思い、使い慣れているCentOSのオリジナルイメージを作ってみました。
作成したイメージファイルを圧縮・分割してS3上に置いた上で、EC2にAIMとして登録を行うと、いつでもそのイメージファイルからインスタンス(サーバー)が起動できるようになります。
当然S3に保管しておくのに料金がかかりますが、月$0.15/GBなので、圧縮したイメージファイルが一つ500Mくらいですから、毎月$0.05(5円)程度ととても経済的です。
(実際、毎月のクレジットの明細にきっちり$0.05が請求されています。請求の手間の方がかかるような気が)
【参考】
RightScaleがCentOSのイメージを公開しているので、それでも問題ない場合はそれを利用した方が楽です。
ami-1363877a rightscale_images/CentOS5_2V4_0_2_Beta.manifest.xml
大まかな流れは
- 空のimgファイルにyumを使ってOSをインストールし、AMI用に各種設定を行う
- S3にアップロードする前にimgファイルを分割してマニフェスト(xmlの設定ファイル)を作る
- 分割したimgファイルとマニフェストをS3にアップロードする
- アップロードしたimgを自分のAMIとしてEC2に登録する
参考にしたサイト
とてもよくまとまっています。
ここを参考に作業を進めていけば、かなりスムーズにいきます。
なので、ここでは環境の問題などで詰まった部分や補足を説明します。
AMI tools は ruby が必要
EC2用のコマンドツール群はEC2のインスタンスを立ち上げたり、情報を取得したり、操作をしたりするec2-api-toolsと今回利用するAMIを作成したり、アップロードしたりするec2-ami-toolsがあります。
後者はrubyが必須で、前者はJava VMが必須です。
yum で 作ったイメージに CentOS 5 をインストールする
ここでyumのgroupinstallオプションでインストールをするわけですが、最初CentOS4.6上で作業した時にはここで躓きました。yumのバージョンが全然違うので、当たり前っていえば当たり前です。
CentOS5のイメージを作成する際に利用する作業マシンのOSはyum > 3 のものを利用しましょう。
(CentOS4系にyum3系インストールするのは依存関係が半端無く、萎えますのであきらめましょう。)
アップロード
ec2-upload-bundleコマンドでアップロードします。
今回はWindows Vista上のVMWareのゲストOS(CentOS5)で作成、そのままアップロードを行いました。
が、VMWare上ではゲストOSの時刻が狂うという問題がありまして、アップロード中にサーバー(S3)の時刻とクライアントの時刻が狂っているとエラーが発生し、正常にアップロードできません。
最終的には、S3Foxを使って手作業でアップロードして、該当するbucketのACLを修正して対応しました。
ACLの設定は「za-team」ユーザーにRead権限を与えます。
以降はスムーズに行くと思います。
インスタンスを立ち上げた後
無事立ち上がった後、このイメージをベースにするため、自分で利用しやすいように環境を整えます。
いきなりhttpdやpostfixなどミドルウェアを入れにいってもいいのですが、どんなサーバーに利用しても必要となる最低限の環境を整えることが今回の目的なので、
ユーザーの作成や、sysstatのインストール、yumレポジトリの追加を行いました。
ベース環境の設定が終わったら、今度はこのインスタンスをイメージ化するため、インスタンス上にprivatekeyファイルとcertificateファイルをコピーして、
ruby、ec2-ami-toolsのインストールからS3へのアップロード、EC2への登録まで、全く同じ手順で行います。
作業の途中、「ec2-bundle-vol」コマンドがエラーで止まってしまうはずなので、
こちらを参考に、EC2カーネル用モジュールをコピーして、依存を修正します。
これでようやく汎用的なマイイメージが出来上がりです。
今後はこれにhttpdを入れればWebサーバに、PerlやPHPを入れてAPサーバーに、MySQLやPostgreSQLを入れてDBサーバーにと、ベースのインスタンスを拡張していろいろな用途のサーバーを自由に、いつでも用意できるようになります。
次回はこのインスタンスを使って、Webサーバーを立てて、CloudFrontの実用性を検証してみたいと思います。
2つになりました。
2008-08-15 01:13 | 日記 | コメントをする »WEB+DB PRESS Plusシリーズでまた面白そうな本が出てたので、一昨日アマゾンで注文しました。
まだ読んでないんですけど、理論本じゃなくて、
実践の賜物・試行錯誤の結実が書かれてると思うので、かなり楽しみです。
それが昨日の昼に届いたらしく、不在票が入っていました。
まあ、しょうがない。
で、昨日になって急遽新しい言語を覚えなくてはいけなくなり、
いろいろ調べてなかなか評価が高かった「詳解 Objective-C 2.0」を注文。
それが今日届いて、いや、届いたらしくて、不在票をみてみたら・・・
え!?確かに2つになったけど、なんで敢えてそれを・・・
「2つになっちゃったけど、いったいいつなら居るんだよ!!!」
「あの、同じものじゃないんです。わ、わかりにくくなっちゃうと思ったんで、か、書きました。」
どういう意味を込めてこれを書いたのか、まだ見ぬドライバーさんを思ってしまいました。