Advanced Ansible Playbooks: YAML Data, Special Characters, and Best Practices

In recent years, Ansible has become an essential tool for IT automation, simplifying configuration management and orchestration at scale. After covering the basics of Ansible Playbooks, it’s time to dive deeper into advanced elements that unlock Ansible’s full potential. In this article, I will explore key topics like advanced YAML data types, handling special characters for custom configurations, and best practices that enhance readability, maintainability, and consistency in your playbooks. We’ll also look at testing and validating playbooks to ensure reliability in complex environments and cover essential command-line usage.

YAML Data Types in Playbooks

Primary Data Types in Ansible
Practical Examples of Data Types in Action
Tips for Using Data Types in Ansible

Understanding Special Characters in Ansible

Common Special Characters in Ansible
Practical Examples of Special Characters in Ansible
Tips for Using Special Characters in Ansible

Common Directives, Parameters, and Modules in Ansible Playbooks

file Module
gather_facts
update_cache
delegate_to
return_content
failed_when
state
package
mode
copy Module
register
Loops and Conditionals

Testing and Validating Ansible Playbooks

Why Test and Validate Ansible Playbooks?
Techniques for Testing and Validating Playbooks
Best Practices for Testing Ansible Playbooks

Command-Line Usage for Ansible Playbooks

Running a Basic Playbook
Installing and Configuring Apache on a Remote Host

Conclusion and Best Practices

YAML Data Types in Playbooks

Data types in Ansible help define the kind of information a variable holds and how that information should be interpreted. Proper use of data types enables better organization, more readable playbooks, and greater control over tasks and configurations. By understanding and using data types, you can build flexible playbooks that adapt to various environments, making Ansible automation both efficient and reliable.

Primary Data Types in Ansible

String

Strings are the most basic data type and represent textual data. They are enclosed in quotes (`" "` or `' '`), though Ansible often accepts unquoted strings in simple cases. Strings are useful for representing text values, such as paths, names, or other configuration settings.

Example:

- name: Print a welcome message

debug:

msg: "Welcome to Ansible automation"

You can also use variable substitution in strings to make them dynamic:

- name: Show host information

debug:

msg: "Connecting to {{ inventory_hostname }}"

Number

Ansible supports numeric data types, including integers and floating-point numbers, which can be used for counting, configuration limits, or calculations. Numbers don’t require quotes and can be used directly in tasks.

Example:

- name: Set the maximum number of retries

set_fact:

max_retries: 5

Numbers can be used in conditionals and mathematical operations, enhancing playbook logic. For instance, you might use a number to set a limit or threshold for certain configurations:

- name: Configure the number of worker processes

lineinfile:

path: /etc/app/config.conf

line: "worker_processes {{ max_retries }}"

List

Lists are ordered sequences of items. They are defined using square brackets (`[ ]`) or with each item on a new line prefixed by a dash (`-`). Lists are useful for managing collections of data, such as packages to install, users to create, or hosts to target.

Example:

- name: Install multiple packages

apt:

state: present

loop:

- nginx

- python3

- git

In this example, the `loop` keyword iterates over each item in the list, installing each package in sequence. Lists can be nested, allowing you to build complex data structures.

Dictionary

Dictionaries, also known as hashes or maps, store key-value pairs, making them ideal for grouping related information. Dictionaries are enclosed in curly braces (`{ }`), and each key-value pair is separated by a colon. This data type is excellent for configuring parameters with multiple attributes, such as user details or application settings.

Example:

- name: Define user information

set_fact:

user_info:

uid: 1001

shell: /bin/bash

Dictionaries allow you to access specific values using dot notation or bracket notation. They’re particularly useful for passing structured data and organizing configurations in a readable way.

- name: Create a user with structured data

user:

uid: "{{ user_info.uid }}"

shell: "{{ user_info.shell }}"

Dictionaries can also be nested, allowing for highly detailed configurations:

users:

johndoe:

uid: 1001

groups:

- admin

- web

janedoe:

uid: 1002

groups:

- users

Boolean

Booleans represent `true` or `false` values and are essential for managing conditions in Ansible. Booleans allow you to enable or disable features, control task execution, and add branching logic to your playbooks.

Example:

- name: Install a package conditionally

apt:

state: present

when: install_nginx == true

