CUIでec2-register実行したときに発生。 なんなの。ファイルあるっつーの。 [root@domU-12-31-38-00-A1-B8:/vol] ec2-register cyberarchitect/CentOS5_0V4_0_1_weblogic_200906250227.image.manifest.xml File not found: ” 仕方ないので、ブラウザでAWS Management Console起動して、Register New AMIしたらあっさり登録できた。なんなの。 [amazon_enhanced asin=”4844329804″ /]

　 EC2のus-westリージョンでAmazon Linux AMIのインスタンスを起動すると、デフォルトではタイムゾーンがUTCになっている。タイムゾーンをJSTに変更後、cronの設定をしたのだが、設定した時間にシェルが起動されない。なぜだ？ cp /usr/share/zoneinfo/Japan /etc/localtime ・・原因は、crondを再起動してないだけだった。設定した時間にシェルが起動されないのではなく、設定した時間の9時間後に実行されるようになっていただけだった。 /etc/init.d/crond restart　で解決。 　

　 Root Device=ebsのAmazon EC2インスタンスのバックアップを実現するために、一番簡単な方法はEBSのsnapshotを取得することだ。スナップショットの取得のためにAPIも用意されており、スナップショットの取得とパージの自動化も容易に実現可能である。 [amazon_enhanced asin=”4844329804″ /] 今回は、@namikawa 氏のWebサイトの情報を参考にさせて頂いた。 Amazon EBSのスナップショット(バックアップ)を取得しつつ世代管理も行うスクリプト http://d.hatena.ne.jp/rx7/20100606/p1 US-westのAmazon Linux AMIを利用しているため、環境変数の設定は以下のようにした。 export JAVA_HOME=/usr/lib/jvm/jre export EC2_HOME=/opt/aws/apitools/ec2 export PATH=${PATH}:/bin:/usr/bin:/opt/aws/bin また、US-east以外はEC2_URLの設定をシェルに追記する必要がある。以下はus-westの場合。 EC2_URL=https://ec2.us-west-1.amazonaws.com 古いスナップショットの削除含め、うまくいった。 [amazon_enhanced asin=”4844328549″ /]

　 これまでインスタンスタイプをt1.microで運用してきたAWS上のインスタンスを、m1.smallに変更したい。 インスタンスをTerminateしてしまうとデータが消えてしまうため、バックアップを取り、そのバックアップからインスタンスを起動しなおす。 instanceのTypeを変更した時の手順をメモ。Root Deviceのタイプはebs。 １、前準備 稼働中のインスタンスイメージからAMIを作成するため、ApacheやMySQL等の稼働中のサービスを停止。 また、AWS Management ConsoleにてElastic IPをDe-associateしておく。 ２、稼働中のインスタンスイメージからAMIを作成 AWS Management ConsoleのInstancesの画面で、稼働中のインスタンスを選択し、右クリック→Create Image(EBS AMI)を実行。 AMI名等を入力し、AMIを作成。 ３、作成したAMIからインスタンスを起動 AMIsの画面で、作成したAMIを選択し、インスタンスをLaunch。この時に、インスタンスのTypeをm1.smallにする。 ４、事後処理 サービスを起動したり、Elastic IPをAssociateしたり。 昔はEBSのAMI作るのにもコマンドでいろいろ作業しないといけなかったけど、便利になったもんだ。

