AWS t1.micro（または他の）リザーブドインスタンス上のJuju
AWSでインスタンスを実行する最もスマートな（多くの場合）方法は、「予約済み」インスタンスを1〜3年間購入することです。
ここでの目標は、WordPressチャームをt1.microインスタンスで推奨のデフォルト設定（メモリ用に4または5インスタンス）で実行することです。予約済みインスタンスを使用するのが最も理にかなっています。私の費用ができる限り低いことを確認するため。
今、私には2つの問題があります：
juju 0.7（私はGoバージョンをテストしていません）はt1.microインスタンスが好きではなく、AWSがインスタンス化した後、それらとの接続を失うようです。他にも同じことを報告している人がいます。
いくつかのインスタンスを事前に予約している場合、これらをjujuの設定に「ハードコード」して、「ランダム」ではなく環境で使用されるようにするにはどうすればよいですか？
これでコードをクラックできる場合は、私はオフで実行しています!!
t1.microsは、特にJuju .7の場合、ノードにzookeeperが必要であり、Javaなど）になるため、あまりパフォーマンスが良くありません。これにより、t1.microsではほとんど使用できなくなります。そしてあなたが問題を抱えている理由です。
良いニュースは、Juju 2.xではコンテナに取り組んでいるため、JujuがインスタンスのLXCコンテナ内にデプロイされるということです。これの素晴らしいボーナスは、同じインスタンスで複数のチャーム/サービスを実行できるようになることです。
つまり、すべてを実行する61ドルの小さなインスタンスを1つだけ予約することになります。その上、Juju 2.xのオーバーヘッドは.7よりもはるかに低くなっています。これは、帯域幅を考慮せずに月額約5ドルに達します。
欠点は、この機能の準備が整っていないことですが、逆に、チーム全体がこの機能に取り組んでおり、来月かそこらにリリースされる予定です。
これはおそらく現在の問題の解決策ではありませんが、もう少し待っていただければ、さらに長くなります。
以下は、フォローアップするべきものです。