Ansible may need access to sensitive data such as passwords or API keys in order to configure remote servers. Normally, this information might be stored as plain text in inventory variables or other Ansible files. But in that case, any user with access to the Ansible files or a version control system which stores the Ansible files would have access to this sensitive data. This poses an
obvious security risk.
Czytaj dalej Ansible Vault
Ansible Galaxy is essentially a large public repository of Ansible roles. Roles ship with readmes detailing role use and available variables. Galaxy contains a large number of roles that are constantly evolving and increasing. Galaxy can use git allowing for other role sources such as GitHub.
Czytaj dalej Ansible Galaxy
When dealing with extensive playbooks, it is easier to split the tasks into roles. This also helps in reusing the roles in the future. Roles are a collection of tasks, which can be moved from one playbook to another, can be run independently but only through a playbook file. In other words, roles are a feature of Ansible that facilitate reuse and further promote modularization of configuration.
Czytaj dalej Ansible Roles
Ansible evaluates the return codes of modules and commands to determine whether a task succeeded or failed. Normally, when a task fails Ansible immediately aborts the plays, skipping all subsequent tasks.
However, sometimes an administrator may want to have playbook execution continue even if a task fails. For example, it may be expected that a particular command will fail.
Czytaj dalej Ansible Handling Errors
For long playbooks, it is useful to be able to run subsets of the tasks in the playbook. To do this, tags can be set on specific resources as a text label. Tagging a resource only requires that the tags keyword be used, followed by a list of tags to apply. When plays are tagged, the –tags option can be used with ansible-playbook to filter the playbook to only execute specific tagged plays.
Czytaj dalej Ansible Tags