There are only three tasks needed to create the EFS volumes; as with previous roles, we can use the ansible-galaxy command to create the folder and file structure:

$ ansible-galaxy init roles/efs

Before we add the tasks, we need to add some default variables and a template, so add the following to roles/efs/defaults/main.yml:

efs:
  wait: "yes"
  wait_time: "1200"

Now, create a file in roles/efs/templates called targets.j2, which should contain:

---

efs_targets:
{% for item in subnet_efs_ids %}
      - subnet_id: "{{ item }}"
        security_groups: [ "{{ sg_efs.group_id }}" ]
{% endfor %}

As you can see, this template is looping over the subnet_efs_ids variable to create a list of subnet IDs and security groups under the variable name efs_targets; we will find out why this is needed shortly.

The first task in roles/efs/tasks/main.yml uses the template module to read the previous file to create a file and store it in the group_vars folder, and the second task loads the contents of the file using the include_vars module:

- name: generate the efs targets file
  template:
    src: "targets.j2"

    dest: "group_vars/generated_efs_targets.yml"

- name: load the efs targets
  include_vars: "group_vars/generated_efs_targets.yml"

Now that we have the efs_targets variable populated and loaded, we can add the third and final task; this task uses the efs module to create the volume:

- name: create the efs volume
  efs:
    region: "{{ ec2_region }}"
    state: present
    name: "{{ environment_name }}-efs"
    tags:
        Name: "{{ environment_name }}-efs"
        Environment: "{{ environment_name }}"
    targets: "{{ efs_targets }}"
    wait: "{{ efs.wait }}"
    wait_timeout: "{{ efs.wait_time }}"

"So, why go to the effort of creating a template, generating a file, and then loading the contents in when you could use with_items?" you may be asking yourself.

If we were to use with_items, then our task would look like the following:

- name: create the efs volume
  efs:
    region: "{{ ec2_region }}"
    state: present
    name: "{{ environment_name }}-efs"
    tags:
        Name: "{{ environment_name }}-efs"
        Environment: "{{ environment_name }}"
    targets:
      - subnet_id: "{{ item }}"
        security_groups: [ "{{ sg_efs.group_id }}" ]
    wait: "{{ efs.wait }}"
    wait_timeout: "{{ efs.wait_time }}"
  with_items: "{{ subnet_efs_ids }}"

This, at first glance, looks like it should work; however, if we take a look at an example of what group_vars/generated_efs_targets.yml looks like once it is has been generated, you may notice one important difference:

efs_targets:
      - subnet_id: "subnet-0ce64b6a"
        security_groups: [ "sg-695f8b14" ]
      - subnet_id: "subnet-2598747f"
        security_groups: [ "sg-695f8b14" ]
      - subnet_id: "subnet-ee3487a6"
        security_groups: [ "sg-695f8b14" ]

As you can see from the example, we have three sections, each with the subnet_id unique to an availability zone. If we were to use with_items, we would only have one section and the task would be executed three times, each time overwriting the previous targets. Sure, we could have hardcoded three targets, but then what if we decided to reuse the role in a region that only has two availability zones, or one that has four? Hardcoding would mean we would lose the flexibility to have Ansible dynamically adapt to situations where there is a range of dynamic results depending on what is being targeted.

Now we have our EFS role complete and the basics finished. Before we start to launch EC2 instances, we can look at testing our playbook.