In this example, the task only runs if the variable `install_nginx` is set to `true`. Booleans are often used with conditional statements to make playbooks adaptable to different environments or requirements.

Practical Examples of Data Types in Action

To see data types in action, here’s a practical example of using strings, lists, dictionaries, and booleans to set up users and configure a web server.

Example Playbook

- hosts: webservers

become: true

vars:

server_name: "example.com"

packages:

- nginx

- ufw

users:

- name: johndoe

uid: 1001

shell: /bin/bash

admin: true

- name: janedoe

uid: 1002

shell: /bin/bash

admin: false

firewall_enabled: true

tasks:

- name: Install required packages

apt:

state: present

loop: "{{ packages }}"

- name: Set up users

user:

uid: "{{ item.uid }}"

shell: "{{ item.shell }}"

loop: "{{ users }}"

- name: Add user to admin group if they are admin

user:

groups: sudo

append: true

when: item.admin == true

loop: "{{ users }}"

- name: Configure firewall

ufw:

rule: allow

when: firewall_enabled

Explanation

Strings: The `server_name` variable is a string representing the server’s domain.
List: `packages` is a list of required packages that will be installed by looping through each item in the list.
Dictionary: Each item in `users` is a dictionary containing user details, such as `name`, `uid`, `shell`, and `admin` status.
Boolean: `firewall_enabled` is a boolean that controls whether the firewall configuration task runs.

Tips for Using Data Types in Ansible

Choose the Right Type: Use the most appropriate data type for the information you’re managing. Lists work well for repeated items, dictionaries for structured data, and booleans for flags.
Leverage Variables: Variables make it easy to reference and reuse data types throughout your playbooks, improving flexibility and readability.
Use Defaults: Combine data types with default values to avoid undefined variables, especially when variables may differ across environments.
Nest Data for Complex Configurations: Take advantage of nested dictionaries and lists for detailed configurations, like user setups or application configurations.

Understanding Special Characters in Ansible

Ansible is a powerful automation tool that uses YAML files to define tasks, configurations, and infrastructure automation. While YAML syntax is simple, there are several special characters in Ansible that help define variables, delimit data structures, and manage control flow effectively. Understanding how to use these special characters correctly is essential for writing clean, functional, and readable playbooks. This article covers key special characters in Ansible, explaining their uses and providing examples to illustrate how each character or symbol is applied.

Common Special Characters in Ansible

Curly Braces (`{{ }}`)

Curly braces are used to denote variables in Ansible. When a variable is wrapped in `{{ }}`, it signals to Ansible to replace it with the variable's value during execution. This syntax, known as **Jinja2 templating**, allows you to dynamically inject variables into tasks, commands, and templates.

Example:

- name: Install a package

apt:

state: present

In this example, `{{ package_name }}` is replaced with the actual value of `package_name` during execution. This templating is one of Ansible’s most powerful features, making it easy to manage dynamic values.

Square Brackets (`[ ]`)

Square brackets are used to define lists in YAML syntax. Lists allow you to specify multiple values in a single variable or setting, often used for specifying packages to install, hosts, or arguments.

Example:

- name: Install multiple packages

apt:

state: present

loop:

- nginx

- git

- curl

Here, the list `[nginx, git, curl]` specifies multiple packages to install in a loop. Ansible iterates through each item in the list, applying the task to each package.

Colon (`:`)

The colon is used in YAML to separate keys and values in dictionaries or to define mappings. In Ansible, colons are fundamental for setting variables, defining task attributes, and creating key-value pairs.

Example:

package_name: nginx

In this example, `package_name` is the key, and `nginx` is its value. Colons are used throughout YAML files to define mappings, which Ansible then interprets as variable assignments, task options, and other configurations.

Hyphen (`-`)

The hyphen is used in YAML to denote list items and to define tasks within a playbook. It separates individual items in a list and defines task sequences within plays.

Example:

- hosts: webservers

tasks:

- name: Install Nginx

apt:

state: present

- name: Start Nginx

service:

state: started

In this example, each task within the `tasks` section starts with a hyphen, defining the sequence of actions to perform on the `webservers` group.

Pipe (`|`) and Greater Than (`>`)

The pipe (`|`) and greater than (`>`) symbols are used in YAML for multi-line strings. The pipe retains line breaks, while the greater-than symbol folds lines into a single line. Multi-line strings are useful for defining complex commands, script content, or long strings in Ansible playbooks.

