Ansible 2.0 & AWS Part 2: What You Need to Know

In our last article, we took a look at how marrying Ansible and AWS makes a great deal of sense for DevOps enterprises and discussed eight specific ways Ansible helps create greater efficiency and effectiveness for AWS deployments. Today we will dive into the recently refactored Ansible to discuss its newest features and how they can further help bolster your AWS efforts. In addition, Ansible likes to bill itself as “batteries included”. As a result, we will also review the new “batteries” or modules that are available with the release of Ansible 2.0.

In the process of developing Ansible 2.0, the team reports that it took a step back and looked at what it really wanted to achieve. In addition to the new features here, Ansible maintained backward compatibility with existing playbooks and in the process created a much cleaner architecture that has allowed Ansible to double-down on its simple, lightweight approach.

Blocks

First up are blocks which introduce the ability to handle errors in a way similar to exceptions in most programming languages. This eases development of playbooks and tasks, where task failures can be caught and dealt with in a single playbook much more simply than before. Blocks also allow users to group related tasks together using tags and conditionals, as well as many other task attributes (become settings, delegation, etc.).

Execution Strategy Plugins

Ansible 2.0 also rolls out a new execution strategy. Developers are able to combine the traditional linear strategy of waiting for a host to complete all tasks with a new free strategy of running through task lists as fast as possible. The strategies exist as a playbook-level setting and essentially act as plug-ins.

Dynamic Include Statements

Another noteworthy feature in Ansible 2.0 includes a dynamic “Include+” action for task evaluation. In 1.9.x and before, Ansible includes function simply as a pre-processor macro, in which tasks were expanded before any task execution starts. Now, in 2.0 and beyond, includes are executed as any other task is and expanded only at the point it is executed.

New AWS Modules

As I mentioned earlier, Ansible comes with the batteries included in the form of modules that support a variety of tasks. With regard to managing DevOps in the cloud, I think you’ll be particularly interested in the fact that Ansible introduced 30 new modules specifically designed to expand support for AWS:

New Options in existing AWS modules

In addition to the 30 new AWS modules, Ansible has historically shipped with many modules for controlling and configuring a wide variety of AWS services. Following we include a list of AWS modules that saw new options added to them with the release of Ansible 2.0, further expanding your ability to control your AWS infrastructure from development, operations and security perspectives.

With so many services and raw compute power available, AWS gives organizations the power to create a DevOps enterprise that delivers all the benefits we’ve come to expect. Yet, like a kindergartener with too many crayons in the box, we can quickly become overwhelmed and end up with a picture that barely resembles the ideal image we once had. Ansible’s easy to use and lightweight engine helps IT automate its way to an ideal DevOps posture through its new features and greatly expanded AWS module offerings. Are you still looking for advice on how to draw the perfect DevOps picture for your enterprise? Please contact us today and we’ll walk you through our equally easy assessment process.

—-

Glossary of Updated AWS Modules 

ec2 – create, terminate, start or stop an instance in ec2

1. network_interfaces: A list of existing network interfaces to attach to the instance at launch. When specifying existing network interfaces, none of the assign_public_ip, private_ip, vpc_subnet_id, group, or group_id parameters may be used. aliases: network_interface
2. spot_type: Type of spot request; one of “one-time” or “persistent”. Defaults to “one-time” if not supplied.
3. spot_launch_group: Launch group for spot request
4. termination_protection: Enable or Disable the Termination Protection

ec2_ami – create or destroy an image in ec2

1. device_mapping: An optional list of device hashes/dictionaries with custom configurations (same block-device-mapping parameters)Valid properties include: device_name, volume_type, size (in GB), delete_on_termination (boolean), no_device (boolean), snapshot_id, iops (for io1 volume_type)
2. launch_permissions: Users and groups that should be able to launch the ami. Expects dictionary with a key of user_ids and/or group_names. user_ids should be a list of account ids. group_name should be a list of groups, “all” is the only acceptable value currently.
3. tags: a hash/dictionary of tags to add to the new image; ‘{“key”:”value”}’ and ‘{“key”:”value”,”key”:”value”}’

ec2_asg – Create or delete AWS Autoscaling Groups

