仮想化で社内LANを構築して、一世代前のWindowsサーバーを構築したよ2
2014年08月16日
さて、AWSの話題の続きです。
AWSの良い所はハードウェアの賞味期限が切れたハードもクラウド上に稼働させることができる点があります。
が、これには注意が必要です。
それは言われてみれば、そのとおりのアタリマエのことですが、実際にやってみるまで気づかなかったことです。
その注意とは、「自己責任」ということです。
いくら昔のハードをAWS上で再現したとはいえ、AWSがその動作を保証してくれるというわけではないのです。
先日、AWSコンサルでは最大手のサーバーワークスさんの代表の方とお話をさせていただいた時に、そりゃそうだよね、と思った次第です。
つまり、交換パーツの保守期限の経過したサーバは、AWSに展開してパーツの問題は解決するけど、システム構成や設計は古いままということです。
次々と進歩していくITの世界で、周りは変わり続けているのに、いつまでも古いままで使い続けることができるわけではなく、結局、それは延命措置ということなのです。
とはいえ、今回、社内で使用する業務システムは、うちのチームがオンプレミスで作成したものではないので、作成したベンダーさんの要求仕様に合わせて用意する必要がありました。
(これが若干ですが、古いものだったので仕方がない面がありました・・・)
一般的には、AWSでインスタンス(仮想マシン)を立ち上げる場合にはAMI(Amazon Machine Image)から希望のシステム構成を選択することからスタートします。
今回はWindows2008 Server 日本語 32bit版が必要だったのですが、AMIには存在しません。
このため、まずはこれを何処かで用意する必要がありました。
で、VMwareを使用しました。

弊社では、システム開発はESXiベースで仮想マシンを構築し、開発を行っています。新規案件の開発がスタートするたびに仮想マシンを用意して、開発を行うわけです。
InternetExplorerのバージョン別表示チェックもこの仮想マシンから行っています。
(だんだんこの方法も時代遅れになりつつありますが、現在のところ確実な開発の一つと考えています。)
ここに新たな仮想マシンを構築し、Windows2008 Server 日本語 32bit版をインストールしました。
DVDのイメージはMicrosoft社のサイトからダウンロードして、ESXiに転送し、作成した仮想マシンの起動ドライブとして設定してインストールしました。
で、初期設定は色々とVMware上で済ませます。
Administratorのパスワードもここでちゃんと設定しておきましょう。
ここで私が間抜けだったのが、リモートデスクトップの接続設定です。これを忘れていて、AWSに転送したのですが、AWSに渡しても、画面へ接続する方法がないため、単に電源スイッチが押せるだけのお地蔵さんとなってしまいました。(泣)
みなさんもここでリモートデスクトップの接続設定を忘れずに!!!
さて、作成を終えたら、VMware vSphere Clientからovfファイル(欲しいのはvmdkファイルですが)をエクスポートします。
エクスポートが終わったら、Windowsに「EC2 API Tools」を導入します。
http://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/set-up-ec2-cli-windows.html
Amazon EC2 API ToolsとはAWSのAmazon EC2をAPIで操作するためのコマンドラインツールです。
このツールは、通常はブラウザを操作して行うAmazon EC2のコントロールを端末からのコマンドラインで実行できるため、今回の用途以外にもいろんなことができます。
EC2の管理画面で右上のプルダウンメニューから、「Security Credential」を見て、下記の情報を入手して控えておいて下さい。
AWSアカウントID
アクセスキーID
シークレットアクセスキー
X509証明書
秘密鍵ファイル

※「X509証明書」「秘密鍵ファイル」はダウンロードした後、「EC2 API Tools」をセットした場所においておきましょう。
また、API ToolsはJavaにより動作しているためJavaをインストールする必要があります。
http://www.java.com/ja/download/
JAVAはインストールした後、Windowsのコントロールパネルで[システムとセキュリティ]-[システム]-[システムの詳細設定]で「環境変数」でパスを通しておきましょう。


ひと通り作成したら、接続が楽になるように、AWSへ接続するバッチファイルも作成しましょう。
start.bat
コマンドプロンプトを開き、「EC2 API Tools」をセットした場所に移動しましょう。
そして、先ほど作成したバッチファイルを叩きます。

その後に
ec2verとコマンドを打ってみましょう。
バージョンが返ってきているならば接続できたということになります。
VMwareからエクポートしたvmdkファイルを下記のコマンドでAWSへ転送します。
転送が完了すると
Amazon EC2のインスタンスに登録されています。
試しに起動して、記載のIPアドレスからリモートデスクトップ接続できるか試してみましょう。
(Firewallの設定を忘れずに)

後はこれをAMIにして前回、作成したVPCに設置します。
次回は最後の仕上げのあたりをご説明させていただきます。
んがんぐ。
一連の詳しい情報は下記を見ると詳しくのっています。
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/UploadingYourInstancesandVolumes.html

AWSの良い所はハードウェアの賞味期限が切れたハードもクラウド上に稼働させることができる点があります。
が、これには注意が必要です。
それは言われてみれば、そのとおりのアタリマエのことですが、実際にやってみるまで気づかなかったことです。
その注意とは、「自己責任」ということです。
いくら昔のハードをAWS上で再現したとはいえ、AWSがその動作を保証してくれるというわけではないのです。
先日、AWSコンサルでは最大手のサーバーワークスさんの代表の方とお話をさせていただいた時に、そりゃそうだよね、と思った次第です。
つまり、交換パーツの保守期限の経過したサーバは、AWSに展開してパーツの問題は解決するけど、システム構成や設計は古いままということです。
次々と進歩していくITの世界で、周りは変わり続けているのに、いつまでも古いままで使い続けることができるわけではなく、結局、それは延命措置ということなのです。
とはいえ、今回、社内で使用する業務システムは、うちのチームがオンプレミスで作成したものではないので、作成したベンダーさんの要求仕様に合わせて用意する必要がありました。
(これが若干ですが、古いものだったので仕方がない面がありました・・・)
一般的には、AWSでインスタンス(仮想マシン)を立ち上げる場合にはAMI(Amazon Machine Image)から希望のシステム構成を選択することからスタートします。
今回はWindows2008 Server 日本語 32bit版が必要だったのですが、AMIには存在しません。
このため、まずはこれを何処かで用意する必要がありました。
で、VMwareを使用しました。

