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

--
*Disclaimer*

This email is really important (well, most of them are.). Also, hopefully
the message has been sent to the person it’s intended for. If we stuffed up
by entering the wrong email address, we’re very sorry for cluttering up
your inbox. But if we have done that, then please do us a favour and let us
know…and if you could keep the juicy bits to yourself, that would be great
too.

Also…stuff that’s said in this message are the views of the person writing
the email and do not actually represent the views of Gramble World
(although they might, but we’re just hedging our bets here). Don’t think
for one minute that anything in this message should be construed as
creating a contract.

Gramble World owns the email infrastructure, including the contents.

Finally…do the right thing by the environment and “think before you ink”!

**********************************************************************

[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

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/1b5356d1-3ed7-4418-b2d7-051644b2942d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Arangel Angov

Systems Operations

M: +31 61 77 48 210

         

Disclaimer

[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

<get_social.png>

<http___s2.gramble.com_images_icons_email_social-media-icons_Gramble_32x3....png>  <http___s2.gramble.com_images_icons_email_social-media-icons_twitter_32X3....png>  <http___s2.gramble.com_images_icons_email_social-media-icons_facebook_32x....png>  <social-media-icons_linkedin_32x32.png>  <http___s2.gramble.com_images_icons_email_social-media-icons_instagram_32....png>  <http___s2.gramble.com_images_icons_email_social-media-icons_googleplus_3....png>

Disclaimer

This email is really important (well, most of them are.). Also, hopefully the message has been sent to the person it’s intended for. If we stuffed up by entering the wrong email address, we’re very sorry for cluttering up your inbox. But if we have done that, then please do us a favour and let us know…and if you could keep the juicy bits to yourself, that would be great too.

Also…stuff that’s said in this message are the views of the person writing the email and do not actually represent the views of Gramble World (although they might, but we’re just hedging our bets here). Don’t think for one minute that anything in this message should be construed as creating a contract.

Gramble World owns the email infrastructure, including the contents.

Finally…do the right thing by the environment and “think before you ink”!

**********************************************************************

--
You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/tZhIGnomN_g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ansible-proje...@googlegroups.com.

To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/540071A8.9090301%40gramble.com.

[Will Thames]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/8afd0618-d774-4c39-ae87-477216dc2352%40googlegroups.com.

[Will Thames]

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)