Video summary

Day-06 | Create Resources on AWS using Ansible | Ansible Variables Demo | Ansible Vault Demo

Main summary

Key takeaways

Technology

What the video episode covers (Ansible + AWS provisioning)

  • Episode context: Episode 6 in a “Ansible Zero to Hero” 14-episode series. Earlier episodes covered Ansible basics, ad-hoc commands, inventory, first playbook (YAML basics), roles, and using pre-built roles from Ansible Galaxy (including a Docker-on-EC2 demo).
  • Main goal of this episode: Learn Ansible variables and variable precedence, using a practical walkthrough to create AWS resources (EC2 instances) via Ansible AWS collections.

1) Creating AWS resources with Ansible (collections vs built-in modules)

Previously, Ansible tasks were run by SSH-ing into EC2 (“managed nodes”) and executing built-in modules (like apt, file, shell, etc.) on the target host (since Python exists there).

For AWS/API-based automation:

  • Ansible does not SSH to AWS.
  • Using Ansible collections (e.g., amazon.aws), Ansible installs/executes the module on the control node (your laptop).
  • The collection’s module is Python code that calls AWS APIs (typically via boto3).

Key concept: - Built-in modules (e.g., apt, copy, file) typically target hosts over SSH. - Collections (AWS/Cisco/Azure/GCP/etc.) enable API-driven automation and run from the control node.

2) Prerequisites for AWS collection

To use the AWS collection:

  • Install the AWS collection via Ansible Galaxy.
  • Install boto3 on the control node, since the module needs it to call AWS APIs.

3) Example playbook/role structure for EC2 creation

The episode demonstrates an EC2 creation playbook structure:

  • Writes an EC2 creation playbook using:
    • hosts: localhost because the AWS module runs on the control node, not via SSH to EC2.
  • Uses an Ansible role created with ansible-galaxy init and places the AWS EC2 task in:
    • roles/<role>/tasks/main.yml
  • Notes that an inventory file is still considered best practice, even though execution is on localhost.

4) Securing AWS credentials using Ansible Vault

Hardcoding AWS access key and secret key in playbooks/roles is called out as a security risk (e.g., exposure via GitHub).

The demo uses Ansible Vault to store secrets:

  • Creating a vault password file (vault pass using base64 in the demo).
  • Creating a vault file containing:
    • ec2_access_key
    • ec2_secret_key
  • Referencing vault variables in templates using Jinja2 syntax:
    • {{ variable_name }}

Troubleshooting shown:

  • Running without vault secret info causes decryption failure:
    • “Attempting to decrypt but no vault secrets found”
  • Providing the vault password file allows successful decryption.
  • Demonstrates a common debugging workflow using errors (e.g., undefined variable due to naming mismatch).

5) Variables: why they matter (avoid hardcoding)

Even though the EC2 creation playbook works, many values are initially hardcoded (AMI ID, instance type, region, etc.).

  • Variables make the playbook reusable and shareable across teams/environments.
  • Uses Jinja2 patterns for applying variables (e.g., {{ type }} for instance type).

6) Ansible variable precedence (core learning outcome)

The episode shows how the same variable defined in multiple places resolves to different values.

Precedence rules emphasized in the demo

  • defaults/main.yml (role defaults) = lowest precedence
  • vars/main.yml (role vars) = higher precedence than defaults
  • -e / extra-vars from the CLI = highest precedence (overrides everything)

Demonstrations

  • When instance type is set in both:

    • defaults/main.yml and vars/main.yml with conflicting values → the resulting EC2 instance uses the higher-precedence value from vars/main.yml.

  • When overridden using CLI extra-vars:

    • -e type=... → the EC2 instance reflects the CLI-provided value.

Most common variable locations highlighted

  • Role defaults
    • Baseline values shared by others
  • Role vars
    • Higher priority; typically more fixed/internal values
  • Inventory group variables (group_vars/)
    • Different values per inventory group (e.g., app vs db passwords)
  • Extra-vars (-e / --extra-vars)
    • Strongest override, used at runtime by users/automation pipelines

The creator mentions there can be many possible places (up to ~22) to define variables, but recommends focusing on the common ones.

Reviews / guides / tutorials

This is primarily a tutorial/guide episode that covers:

  • Install and use the Ansible AWS collection
  • Use the boto3 prerequisite
  • Create EC2 via AWS API using localhost execution
  • Secure credentials via Ansible Vault
  • Use Jinja2 templating for variable substitution
  • Learn variable precedence with real EC2 instance outcomes
  • Explain role defaults vs vars vs extra-vars, and why that matters for reuse and multi-team workflows

Main speakers / sources

  • Speaker: Abhishek (host/teacher)
  • Primary sources referenced:
    • Official Ansible documentation (collections, variables, precedence)
    • Ansible Galaxy (installing the AWS collection)
    • AWS IAM / AWS EC2 (access keys/secret and EC2 instance creation)

Original video