ReleaseEngineering/How To/Use Ansible for AdHoc Updates: Difference between revisions
(→Ansible: Grammar) |
No edit summary |
||
(8 intermediate revisions by 5 users not shown) | |||
Line 1: | Line 1: | ||
{{Release Engineering How To| | {{Release Engineering How To|Use Ansible for Ad-Hoc Updates}} | ||
==Ansible== | ==Ansible== | ||
Ansible is an orchestration/configuration management system written in Python. Since we already have Puppet in place for configuration management, RelEng will only care about Ansible's orchestration oriented features. | Ansible is an orchestration/configuration management system written in Python. Since we already have Puppet in place for configuration management, RelEng will only care about Ansible's orchestration oriented features. Since Ansible has better support for our EC2 use cases, it is the preferred tool for all future non-puppet work (and fabric is deprecated). | ||
====You | ====You will want to use ansible for:==== | ||
* Quickly running a command against all | * Quickly running a command against all ec2 instances | ||
* Testing changes against a subset of all | * Testing changes against a subset of all hosts | ||
* Gathering data on an ad hoc basis (grepping logs for instance) | * Gathering data on an ad hoc basis (grepping logs for instance) | ||
* any new automation development | |||
====Reasons to use Ansible:==== | ====Reasons to use Ansible:==== | ||
* It has lots of nice builtin modules (see the [[http://docs.ansible.com/ docs]]) | * It has lots of nice builtin modules (see the [[http://docs.ansible.com/ docs]]) | ||
* You can define orchestration tasks in a repeatable, clean way | * You can define orchestration tasks in a repeatable, clean, way via writing them as a playbook (YAML) | ||
* It gives our operational scripts (for killing machines, applying common fixes, etc...) a common framework, allowing users (other than the original author) to understand them more easily | * It gives our operational scripts (for killing machines, applying common fixes, etc...) a common framework, allowing users (other than the original author) to understand them more easily | ||
Line 21: | Line 22: | ||
==Set it up locally:== | ==Set it up locally:== | ||
1.) Make sure you have AWS creds, and the | 1.) Make sure you have AWS creds, and the AWS_SECRET_ACCESS_KEY and AWS_ACCESS_KEY_ID environment variables set | ||
2.) <code>pip install ansible</code> | 2.) <code>pip install ansible</code> | ||
3.) <code>git clone https://github.com/ | 3.) <code>git clone https://github.com/mozilla/build-ansible/</code> | ||
-optional but highly recommended- | -optional but highly recommended- | ||
Line 42: | Line 43: | ||
Similarly, replace tst-linux64 with tst-linux32, try-linux32, etc... | Similarly, replace tst-linux64 with tst-linux32, try-linux32, etc... | ||
==Run a shell script:== | |||
From the same, local, directory as somescript.sh: <code>ansible -u root -i ec2-inventory.py -m script -a ./somescript.sh tst-linux64</code> | |||
==Run checkconfig:== | |||
<code>ansible-playbook -i master-inventory.py checkconfig.yml</code> | |||
To limit this to certain hosts or classes you can do this: | |||
<code>ansible-playbook -i master-inventory.py checkconfig.yml -l build</code> | |||
To see which hosts would be impacted: | |||
<code>ansible-playbook -i master-inventory.py checkconfig.yml --list-hosts -l build</code> |
Latest revision as of 18:40, 13 April 2016
Ansible
Ansible is an orchestration/configuration management system written in Python. Since we already have Puppet in place for configuration management, RelEng will only care about Ansible's orchestration oriented features. Since Ansible has better support for our EC2 use cases, it is the preferred tool for all future non-puppet work (and fabric is deprecated).
You will want to use ansible for:
- Quickly running a command against all ec2 instances
- Testing changes against a subset of all hosts
- Gathering data on an ad hoc basis (grepping logs for instance)
- any new automation development
Reasons to use Ansible:
- It has lots of nice builtin modules (see the [docs])
- You can define orchestration tasks in a repeatable, clean, way via writing them as a playbook (YAML)
- It gives our operational scripts (for killing machines, applying common fixes, etc...) a common framework, allowing users (other than the original author) to understand them more easily
How To:
Set it up locally:
1.) Make sure you have AWS creds, and the AWS_SECRET_ACCESS_KEY and AWS_ACCESS_KEY_ID environment variables set
2.) pip install ansible
3.) git clone https://github.com/mozilla/build-ansible/
-optional but highly recommended-
4.) set the environment variable ANSIBLE_HOST_KEY_CHECKING=False
to prevent prompts for adding machines to your known hosts
5.) use ssh-agent to prevent needing to type your passcode thousands of times >.<
Run an ad-hoc command:
These commands should be run from within the build-ansible directory.
Add a file "/tmp/foo" to every tst-linux64 host: ansible -u root -i ec2-inventory.py -a "touch /tmp/foo" tst-linux64
Remove the file: ansible -u root -i ec2-inventory.py -a "rm /tmp/foo" tst-linux64
Similarly, replace tst-linux64 with tst-linux32, try-linux32, etc...
Run a shell script:
From the same, local, directory as somescript.sh: ansible -u root -i ec2-inventory.py -m script -a ./somescript.sh tst-linux64
Run checkconfig:
ansible-playbook -i master-inventory.py checkconfig.yml
To limit this to certain hosts or classes you can do this:
ansible-playbook -i master-inventory.py checkconfig.yml -l build
To see which hosts would be impacted:
ansible-playbook -i master-inventory.py checkconfig.yml --list-hosts -l build