Examples:

Using `|` to retain line breaks:

- name: Write a multi-line configuration

copy:

dest: /etc/myconfig.conf

content: |

[section1]

option1=value1

option2=value2

Using `>` to fold lines into a single line:

- name: Set an environment variable

shell: >

export MY_ENV_VAR="some long value that

is split across multiple lines for readability"

Percent Sign (`%`)

The percent sign is used within Jinja2 expressions for conditional statements, filters, and loops in templates. This allows more advanced control over dynamic content in playbooks and templates.

Example:

- name: Ensure only web servers are configured

debug:

msg: "This is a web server"

when: "{{ inventory_hostname }}" is search("web")

In this example, a Jinja2 expression checks if `inventory_hostname` contains `"web"`, allowing you to apply specific logic or formatting based on conditions.

Exclamation Mark (`!`)

The exclamation mark is used for explicit YAML tags, allowing you to specify data types, like booleans or strings. This is particularly useful when values like "yes" or "no" could be interpreted as booleans but need to be read as strings instead.

Example:

always_yes: !!str "yes"

Here, `always_yes` is interpreted as a string with the value `"yes"` instead of being evaluated as a boolean `true`.

Dot (`.`)

In Ansible, the dot is used to access attributes of dictionaries or objects. Dot notation allows you to refer to specific elements within nested structures, such as items in dictionaries or host facts.

Example:

- name: Display OS family

debug:

msg: "This system is running on {{ ansible_facts.os_family }}"

Here, `ansible_facts.os_family` accesses the `os_family` attribute within the `ansible_facts` dictionary, which provides system facts gathered by Ansible.

Double Colon (`::`)

The double colon is often used with **hashes and scopes** in complex data structures or variable namespaces. It is rarely used in basic YAML but may appear in advanced configurations, particularly in roles or when handling nested data in Ansible Galaxy roles.

Practical Examples of Special Characters in Ansible

To see these special characters in action, let’s look at a practical playbook example that uses various special characters to configure a web server.

Example Playbook

---

- hosts: webservers

become: true

vars:

nginx_conf: |

