私は、私たちのアプリケーションのデモバージョンを実行するために(EBSでサポートされた)AMIをカスタマイズしました。 (AMIには、アプリ自体にTomcatとMySQLがセットアップされたUbuntu 11.04と、デモをワンクリックで簡単に更新できるJenkinsが含まれています)。
これは32ビットAMIです。つまり、次の インスタンスタイプオプション があります。
C1.mediumが提供できるよりも、デモサーバーのパフォーマンスを向上させたいことに気づきました。 (具体的には、「I/Oパフォーマンス:中程度」がボトルネックになる可能性があると思いますが、すべてにEBSを使用していることを考えると、それを改善することが役立つかどうかはわかりません。)
とにかく、より強力なインスタンスタイプ(「m1.large」や「c1.xlarge」など)を使用するには、64ビットのAMIが必要です。
これを行う1つの方法は、クリーンな64ビットから新しいインスタンスを作成することです buntu AMI 次に、そこでシステムを再セットアップし、最後にそれを新しいAMIとして保存します。現在の設定でボリュームをマウントしてから、cp -a
新しいインスタンスのルートディスクにいくつかのものがあります。これは多少役に立ちます。しかし、それでも、このアプローチはやや面倒で時間がかかる可能性があります。
だから、私の質問は、32ビットAMIを64ビットAMIに変換するより簡単で自動化された方法はありますか?
いいえ、自動化された方法はありません。 Ubuntuプレーンのものから始めて新しいAMIを作成する必要があります。
Unbuntuインストールを変換することは可能ですが、それは本当に面倒です。新鮮なAMIを作成するのが最善です。
ベストプラクティス:
AMIを構築する(またはインスタンスをセットアップする)ときはいつでも、ソフトウェアをインストールおよび構成するために実行した正確な手順と、ソフトウェアに配置するデータと場所を常に文書化してください。これには、同じAMIを異なるアーキテクチャに簡単に再構築できるなど多くの利点があります。
さらに良いことに、AMIの構築を自動化できるように、インストール、構成の手順のほとんどまたはすべてをスクリプト化することをお勧めします。これにより、セットアップの微調整と新しいバージョンのテストが簡単になります。
プライベートGitリポジトリサーバー用にGitとgitoliteをインストールしてUbuntuAMIを構築する方法のサンプルを次に示します。
https://github.com/alestic/alestic-git/blob/master/bin/alestic-git-build-AMI
上記の最初の推奨事項は、通常ルートボリュームに配置されるソフトウェアをセットアップすることです。データは、AMIの実行後にインスタンスに接続する個別のEBSボリュームに配置する必要があります。これには、新しいAMIの実行に切り替えたい場合など、インスタンス間でデータを移動する機能など、多くの利点があります。また、データボリュームのコピーを作成して、開発インスタンスに添付することもできます。
このアドバイスは手遅れだと思うかもしれませんが、別のAMIを構築しようとしているので...
私が信じている新しいAMIから始める必要がありますが、dpkgを使用して古いイメージにパッケージリストを生成できます。
dpkg --get-selections | awk '{print $1}' > pkgs.old
次に、これを新しいイメージで使用して、インストールする必要のあるパッケージを特定します。
dpkg --get-selections | awk '{print $1}' | fgrep -v -f - pkgs.old
次に、おそらく/ etcからファイルをコピーすると、ほとんどの方法でそこに到達するはずです。
そして、スクリプトを作成するための+1(これらを1回または2回設定することはほとんどありません)は、通常、何度も行われます。これらすべてを自動化してソース管理することが重要です。
ブループリントを使用して32ビットAMIをリバースエンジニアリングしてみてください。
https://github.com/devstructure/blueprint
出力をbashスクリプトとして保存し、64ビットバージョンを起動するときにユーザーデータフックを使用します。