AWSはインスタンスを起動する度にPublic IPが変わってしまい、非常にウザいので、Elastic IPを使って固定IPを割り振ることにした。Elastic IPはインスタンスのInstance IDと紐付くことになるため、Amazon EBSと同じく、インスタンスを起動するタイミング、shutdownするタイミングで紐付きを解除することにした。 参考：[TechDay] 第7回 Amazon Elastic Compute Cloud (Amazon EC2) : Elastic IP http://builder.japan.zdnet.com/member/u502383/blog/2008/11/08/entry_27017766/ １、固定IP取得 AWS Management Consoleとかで固定IPをallocateする。 ２、スクリプト準備 /rootに.ec2envを作成。自分とこの環境に合わせて適宜修正。 (2014/10/12追記) EC2_PRIVATE_KEY、EC2_CERT環境変数を使ったAWS CLIツールアクセスはできなくなるので、IAM Roleを活用しましょう。 参考：Private key authentication has been deprecated from the CLI. export JAVA_HOME=/usr/local/jre1.6.0_13 export EC2_HOME=/usr/local/ec2-api-tools-1.3-34128/ export PATH=$PATH:$EC2_HOME/bin:$JAVA_HOME/bin export EC2_PRIVATE_KEY=/root/pk-.pem export EC2_CERT=/root/cert-.pem /etc/init.dにaws_elastic_ipを作成。 #! /bin/sh # ELASTIC_IP_ADDRESS=自分とこのelastic IP ..

　 EC2でインスタンスを起動すると、Instance IDが割り振られる。Amazon EBS(Elastic Block Store)のボリュームをインスタンスにattachすると、このInstance IDとボリュームが紐付くことになる。fstabにマウント情報を書いておけば、インスタンスを再起動してもこの紐付きは維持され、再起動後も普通にマウントされる。 だが、Instance IDはインスタンスをshutdownすると変わってしまい、都度ボリュームをattachし直さないといけない。これはウザい。耐えられない。 おなじことを考えている（？）人がいた。 Possible to Auto-Attach/Mount EBS at Boot? http://developer.amazonwebservices.com/connect/thread.jspa?messageID=103331&#103331 そして、EBSのボリュームを自動でattach/detachして、マウントするためのスクリプトをPythonで書いた勇者がいた。 Scripts to automatically attach and mount an EBS Volume at Boot Time http://developer.amazonwebservices.com/connect/thread.jspa?messageID=99100 早速試してみたときのメモ。 ■インスタンスを起動して、EBSをattach AWS Management ConsoleとかでEBSのボリュームを作成しておく。今回、デバイス名はsdfとした。 今回は、Oracleが提供しているAMIを使って、インスタンスを起動した。AMI IDはami-cecb2fa7のやつを使った。 以下を参考に、EBSをattach。 Amazon EBSを活用してデータをバックアップしてみよう ～Amazon EC2/S3環境構築のすべて～ http://codezine.jp/article/detail/3546 EBSボリュームが認識されているか確認。 $ cd /dev $ ls sd* sda1 sda2 sda3 sdf.

　 （旧ブログから移行） さて、Linuxの環境もできたし、Oracleインストールするべ～。GUIがいるから、まずはXのインストールだ！ yum groupinstall “X Window System” “GNOME Desktop Environment” ・・・え？ Oracle and AWS http://www.amazon.com/gp/browse.html?node=728072011 Cloud Computing Center http://www.oracle.com/technology/tech/cloud/index.html? Amazon Machine Images(AMIs) -Oracle Database 11g Release 1 Enterprise Edition -32 Bit http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1718&categoryID=205 Oracle、クラウドコンピューティングに参戦、Amazon Web Servicesへのサポート開始 http://codezine.jp/article/detail/3063 ［ITproカンファレンス：Amazonクラウド］「AWSで1時間以内にOracle環境をクラウド上に構築できる」と日本オラクル http://itpro.nikkeibp.co.jp/article/NEWS/20090410/328218/ なん・・・だと・・・？ AWS Management Consoleで検索すると、AMIあった。 AMIをLaunch。CentOSより若干Pending時間が長い。でも5分ぐらい。 ログインしてみる １、rootでログインすると、License Agreementsが表示される。acceptすると、oracleユーザのパスワードを設定させられる。 ２、Would you like to create a database now.

　 （旧ブログから移行） AWSへのユーザ登録から、インスタンスの起動(EC2)、OSイメージの保存(S3)、ストレージのマウント(EBS)まで試してみた。Web上にAWSを解説したサイトは数多くあるが、なんだかよくわからない点が色々あり、実際に環境を作ってみて少しだけ理解できた気がした。 なんでS3とEBSって分かれてるの？両方ストレージじゃないの？ 実際に使ってみて、S3はマウントできないNASで、EBSはSANみたいなものと理解した。 EC2は、インスタンスを停止するとデータが全て消えてしまうため、システムバックアップ（と言っていいのか？）をどこかに保存しておく必要がある。EC2のサーバ側でec2-bundle-volコマンドを実行し、システムバックアップを取得し、それをネットワーク経由(HTTP？)でS3に保存する。S3に保存したシステムバックアップを元に、クライアント側でec2-registerコマンドを実行し、AMI(Amazon Machine Images)を登録することができる。AMIを元にEC2のインスタンスを起動すれば、システムバックアップを取得した時点から、システムの利用を再開できる。逆に言うと、システムバックアップを取得する前にインスタンスが落ちると、データは消えることになる。 一方、EBSに保存したデータは、EC2のインスタンスが落ちても消えない。S3はEC2のインスタンスからマウントできないが、EBSはできる。DBサーバのデータなんかはEBSにマウントした領域に保存しておき、不測の障害でインスタンスが死んだ場合も、データを残すことができる。 環境構築の時になんか色々ツールとかでてきてめんどくさいんですけど 環境構築に必要そうなツールやサイトとして、 ・Amazon EC2 API Tools(コマンドラインツール) ・S3 FireFox Organizer(FireFoxのプラグイン) ・AWS Management Console(AWS管理用のWebサイト) が存在し、機能が重複しているため、色々と混乱した。結論として、現状ではコマンドラインの操作をベースに手順を解説しているサイトが多いので、Amazon EC2 API Toolsベースで作業するのが良いだろう。AWS Management ConsoleはブラウザでAWSの管理を行えるかなりイケてるサイトなのだが、現状ではS3を操作することができず、またWeb上の解説もコマンドベースが多いので、若干混乱することになる。あと、S3上にbucket（フォルダみたいなもん）を作るためにFireFox起動するのがかなりウザかった。早く全部AWS Management Consoleでできるようになってほしい。 とはいえ、AWSおもしろい。