server {

listen 80;

server_name {{ inventory_hostname }};

location / {

root /var/www/html;

index index.html;

}

packages:

- nginx

- ufw

firewall_enabled: true

tasks:

- name: Install required packages

apt:

state: present

loop: "{{ packages }}"

- name: Configure Nginx

copy:

dest: /etc/nginx/sites-available/default

content: "{{ nginx_conf }}"

- name: Enable firewall

ufw:

rule: allow

when: firewall_enabled

- name: Start Nginx service

service:

state: started

Explanation of Special Characters Used

Curly Braces (`{{ }}`): Used in `nginx_conf` to dynamically insert the `inventory_hostname` variable into the server block configuration.
Pipe (`|`): Used in `nginx_conf` to preserve line breaks, creating a clean, multi-line configuration for the Nginx server block.
Square Brackets (`[ ]`): Used to define the `packages` list, specifying multiple packages to install.
Colon (`:`): Separates keys and values, such as in variable definitions and task attributes.
Hyphen (`-`): Indicates each item in the `packages` list and each task in the playbook.

Tips for Using Special Characters in Ansible

Use Curly Braces for Variables: Always wrap variables in `{{ }}` to ensure they are recognized correctly.
Indent Properly: YAML is indentation-sensitive, so ensure consistent indentation for lists and mappings.
Leverage Multi-line Strings: Use `|` or `>` for complex text blocks or configuration files to improve readability and maintain structure.
Understand List vs. Dictionary Syntax: Know when to use `-` for lists and `:` for dictionaries to avoid syntax errors.

Common Directives, Parameters, and Modules in Ansible Playbooks

file Module

The `file` module is used to manage file attributes such as permissions, ownership, and state (e.g., file, directory, or symlink).

Example:

- name: Ensure /etc/myapp exists as a directory

file:

path: /etc/myapp

state: directory

mode: '0755'

```

In this example:

- `state: directory` ensures that `/etc/myapp` is a directory.

- `mode: '0755'` sets the permissions.

gather_facts

`gather_facts` is a setting in playbooks that collects information about the target system. It is set to `true` by default, providing data about the system, such as IP address, OS type, and memory, which can be used in tasks.

Example:

- hosts: all

gather_facts: true

tasks:

- name: Display OS family

debug:

msg: "This host is running on {{ ansible_facts['os_family'] }}."

```

update_cache

The `update_cache` parameter, often used with the `apt` module, refreshes the package cache before installing packages on Debian-based systems.

Example:

- name: Install nginx and update cache

apt:

state: present

update_cache: yes

```

Here, `update_cache: yes` ensures the package cache is updated before `nginx` is installed.

delegate_to

`delegate_to` allows a task to be executed on a different host than the one defined in the playbook, useful for managing centralized operations (e.g., controlling load balancers).

Example:

- name: Check disk space on webservers

command: df -h

delegate_to: localhost

```

In this example, the `df -h` command will run on `localhost` rather than on each host in `webservers`.

return_content

The `return_content` parameter is used with the `uri` module to return the content of a web request. Setting it to `true` allows you to capture and store the response.

Example:

- name: Fetch data from a web API

uri:

url: "https://api.example.com/data"

return_content: yes

- name: Display the API response

debug:

var: api_response.content

```

Here, `return_content: yes` saves the API response content in `api_response.content`.

failed_when

`failed_when` allows you to define custom conditions for marking a task as failed, even if the command itself exits successfully.

Example:

- name: Check if a file contains specific text

shell: cat /tmp/myfile.txt

failed_when: "'ERROR' in file_output.stdout"

```

In this case, the task will fail if the word "ERROR" is found in the file content.

state

The `state` parameter is used in several modules to specify the desired state of resources. For example, in the `service` module, it controls whether a service should be started, stopped, or restarted.

Example:

- name: Ensure nginx is started

service:

state: started

```

this example, `state: started` ensures that the `nginx` service is running.

package

`package` is a general module that manages packages on various operating systems, providing a unified interface across different package managers.

Example:

- name: Install a package

package:

state: present

```

This example installs `vim`, regardless of the underlying OS.

mode

`mode` sets file or directory permissions. It’s commonly used with modules like `file` and `copy`.

Example:

- name: Set permissions on a file

file:

path: /tmp/myfile

state: touch

mode: '0644'

```

Here, `mode: '0644'` sets the permissions of `/tmp/myfile`.

copy Module

The `copy` module copies files from the control node to the remote host.

Example:

- name: Copy a configuration file

copy:

src: /path/to/myconfig.conf

dest: /etc/myapp/config.conf

mode: '0644'

```

In this example, `src` specifies the file to copy, `dest` specifies where to place it on the remote host, and `mode` sets the permissions.

register

`register` is used to store the output of a task in a variable, allowing you to reference the output in later tasks.

Example:

- name: Check for available updates

command: apt list --upgradable

- name: Display update information

debug:

var: update_output.stdout

```

Here, `register: update_output` saves the output of the `apt list --upgradable` command, which is then displayed with `debug`.

Each of these keywords and modules gives Ansible powerful functionality to manage and automate complex systems flexibly and efficiently.

Ansible offers several constructs for more complex tasks.

Loops and Conditionals

Loops repeat tasks across multiple items, while conditionals let tasks run only if specific criteria are met.

Loop Example:

tasks:

- name: Install packages

yum:

name: "{{ item }}"

state: present

loop:

- git

- curl

- vim

Explanation

`name: Install packages`: Descriptive name for the task.
`yum`: The module used to manage packages on Red Hat-based systems.
`name: "{{ item }}"`: This uses the loop variable `item` to install each package specified in the list.
`loop`: Defines a list of packages (`git`, `curl`, `vim`) to be installed, iterating over each one.

This task will install `git`, `curl`, and `vim` on the target system.

Conditional Example:

- name: Restart Apache on RedHat systems

service:

name: httpd

state: restarted

when: ansible_os_family == "RedHat"

Explanation

`name: Restart Apache on RedHat systems`: A descriptive name for the task, indicating that it’s meant for RedHat systems.
`service`: The module used to manage services.
`name: httpd`: Specifies the Apache service (`httpd` is the package name on RedHat-based systems).
`state: restarted`**: Ensures the service is restarted.
`when: ansible_os_family == "RedHat"`: Conditional statement that makes this task run only if the operating system family is RedHat.

This task will restart the Apache service only on systems identified as RedHat-based (e.g., RHEL, CentOS).

Testing and Validating Ansible Playbooks

Ansible is widely used for automating configurations and deployments, but ensuring that playbooks function correctly across different environments requires robust testing and validation. Proper testing minimizes errors, avoids configuration drift, and maintains consistent, reliable infrastructure. This article covers key techniques and tools for testing and validating Ansible playbooks, including syntax checking, dry runs, and advanced testing frameworks.

Why Test and Validate Ansible Playbooks?

Testing and validation are essential steps in building dependable Ansible playbooks. Testing enables you to:

Identify Syntax Errors: Catch YAML syntax issues or malformed variables before they impact production.
Verify Desired States: Ensure that configurations and installations meet expected outcomes across environments.
Prevent Configuration Drift: Detect unintended changes that could lead to inconsistencies.
Enhance Playbook Reliability: Confirm that tasks work as intended, reducing failures and downtime.

Techniques for Testing and Validating Playbooks

Syntax Check with `ansible-playbook --syntax-check`

One of the simplest ways to validate a playbook is by running a syntax check. This check analyzes the YAML syntax and Ansible structure, catching formatting errors, incorrect indentation, and malformed variables.

ansible-playbook playbook.yml --syntax-check

This command will identify syntax errors in `playbook.yml` without executing any tasks. It’s a quick, essential step for validating playbooks before deeper testing.

Perform a Dry Run with `--check`

Ansible’s check mode (`--check`) performs a “dry run” of the playbook, where Ansible simulates changes without actually making any modifications to the hosts. This allows you to see what Ansible would change, providing a preview of the tasks’ impact.

ansible-playbook playbook.yml --check

In check mode, Ansible reports what changes would occur, but without altering files, packages, or services. This mode is valuable for confirming expected changes and ensuring that the playbook logic is correct without making any actual changes.

Validate Variables with `--extra-vars`

Sometimes, a playbook may fail due to missing or incorrect variables. Using the `--extra-vars` option, you can test playbooks with specific variables to ensure they behave as expected.

ansible-playbook playbook.yml --extra-vars "env=production"

With `--extra-vars`, you can pass variables at runtime, helping you verify that the playbook works correctly in various environments (e.g., development, testing, production) by setting different variable values.

Use `ansible-lint` for Best Practices

`ansible-lint` is a tool that checks playbooks for common syntax and formatting errors, as well as Ansible best practices. Running `ansible-lint` on your playbooks ensures they adhere to Ansible conventions, helping avoid common mistakes and maintain clean, readable code.

Install `ansible-lint` with:

pip install ansible-lint

Then run it against a playbook:

ansible-lint playbook.yml

`ansible-lint` will highlight issues, suggest improvements, and enforce best practices, improving both the readability and maintainability of your playbooks.

Validate Idempotency

Idempotency is a key principle in Ansible: running the same playbook multiple times should produce the same result without making additional changes. Testing for idempotency ensures that tasks are well-defined and won’t reapply unnecessary changes.

To test idempotency:

Run the playbook on a test environment.
Run the playbook again and check the output for unnecessary changes.

If any tasks continue to execute on the second run, review the tasks to ensure they correctly specify the desired state (e.g., `state: present` for package installations).

Testing with Molecule

For advanced testing, Molecule is a powerful framework that provides a complete test environment for Ansible roles. Molecule supports multiple testing stages, including linting, syntax checks, idempotency testing, and integration testing using Docker or other virtual environments.

Setting Up Molecule

Install Molecule with `pip`:

pip install molecule docker

Initialize Molecule in a role directory:

cd roles/my_role

molecule init scenario -d docker

Run Molecule Tests:

Molecule’s `test` command runs all stages, from linting to idempotency testing.

molecule test

Molecule creates Docker containers to simulate hosts, applies your role, verifies the outcome, and ensures idempotency. It’s a comprehensive way to validate roles in isolated, repeatable environments, making it ideal for CI/CD pipelines.

Verify Output with `debug` Statements

Adding `debug` statements in playbooks helps confirm that variables are set correctly and tasks produce expected output. This is particularly useful for troubleshooting complex playbooks or testing new variables.

Example:

- name: Check hostname

debug:

msg: "The hostname is {{ ansible_hostname }}"

By running the playbook with debug statements, you can check variable values and task outputs without diving into logs, making troubleshooting and validation easier.

Use `assert` Statements for Validation

`assert` statements allow you to set conditions that must be met for the playbook to continue, providing an additional layer of validation. This is useful for ensuring prerequisites, like specific OS versions or required packages.

Example:

- name: Ensure the OS is Ubuntu

assert:

that:

- ansible_facts['os_family'] == "Debian"

If the assertion fails, the playbook stops, providing feedback on unmet conditions, making it an effective way to validate requirements.

Testing Playbooks in CI/CD Pipelines

Automating playbook tests within CI/CD pipelines ensures that playbooks are validated every time they’re modified, helping catch errors early in the development process. You can use CI/CD tools like Jenkins, GitLab CI, or GitHub Actions to automate syntax checks, linting, dry runs, and Molecule tests.

Example GitHub Actions Workflow for Ansible Testing:

on: [push, pull_request]

jobs:

test:

runs-on: ubuntu-latest

steps:

- name: Check out the code

uses: actions/checkout@v2

- name: Set up Python

uses: actions/setup-python@v2

with:

python-version: '3.x'

- name: Install Ansible and Dependencies

run: |

pip install ansible ansible-lint molecule docker

- name: Run Syntax Check

run: ansible-playbook playbook.yml --syntax-check

- name: Run Linting

run: ansible-lint playbook.yml

- name: Run Molecule Test

working-directory: roles/my_role

run: molecule test

This workflow checks out the code, installs Ansible and Molecule, runs a syntax check, lints the playbook, and performs Molecule tests to verify the playbook’s functionality.

Best Practices for Testing Ansible Playbooks

Use a Test Environment: Test playbooks on a non-production environment that mirrors production as closely as possible.
Modularize with Roles: Testing individual roles is more manageable and allows you to pinpoint issues quickly.
Automate with CI/CD: Integrate Ansible testing into CI/CD pipelines to catch issues before deployment.
Document Tests and Expected Outcomes: Keep records of tests, scenarios, and expected results to streamline future testing efforts.

Command-Line Usage for Ansible Playbooks

Running an Ansible playbook is straightforward once your YAML file is ready.

Running a Basic Playbook

To execute a playbook, use:

ansible-playbook myplaybook.yml

Installing and Configuring Apache on a Remote Host

Assuming we have a playbook file called `apache.yml` for setting up Apache:

---

- name: Setup Apache on web servers

hosts: web

become: true

tasks:

- name: Install Apache

yum:

state: present

- name: Start Apache

service:

state: started

Explanation

`hosts: web`: Specifies that this playbook will target hosts in the `web` group, as defined in the inventory file.
`become: true`: Ensures that Ansible uses elevated privileges (e.g., `sudo`) to execute tasks, which is essential for tasks that require administrator rights, like installing packages.
`tasks`: Contains a list of tasks for setting up Apache.
`Install Apache`: Uses the `yum` module to install the `httpd` package (Apache) on RedHat-based systems.
`Start Apache`: Uses the `service` module to start the Apache service.

This playbook will install and start Apache on all hosts in the `web` group, making it ready for web server functionality.

To run this playbook on remote servers in your inventory:

ansible-playbook -i inventory/apache_hosts apache.yml

Example inventory file (`inventory/apache_hosts`):

[web]
webserver1 ansible_host=192.168.1.10
webserver2 ansible_host=192.168.1.11

Passing Extra Variables

You can pass variables to a playbook at runtime using `-e`:

ansible-playbook myplaybook.yml -e "variable1=value1 variable2=value2"

Conclusion and Best Practices

With clean, well-structured YAML and knowledge of command-line options, you can create powerful, flexible playbooks to manage diverse environments. Here are some final tips:

Use roles for complex playbooks: Roles help modularize code.
Leverage variables: This improves reusability and readability.
Test before deploying: Always run a `--check` to validate before applying changes.

By following these best practices, you’ll ensure Ansible playbooks are reliable and easy to maintain.

References:

Ansible Documentation
YAML Specification
Illustrations generated with the help of OpenAI's AI.

Your Feedback Matters!

Have ideas or suggestions? Follow the blog and share your thoughts in the comments.

About Me

I am passionate about IT technologies. If you’re interested in learning more or staying updated with my latest articles, feel free to connect with me on:

Feel free to reach out through any of these platforms if you have any questions!

I am excited to hear your thoughts! 👇