1. default_cooldown: The number of seconds after a scaling activity completes before another can begin.
2. termination_policies: An ordered list of criteria used for selecting instances to be removed from the Auto Scaling group when reducing capacity.For ‘Default’, when used to create a new autoscaling group, the “Default” value is used. When used to change an existent autoscaling group, the current termination policies are mantained

ec2_eip – associate an EC2 elastic IP with an instance.

1. device_id: The id of the device for the EIP. Can be an EC2 Instance id or Elastic Network Interface (ENI) id. aliases: instance_id
2. release_on_disassociation: whether or not to automatically release the EIP when it is disassociated

ec2_elb_lb – Creates or destroys Amazon ELB.

1. access_logs: An associative array of access logs configuration settings (see example)
2. idle_timeout: ELB connections from clients and to servers are timed out after this amount of time
3. instance_ids: List of instance ids to attach to this ELB
4. purge_instance_ids: Purge existing instance ids on ELB that are not found in instance_ids
5. security_group_names: A list of security group names to apply to the elb
6. stickiness: An associative array of stickness policy settings. Policy will be applied to all listeners ( see example )
7. wait: When specified, Ansible will check the status of the load balancer to ensure it has been successfully removed from AWS.

ec2_lc – Create or delete AWS Autoscaling Launch Configurations

1. classic_link_vpc_id: Id of ClassicLink enabled VPC
2. classic_link_vpc_security_groups: A list of security group id’s with which to associate the ClassicLink VPC instances.

ec2_snapshot – creates a snapshot from an existing volume

1. last_snapshot_min_age: If the volume’s most recent snapshot has started less than `last_snapshot_min_age’ minutes ago, a new snapshot will not be created.

elasticache – Manage cache clusters in Amazon Elasticache.

1. cache_parameter_group: The name of the cache parameter group to associate with this cache cluster. If this argument is omitted, the default cache parameter group for the specified engine will be used. aliases: parameter_group
2. cache_subnet_group: The subnet group name to associate with. Only use if inside a vpc. Required if inside a vpc

rds – create, delete, or modify an Amazon RDS instance

1. force_failover: Used only when command=reboot. If enabled, the reboot is done using a MultiAZ failover.

route53 – add or delete entries in Amazons Route53 DNS service

1. alias_evaluate_target_health: Whether or not to evaluate an alias target health. Useful for aliases to Elastic Load Balancers.
2. failover: Failover resource record sets only. Whether this is the primary or secondary resource record set.
3. health_check: Health check to associate with this record
4. hosted_zone_id: The Hosted Zone ID of the DNS zone to modify
5. identifier: Weighted and latency-based resource record sets only. An identifier that differentiates among multiple resource record sets that have the same combination of DNS name and type.
6. region: Latency-based resource record sets only Among resource record sets that have the same combination of DNS name and type, a value that determines which region this should be associated with for the latency-based routing
7. vpc_id: When used in conjunction with private_zone: true, this will only modify records in the private hosted zone attached to this VPC.This allows you to have multiple private hosted zones, all with the same name, attached to different VPCs.
8. wait: Wait until the changes have been replicated to all Amazon Route 53 DNS servers.
9. wait_timeout: How long to wait for the changes to be replicated, in seconds.
10. weight: Weighted resource record sets only. Among resource record sets that have the same combination of DNS name and type, a value that determines what portion of traffic for the current resource record set is routed to the associated location.

s3 – manage objects in S3.

1. encrypt: When set for PUT mode, asks for server-side encryption
2. headers: Custom headers for PUT operation, as a dictionary of ‘key=value’ and ‘key=value,key=value’.
3. marker: Specifies the key to start with when using list mode. Object keys are returned in alphabetical order, starting with key after the marker in order.
4. max_keys: Max number of results to return in list mode, set this if you want to retrieve fewer than the default 1000 keys.
5. permission: This option let’s the user set the canned permissions on the object/bucket that are created. The permissions that can be set are ‘private’, ‘public-read’, ‘public-read-write’, ‘authenticated-read’. Multiple permissions can be specified as a list.
6. prefix: Limits the response to keys that begin with the specified prefix for list mode
7. retries: On recoverable failure, how many times to retry before actually failing.
8. version: Version ID of the object inside the bucket. Can be used to get a specific version of a file if versioning is enabled in the target bucket.

Did you find this useful? 

Interested in getting tips, best practices and commentary delivered regularly? Click the button below to sign up for our blog and set your topic and frequency preferences.