　 us-westのEC2環境を使い始めたのを機に、昨年末話題になっていたEC2インスタンスのEBSブートを試した。 その際、以下の各サイトを参考にさせて頂いた。 http://nxdxa.blogspot.com/2010/02/amazon-ebs-ec2.html http://blog.suz-lab.com/2010/01/migrating-centos-s3-based-ami-to-ebs.html http://coderslike.us/2009/12/07/amazon-ec2-boot-from-ebs-and-ami-conversion/ ネット上の情報を見るに、EC2インスタンスのEBSブートには、以下のようなメリットがあるようだ。 ・S3ベースのインスタンスと比較し、起動が速い。 ・インスタンス停止時に”terminate”ではなく”stop”を実行することで、ルートパーティション上のデータが消されないで済む。 ・S3ベースのインスタンスのルートパーティションの領域は、10GBが上限。一方、EBSベースの場合、1TBまで領域を拡張できる。 1つ目、2つ目のメリットについては噂通り。 インスタンスの起動時間は計測したわけではないが、速くなっている印象を受けた。 また、ルートパーティション上で変更を加えた場合（/etcの下のファイルをイジる、とか・・・）、以前ならec2-bundle-volしないといけなくてウザかったのだが、その必要はなくなった。インスタンスをterminateせず、stopしておけば、ルートパーティション上のデータは消えず、課金もされない。個人でちょくちょく使う利用者にとってはうれしい機能だ。 一方、3つ目のメリット、ルートパーティションの領域拡張については、最初若干うまくいかなかった。 参考にさせて頂いた3つめのサイトの情報を基に、インスタンス起動時にblock-device-mappingを指定してルートパーティションの領域を拡張しようとしたのだが、これがどうにもうまくいかない。ec2run -hの情報を見て色々試行錯誤したのだが、コマンドだとうまくいかない・・・なんでだろう？ C:\Amazon Web Services>ec2run ami-XXXXXXXX –block-device-mapping /dev/sda1=:50 -k xxxx -g xxxx -z us-west-1a WARNING: Ignoring extra parameter(s): [ :50 ] Invalid argument for option ‘-b, –block-device-mapping MAPPING’: ‘/dev/sda1’ (-h for usage) 結局、インスタンスはAWS Management Consoleで普通に起動させ、起動後にサーバにログインし、resize2fsしたら普通にうまくいった。 (以下はCentOSの例) [root@hogehoge ~]# df -k Filesystem.

　 Amazon EC2でus-west(N. California)にインスタンスを立てたのだが、インスタンス上でec2-describe-instancesしても、何も表示されない。 どうやら、Amazon EC2 API Toolsのデフォルトregionは、us-eastになっているようだ。 http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/index.html?setting-up-your-tools.html By default, the Amazon EC2 tools use the Eastern United States region (us-east-1) with the us-east-1.ec2.amazonaws.com service endpoint URL. This section describes how to specify a different region by changing the service endpoint URL. regionの切り替えは、環境変数で行う。EC2_URLに、管理を行いたいregionのURLを設定する。 以下は、us-west、Linux環境の例。Windowsなら、当然ながらsetにすること。 export EC2_URL=https://ec2.us-west-1.amazonaws.com URLのFQDN部分は、ec2-describe-regionsで調べられる模様。 [root@hogehoge ~]# ec2-describe-regions REGION eu-west-1 ec2.eu-west-1.amazonaws.com REGION.

　 Oracleのインスタンス用に使っているAmazon EBSのボリューム容量が手狭になってきたため、容量を増やすことにした。 ネットで軽く調べた限り、作成済みのEBSボリュームの容量を拡張することはできなさそう。 また、snapshotを作成後、以下のようにsnapshotオプションを指定して新規EBSボリュームを作成すれば、擬似的にボリュームの容量を拡張できるのではと思ったが、ボリュームの容量が増えても、OSが認識するパーティションのサイズは変わらないので、要件を満たせない。 ec2-create-volume –size 50 –snapshot snap-xxxexxxb -z us-east-1a というわけで、新しいボリュームマウントして、素直にデータコピーしましたが何か？という結果になった。 １、新しいボリュームを作成 $ ec2-create-volume –size 50 -z us-east-1a ２、新旧のボリュームをマウント $ ec2-attach-volume -d /dev/sdf -i $ ec2-attach-volume -d /dev/sdg -i ３、新しいボリュームのファイルシステムを作成 $ mkfs -t ext3 /dev/sdf ４、両方マウント $ mount /dev/sdf /opt/oracle $ mount /dev/sdg /mnt ５、古いボリュームから、データをコピー ６、Oracle起動して確認 うまくいったみたい。 　

　 ec2-bundle-volでバックアップを取得しようとすると、エラーが出て失敗する。 $ ec2-bundle-vol -d /vol -k /root/pk-hogehoge.pem -c /root/cert-hogehoge.pem -u xxxx-xxxx-xxxx –fstab /etc/fstab -r i386 Copying / into the image file /vol/image… Excluding: /sys /proc /dev/pts /proc/sys/fs/binfmt_misc /dev /media /mnt /proc /sys /vol/image /mnt/img-mnt 1+0 records in 1+0 records out 1048576 bytes (1.0 MB) copied, 0.003753 seconds, 279 MB/s mke2fs 1.39 (29-May-2006) ERROR: execution.

　 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 ..