зеркало из
https://github.com/iharh/notes.git
synced 2025-10-30 05:06:05 +02:00
92 строки
3.0 KiB
Plaintext
92 строки
3.0 KiB
Plaintext
Environment:
|
||
https://github.com/ansible/ansible-examples/blob/master/language_features/environment.yml
|
||
|
||
- hosts: all
|
||
remote_user: root
|
||
# here we make a variable named "env" that is a dictionary
|
||
vars:
|
||
env:
|
||
HI: test2
|
||
http_proxy: http://proxy.example.com:8080
|
||
tasks:
|
||
# here we just define the dictionary directly and use it
|
||
# (here $HI is the shell variable as nothing in Ansible will replace it)
|
||
- shell: echo $HI
|
||
environment:
|
||
HI: test1
|
||
# here we are using the $env variable above
|
||
- shell: echo $HI
|
||
environment: env
|
||
|
||
|
||
Conditionals:
|
||
|
||
http://docs.ansible.com/ansible/playbooks_conditionals.html
|
||
|
||
Sometimes you will want to do certain things differently in a playbook based on certain criteria.
|
||
Having one playbook that works on multiple platforms and OS versions is a good example.
|
||
|
||
As an example, the name of the Apache package may be different between CentOS and Debian,
|
||
but it is easily handled with a minimum of syntax in an Ansible Playbook:
|
||
|
||
---
|
||
- hosts: all
|
||
remote_user: root
|
||
vars_files:
|
||
- "vars/common.yml"
|
||
- [ "vars/{{ ansible_os_family }}.yml", "vars/os_defaults.yml" ]
|
||
tasks:
|
||
- name: make sure apache is running
|
||
service: name={{ apache }} state=running
|
||
|
||
As a reminder, the various YAML files contain just keys and values:
|
||
|
||
---
|
||
# for vars/CentOS.yml
|
||
apache: httpd
|
||
somethingelse: 42
|
||
|
||
How does this work?
|
||
If the operating system was ‘CentOS’, the first file Ansible would try to import would be ‘vars/CentOS.yml’,
|
||
followed by ‘/vars/os_defaults.yml’ if that file did not exist.
|
||
If no files in the list were found, an error would be raised.
|
||
On Debian, it would instead first look towards ‘vars/Debian.yml’ instead of ‘vars/CentOS.yml’,
|
||
before falling back on ‘vars/os_defaults.yml’.
|
||
Pretty simple.
|
||
|
||
To use this conditional import feature, you’ll need facter or ohai installed prior to running the playbook,
|
||
but you can of course push this out with Ansible if you like:
|
||
|
||
# for facter
|
||
ansible -m yum -a "pkg=facter state=present"
|
||
ansible -m yum -a "pkg=ruby-json state=present"
|
||
|
||
# for ohai
|
||
ansible -m yum -a "pkg=ohai state=present"
|
||
|
||
Ansible’s approach to configuration – separating variables from tasks, keeps your playbooks from turning into arbitrary code
|
||
with ugly nested ifs, conditionals, and so on - and results in more streamlined & auditable configuration rules –
|
||
especially because there are a minimum of decision points to track.
|
||
|
||
|
||
|
||
|
||
Sometimes a configuration file you want to copy, or a template you will use may depend on a variable.
|
||
The following construct selects the first available file appropriate for the variables of a given host,
|
||
which is often much cleaner than putting a lot of if conditionals in a template.
|
||
|
||
The following example shows how to template out a configuration file that was very different between, say, CentOS and Debian:
|
||
|
||
- name: template a file
|
||
template: src={{ item }} dest=/etc/myapp/foo.conf
|
||
with_first_found:
|
||
- files:
|
||
- {{ ansible_distribution }}.conf
|
||
- default.conf
|
||
paths:
|
||
- search_location_one/somedir/
|
||
- /opt/other_location/somedir/
|
||
|
||
|
||
|