弊社では、システム開発はESXiベースで仮想マシンを構築し、開発を行っています。新規案件の開発がスタートするたびに仮想マシンを用意して、開発を行うわけです。
InternetExplorerのバージョン別表示チェックもこの仮想マシンから行っています。
(だんだんこの方法も時代遅れになりつつありますが、現在のところ確実な開発の一つと考えています。)
ここに新たな仮想マシンを構築し、Windows2008 Server 日本語 32bit版をインストールしました。
DVDのイメージはMicrosoft社のサイトからダウンロードして、ESXiに転送し、作成した仮想マシンの起動ドライブとして設定してインストールしました。
で、初期設定は色々とVMware上で済ませます。
Administratorのパスワードもここでちゃんと設定しておきましょう。
ここで私が間抜けだったのが、リモートデスクトップの接続設定です。これを忘れていて、AWSに転送したのですが、AWSに渡しても、画面へ接続する方法がないため、単に電源スイッチが押せるだけのお地蔵さんとなってしまいました。(泣)
みなさんもここでリモートデスクトップの接続設定を忘れずに!!!
さて、作成を終えたら、VMware vSphere Clientからovfファイル(欲しいのはvmdkファイルですが)をエクスポートします。
エクスポートが終わったら、Windowsに「EC2 API Tools」を導入します。
http://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/set-up-ec2-cli-windows.html
Amazon EC2 API ToolsとはAWSのAmazon EC2をAPIで操作するためのコマンドラインツールです。
このツールは、通常はブラウザを操作して行うAmazon EC2のコントロールを端末からのコマンドラインで実行できるため、今回の用途以外にもいろんなことができます。
EC2の管理画面で右上のプルダウンメニューから、「Security Credential」を見て、下記の情報を入手して控えておいて下さい。
AWSアカウントID
アクセスキーID
シークレットアクセスキー
X509証明書
秘密鍵ファイル

※「X509証明書」「秘密鍵ファイル」はダウンロードした後、「EC2 API Tools」をセットした場所においておきましょう。
また、API ToolsはJavaにより動作しているためJavaをインストールする必要があります。
http://www.java.com/ja/download/
JAVAはインストールした後、Windowsのコントロールパネルで[システムとセキュリティ]-[システム]-[システムの詳細設定]で「環境変数」でパスを通しておきましょう。


ひと通り作成したら、接続が楽になるように、AWSへ接続するバッチファイルも作成しましょう。
start.bat
set EC2_HOME=C:\ec2-api-tools → ダウンロードしたコマンドラインツールの置き場所
set PATH=C:\ec2-api-tools\bin → ダウンロードしたコマンドラインツールの実行ファイルの置き場所
set AWS_ACCESS_KEY=アクセスキーID
set AWS_SECRET_KEY=シークレットアクセスキー
set EC2_URL=https://ec2.ap-northeast-1.amazonaws.com → アクセスしたいリージョンの場所
set EC2_PRIVATE_KEY=%EC2_HOME%「X509証明書ファイル」
set EC2_CERT=%EC2_HOME%「秘密鍵ファイル」
コマンドプロンプトを開き、「EC2 API Tools」をセットした場所に移動しましょう。
そして、先ほど作成したバッチファイルを叩きます。

その後に
ec2verとコマンドを打ってみましょう。
バージョンが返ってきているならば接続できたということになります。
VMwareからエクポートしたvmdkファイルを下記のコマンドでAWSへ転送します。
ec2-import-instance -t m1.medium C:\ec2-api-tools\windows2008server_32bit\windows2008server_32bit-disk1.vmdk -f VMDK -a i386 -p Windows -b 設定したS3バケット -o AWS_ACCESS_KEY -w AWS_SECRET_KEY
転送が完了すると
Amazon EC2のインスタンスに登録されています。
試しに起動して、記載のIPアドレスからリモートデスクトップ接続できるか試してみましょう。
(Firewallの設定を忘れずに)

後はこれをAMIにして前回、作成したVPCに設置します。
次回は最後の仕上げのあたりをご説明させていただきます。
んがんぐ。
一連の詳しい情報は下記を見ると詳しくのっています。
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/UploadingYourInstancesandVolumes.html

小ネタ
今の時代、出会いはwebで!続きもwebで!静岡在住の人に送るマッチングサービス4選
エンジニアvsデザイナーメモ比較!良いメモを取るコツとは?
「アタリショック」とその復活
仮想化で社内LANを構築して、一世代前のWindowsサーバーを構築したよ1
秒速で稼ぐ人、それに続く人、プログラマー
今の時代、出会いはwebで!続きもwebで!静岡在住の人に送るマッチングサービス4選
エンジニアvsデザイナーメモ比較!良いメモを取るコツとは?
「アタリショック」とその復活
仮想化で社内LANを構築して、一世代前のWindowsサーバーを構築したよ1
秒速で稼ぐ人、それに続く人、プログラマー