4

The smartest (often) way to run instances on AWS is to buy "reserved" instances - for either one or three years.

My goal here is to run the WordPress charm on t1.micro instances as per the default setup recommended (4 or 5 instances, for memory). It would make the most sense to use reserved instances, to ensure my costs are the lowest they can be.

Now, I have two issues:

  1. juju 0.7 (I've not tested the Go version) doesn't like t1.micro instances and appears to lose contact with them after AWS instantiates them. There are others reporting the same thing.

  2. If I've pre-reserved a number of instances, how do I "hard-code" these into juju's settings to ensure they are used in the environment, rather than "randoms"?

If I can crack the code on this, then I'm off and running!!

1 Answer 1

3

t1.micros are really not very performant, especially with Juju .7 as it needs zookeeper on the node and that brings in Java and so on. This makes it pretty much unusable on t1.micros, and is the reason you're having problems.

The good news is that for Juju 2.x we're working on containers so that Juju will deploy inside an LXC container on an instance. A nice bonus of this is that we'll finally have the ability to run more than one charm/service on the same instance.

That means that you'd reserve just one small instance for $61 that would run everything. On top of that Juju 2.x has a much lower overhead than .7. This works out to ~$5 a month, not counting bandwidth, that's not a bad deal!

The downside is that this feature is not ready, but the flipside is that there's an entire team working on this feature right now and it's due to land over the next month or so.

This is probably not a solution to your current problem, but if you could wait just a little while longer we're getting there.

Here's some things to follow up on:

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .