General Information
The command ansible-pull, inverts the way that ansible works. Instead of sending commands from a central location, a client can pull down a playbook from a version controlled repository and run it locally.
Checklist
You will need access to a software repo in order to commit/push your ansible-pull playbook into.
This repo will be used by the clients to pull from.
The repo visibility (public/private) doesn't matter, as long as there is a way for the client to access it over https or ssh.
The ansible-pull playbook file will be the only part that looks different than a normal playbook/role setup.
The entire role directory structure/files can remain the same as if it were being deployed via normal ansible-playbook commands.
The directory structure for an Ansible Pull repo does not look that much different than Ansible's best practices for playbooks.
If this method is followed, the same role can also be used on the system that does regular ansible-playbook push commands (referenced from a different playbook file).
├── myplaybook.yml └── myrole ├── files ├── handlers │ └── main.yml ├── tasks │ └── main.yml └── vars └── main.yml
Example of a playbook tailored for pulling.
# File: myplaybook.yml # Description: Playbook used to execute on the local system via ansible-pull # hosts to run on - hosts: - localhost # roles: located in same directory roles: # role: role to assign to hosts, tags: tag(s) to give entire role - { role: myrole, tags: myrole } # Do not gather host facts for this playbook (comment out/remove if you need facts) gather_facts: no
Example of a role that can be used with either a pull playbook or normal playbook.
File: myrole/tasks/main.yml → Installs a list of applications using the variable “my_awesome_apps” and notifies a handler if anything changes
- name: Install my awesome app list yum: name: "{{ my_awesome_apps }}" state: present notify: restart my awesome service
File: myrole/vars/main.yml → Variable that contains a list of applications to install
my_awesome_apps: - myapp1 - myapp2
File: myrole/vars/handlers.yml → Handler that restarts a service when triggered
- name: restart my awesome service service: name: my-awesome-service state: restarted
Steps for the client to run the playbook via ansible-pull.
Example with a git repo
yum -y install ansible git
cp /mnt/remote-mount/share/id_rsa_ansible-pull /root/.ssh/id_rsa_ansible-pull
chown root:root /root/.ssh/id_rsa_ansible-pull chmod 600 /root/.ssh/id_rsa_ansible-pull
mkdir -p /root/.ansible/pull
ansible-pull --directory /root/.ansible/pull --url git@mygitserver.mycorps.domain.org:group/myrepo.git --key-file /root/.ssh/id_rsa_ansible-pull --accept-host-key --clean myplaybook.yml
ansible-pull --directory /root/.ansible/pull --url https://mygitserver.mycorps.domain.org/group/myrepo.git --clean myplaybook.yml
Options Used
Using ansible-pull, there is now the capability to make changes to systems via repo pushes.
Automation Ideas
--only-if-changed
--checkout 'development'