Introduction
Hitachi Ansible modules for VSP One Block and VSP One Object provide a simplified and automated way to configure and manage Hitachi storage systems, enabling seamless integration with Ansible playbooks and workflows. These modules are used to perform specific tasks within playbooks. Below are some best practices for creating playbooks with Hitachi’s Ansible modules.
- Encrypt sensitive data
- Simplify tasks with Ansible roles
- Organize tasks and handlers
- Use dynamic inventory
- Documentation
- Test and validate playbooks
The sections below will dive into each of these best practices.
Encrypt Sensitive Data
Sensitive data used within Ansible playbooks should be encrypted and securely stored using Ansible Vault. Ansible Vault is a built-in feature of Ansible that protects sensitive information such as storage serial numbers, IP addresses, usernames, passwords, API tokens and secret keys. Encrypting sensitive data ensures it is not stored in plain text and reduces security risks in automation workflows.
See the following recommendations to securely manage sensitive data:
- Create a YAML file containing required sensitive variables (for example: storage serial, address, username, password). Avoid storing sensitive information directly inside playbooks. See the following YAML file as an example.
- Use
ansible-vault to encrypt the file. The contents of the YAML file will be AES256 encrypted.
ansible-vault encrypt ansible_vault_storage_var.yml
- In the playbook, reference the encrypted file with the following:
vars_files:
- ./ansible_vault_vars/ansible_vault_storage_var.yml
- When running the playbook, use the --ask-vault-pass flag
ansible-playbook playbook.yml --ask-vault-pass
- For non-interactive execution (such as CI/CD pipelines), use a vault password file with
--vault-password-file. Where the password file can be hidden file in local directory as secret.pass
- For multi-environment deployments, use vault IDs that manage separate vault passwords.
- Avoid hardcoding vault password files in project directories. For improved security, use environment variables configuration or secure CI/CD secret mechanisms.
- Alternatively, you encrypt individual texts instead of entire files. These encrypted text can be used in YAML files. To encrypt individual texts:
ansible-vault encrypt_string 'MyPassword' --name 'vsp_password'
- Use
no_log: true in tasks that handle credentials to prevent sensitive data from appearing in logs.
- Ensure secure communication with VSP One Block systems by enabling TLS certificate validation:
validate_certs: true
- Follow the principle of least privilege by using dedicated automation service accounts with minimal required permissions.
- For enterprise deployments, consider integrating with external secret management solutions such as CyberArk, HashiCorp Vault, cloud based key management services to centrally manage and rotate credentials.
Simplify Tasks with Ansible Roles
Use roles to organize your playbook content. Roles allow you to group tasks, handlers, variables, and other components logically. This also makes the code for Ansible tasks easily reusable across different playbooks and/or projects.
See the following playbook cleanup_gad_pairs_pvol.yml using the ansible role: hv_vsp_host_volume_deletion
Playbook calls the hv_vsp_host_volume_deletion role
The hv_vsp_host_volume_deletion role consolidates 6 tasks in a simple role called from the playbook.
Multiple tasks are grouped in a role. In this case, this role performs numerous get tasks (system info primary and secondary system), delete volumes after migration, and others. Instead of rewriting the code for these tasks, in other playbooks, the role can be reused. Additionally, the playbook that uses these roles, the code is greatly simplified.
Task and Handler Organization
Write simple and readable tasks. Avoid complex logic within tasks whenever possible. The helps to simplify sustainability and maintenance efforts for the playbook. Some examples to avoid are:
- Deep nesting
- Excessive use of inline parsing
- Multiple branches
- Use of mutable facts
Below is a deeper look at a negative example with complex logic to find GAD pairs by primary volume ID.
In this example, there is multi-level nesting of tasks to filer for specific GAD pairs. It makes the playbook unnecessarily long and complicated. Resulting in a playbook that is harder to troubleshoot and maintain.
As with any coding practice, it’s always a good practice to add comments to explain complex tasks or decisions. This section describes some specifics for Ansible playbooks.
Always name your tasks clearly to describe their purpose. This helps with understanding what the playbook is aiming for for each task.
Example: