Updating the launch configuration on EC2

[Arangel_Angov]

Hi,

I've been playing with EC2 autoscaling for a while and my goal is to
start an instance update it and then save it to an AMI or use the
instance AMI id in a launch configuration tied to an auto scaling group
so that I have my instance up to date all the time and ready for scaling.

So I wanted to update the launch configuration using ec2_lc so that I
either use the newly generated AMI image or the image_id of the running
instance. The first doesn't work cause if I want to update the lc I
actually need to delete both autoscaling group and lc (and this is not
acceptable cause I have production instances running in the auto scaling
group, so deleting it will terminate those instances). The second
approach doesn't really work also cause I guess the ec2_lc module
doesn't support updating the lc or using the instance_id of my updated
instance in the lc, which is something that ec2 supports
(http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/create-lc-with-instanceID.html).

I could use the ec2 tools inside ansible but just wanted to see if
anyone had this issue before and how you solved it - without using Tower
of course.

Thanks.

-Arangel

[Scott_Anderson]

Basically you just need to create a new launch configuration and then update it in the autoscaling group. Any new instances created in the autoscaling group will then use the new launch configuration.

Regards,
-scott

[Arangel_Angov]

Thanks for the suggestion, that's what I ended up doing.

Now to figure out how to delete all my old launch configurations.

-Arangel

(attachments)

[Scott_Anderson]

Here’s my cleanup script and the relevant part of a module I use to do this.

If there’s interest I can PR the module.

def delete_launch_configs(asg_connection, ec2_connection, module):
changed = False

launch_configs = asg_connection.get_all_launch_configurations()

Delete all launch configurations that no longer have an attendant AMI

for config in launch_configs:
image_id = config.image_id
images = ec2_connection.get_all_images(image_ids=[image_id])

if not images:
config.delete()
changed = True

tasks:

• name: Obtain list of existing backup AMIs
  local_action:
  module: ec2_ami_facts
  description: “{{ ami_image_name }}-backup”
  tags:
  environment: “{{ app_environment }}”
  sorts:

• “-name”
  region: “{{ vpc_region }}”
  aws_access_key: “{{ aws_access_key }}”
  aws_secret_key: “{{ aws_secret_key }}”
  register: ami_facts
  ignore_errors: yes

• name: Remove all but the most recent backup AMI
  local_action:
  module: ec2_ami
  image_id: “{{ item.id }}”
  state: absent
  delete_snapshot: yes
  region: “{{ vpc_region }}”
  aws_access_key: “{{ aws_access_key }}”
  aws_secret_key: “{{ aws_secret_key }}”
  with_items: ami_facts.images[1:]

• name: Remove all launch configurations whose AMIs no longer exist
  local_action:
  module: ec2_lc_cleanup
  region: “{{ vpc_region }}”
  aws_access_key: “{{ aws_access_key }}”
  aws_secret_key: “{{ aws_secret_key }}”

ec2_ami_facts is used to enumerate the AMIs that I want to delete. It’s in a PR somewhere but was turned down for inclusion in core.

Regards,
-scott

[willthames]

I don’t think you need a custom launch config cleanup module - but I understand you do need a way to tell it what launchconfigs to cleanup

ec2_lc already has state=delete
https://github.com/ansible/ansible/blob/devel/library/cloud/ec2_lc#L225

then it’s just a matter of determining the names of the launchconfigs that need deleting.

Will

[Scott_Anderson]

That’s the rub… the “just a matter of” is the piece that the custom module does.

-scott

[willthames]

True, but a custom module that deletes launch configs without images seems less clean than a custom module that returns launch config facts that you could then iterate over:

• local_action:
  module: ec2_lc_facts
  … credentials
  register: launch_configs

• local_action:
  module: ec2_lc
  name: “{{item.name}}”
  … credentials
  state: absent
  with_items: launch_configs
  when: item.image != ami_facts.images[0]

I’d favour adding a list state to ec2_lc rather than a custom ec2_lc_facts module (and similarly for ec2_ami), but you’re right, similar implementations have not made it through the pull review process. (Although ec2_vol and rds have similar capability)