AWS Load Balancer Use Case

[Kapil Thangavelu]

Excerpts from Clint Byrum's message of Thu Oct 20 12:22:51 -0400 2011:
> Excerpts from Luis Arias's message of Thu Oct 20 07:57:24 -0700 2011:
> > Hi,
> > 
> > I have been learning about juju by writing a charm for our
> > "maintenance site" service.  When doing an upgrade to our site
> > requires downtime, we have a manual procedure which consists in doing
> > starting up a maintenance site instance, adding it to the load
> > balancer, then cleanly shutting down each production instance and
> > removing it from the load balancer.  A similar procedure allows us to
> > take the maintenance site instance down and add newly updated
> > production instances to the load balancer.  I was wondering what your
> > advice would be as to how such a procedure could fit in the juju
> > service orchestration model, in particular as regards adding and
> > removing instances from the load balancer.
> 
> With the current haproxy charm, it would be fairly simple.
> 
> I'd assume you'd build your environment something like this
> 
> juju deploy myapp
> juju add-unit myapp ... (as many as you need)
> juju deploy haproxy
> juju add-relation myapp haproxy
> 
> And then attach elastic IPs to the haproxy node(s) and you're load balancing
> your app.
> 
> To put up a maintenance site:
> 
> juju deploy maintenance-app
> juju remove-relation haproxy myapp
> juju add-relation haproxy maintenance-app
> 
> Then do your work on your site backend, and then
> 
> juju remove-relation maintenance-app
> juju add-relation myapp
> 
> The haproxy charm could probably use some refactoring (its about the third
> charm I ever wrote, maybe the 5th charm ever published. ;) so that these
> were safer operations (relating two things to haproxy at once results
> in a race condition)

Just adding a few minors.

hooks are execute serially on a unit, so there is no race on haproxy with 
concurrent changes.

> 
> But anyway, thats how I would do it.
> 
> To address how to relate to ELB/RDS, we need something like a virtual
> charm which runs its hooks somewhere, but doesn't actually take up
> resources in the juju environment itself, and can return different values
> for private-address and public-address when related to. That would be
> useful for not only AWS things like ELB and RDS, but also for things
> like domain registrar DNS services and other business units within the
> same organization.
> 
> I think this may be a duplicate but I opened this bug because I know
> we've been talking about the concept for a while but haven't actually
> done anything about the concept:
> 
> https://bugs.launchpad.net/juju/+bug/878948
> 

As i see it, ELB is effective just another charm without a service backing it, 
the hooks for it directly interact with ELB via the aws api, and its service 
config takes aws credentials.

cheers,

Kapil