autoscaling_group + add_host == not possible?

Hi! Is there any way to provision hosts built by a rax_scaling_group? Is it possible to re-read dynamic inventory midway through the run - after the servers have been built - and have them ansibled? Or is the only option to have them pull after they build?

Thanks a lot!
Guy

If I understand correctly, this is what add_hosts is for. After you've
dynamically created a host you can add it to a group and then in a
subsequent play include a role that would configure that group.

Is that what you're looking for?

Right, but with an auto-scaling group I don’t know of a way to get the new hostnames of the servers the AS group creates . . . the new host are not returned in the output from the call to create the autoscaling group

Thanks,
Guy

Tower provisioning callbacks embedded into the image are a GREAT solution for this.

http://www.ansible.com/tower

Alternatively schedule a run to configure and apply policy periodically, only adding machines into the LB once configured.

Alternatively, ansible-pull

The provisioning callbacks are the cleanest option and allow ephmeral systems to request configuration as they come online, while still operating in push mode and getting full history/status/logging of activity during that configuration (as with ansible-pull this info can be lost).

Instead of baking the Tower callback script into the AMI, it also can be baked into the ASG’s Launch Config User Data. That may be a bitter easier to manage.

  • James

:frowning: I’m on Rackspace :frowning:

:wink:

Hi Guy!

I’m not an expert on this module because it’s my coworker who wrote it and not me, so I’ll try to give you as much good advice as I can. So I think the issue here is that the autoscale groups don’t return data about the servers they may create or delete. Correct me if I’m wrong in my understanding.

So, this isn’t an issue with the module per se, it’s more of an issue with the way that ASGs operate – you create ASGs and they in turn create servers, or delete them, work on load balancers, etc.

Ansible won’t know about these servers until you run the dynamic inventory script again.

There are three ways to handle this, I think:

  1. ansible-pull
  2. tower + webhooks
  3. bake-in ansible-pull into the image so that it ansible-pulls on boot

The first two methods will take advantage of cloud-init, essentially. So,

  1. For ansible-pull you’ll need to cloud-init install ansible-pull ont he machine as it comes online, and when it does, it pulls down a git repo, and “Ansibles” itself.
  2. But for Tower & Webhooks, when a server comes online, have it use a cloud-init webhook to call back to a Tower server, which would then kick of a playbook of some kind
  3. Baking in ansible-pull is really simple but requires work ahead of deployment; can’t be done afterwards via ansible in they way you desire (you could write a playbook to do this before hand, though!)

When you’re working with Autoscale, cloud-init is your new BFF. It’ll handle the stuff you’re looking to do.

There’s more documentation about cloud-init around. Here’s a started article:
https://developer.rackspace.com/blog/using-cloud-init-with-rackspace-cloud/

And this is a repo made by a Racker specifically covering getting Autoscale working with cloud-init.
https://github.com/devx/autoscale_cloudinit

Essentially, when you set up your autoscale configuration, you’ll need to pass some custom data, base64 encoded a la the webdocs:
http://docs.rackspace.com/cas/api/v1.0/autoscale-devguide/content/Manage_Launch_Configuration.html
http://docs.rackspace.com/servers/api/v2/cs-devguide/content/config_drive_ext.html

Please note that the current implementation of the rax_autoscale_group does not allow you to work with cloud-init, but I have an idea of how I might go about adding such functionality. Apologies for the inconvenience.