reordering entries in glossary for alphabetical order
This commit is contained in:
parent
faca6e9dfe
commit
1918604e72
1 changed files with 28 additions and 28 deletions
|
@ -148,28 +148,6 @@ the inventory file, in YAML format. This provides a convenient place to assign
|
||||||
them in the inventory file. The Host Vars file can also be used to define complex data structures that can't be represented in the
|
them in the inventory file. The Host Vars file can also be used to define complex data structures that can't be represented in the
|
||||||
inventory file.
|
inventory file.
|
||||||
|
|
||||||
Lazy Evaluation
|
|
||||||
+++++++++++++++
|
|
||||||
|
|
||||||
In general, Ansible evaluates any variables in playbook content at the last possible second, which means that if you define a data structure
|
|
||||||
that data structure itself can define variable values within it, and everything "just works" as you would expect. This also means variable
|
|
||||||
strings can include other variables inside of those strings.
|
|
||||||
|
|
||||||
Lookup Plugin
|
|
||||||
+++++++++++++
|
|
||||||
|
|
||||||
A lookup plugin is a way to get data into Ansible from the outside world. These are how such things as "with_items", a basic looping plugin, are implemented,
|
|
||||||
but there are also lookup plugins like "with_file" which loads data from a file, and even ones for querying environment variables,
|
|
||||||
DNS text records, or key value stores. Lookup plugins can also be accessed in templates, e.g., ``{{ lookup('file','/path/to/file') }}``.
|
|
||||||
|
|
||||||
Multi-Tier
|
|
||||||
++++++++++
|
|
||||||
|
|
||||||
The concept that IT systems are not managed one system at a time, but by interactions between multiple systems, and groups of systems, in
|
|
||||||
well defined orders. For instance, a web server may need to be updated before a database server, and pieces on the web server may need
|
|
||||||
to be updated after *THAT* database server, and various load balancers and monitoring servers may need to be contacted. Ansible models
|
|
||||||
entire IT topologies and workflows rather than looking at configuration from a "one system at a time" perspective.
|
|
||||||
|
|
||||||
Idempotency
|
Idempotency
|
||||||
+++++++++++
|
+++++++++++
|
||||||
|
|
||||||
|
@ -211,6 +189,13 @@ JSON
|
||||||
|
|
||||||
Ansible uses JSON for return data from remote modules. This allows modules to be written in any language, not just Python.
|
Ansible uses JSON for return data from remote modules. This allows modules to be written in any language, not just Python.
|
||||||
|
|
||||||
|
Lazy Evaluation
|
||||||
|
+++++++++++++++
|
||||||
|
|
||||||
|
In general, Ansible evaluates any variables in playbook content at the last possible second, which means that if you define a data structure
|
||||||
|
that data structure itself can define variable values within it, and everything "just works" as you would expect. This also means variable
|
||||||
|
strings can include other variables inside of those strings.
|
||||||
|
|
||||||
Library
|
Library
|
||||||
+++++++
|
+++++++
|
||||||
|
|
||||||
|
@ -222,12 +207,6 @@ Limit Groups
|
||||||
By passing ``--limit somegroup`` to ansible or ansible-playbook, the commands can be limited to a subset of hosts. For instance,
|
By passing ``--limit somegroup`` to ansible or ansible-playbook, the commands can be limited to a subset of hosts. For instance,
|
||||||
this can be used to run a playbook that normally targets an entire set of servers to one particular server.
|
this can be used to run a playbook that normally targets an entire set of servers to one particular server.
|
||||||
|
|
||||||
Local Connection
|
|
||||||
++++++++++++++++
|
|
||||||
|
|
||||||
By using "connection: local" in a playbook, or passing "-c local" to /usr/bin/ansible, this indicates that we are managing the local
|
|
||||||
host and not a remote machine.
|
|
||||||
|
|
||||||
Local Action
|
Local Action
|
||||||
++++++++++++
|
++++++++++++
|
||||||
|
|
||||||
|
@ -235,6 +214,19 @@ A local_action directive in a playbook targeting remote machines means that the
|
||||||
machine, but that the variable '{{ ansible_hostname }}' can be passed in to reference the remote hostname being referred to in
|
machine, but that the variable '{{ ansible_hostname }}' can be passed in to reference the remote hostname being referred to in
|
||||||
that step. This can be used to trigger, for example, an rsync operation.
|
that step. This can be used to trigger, for example, an rsync operation.
|
||||||
|
|
||||||
|
Local Connection
|
||||||
|
++++++++++++++++
|
||||||
|
|
||||||
|
By using "connection: local" in a playbook, or passing "-c local" to /usr/bin/ansible, this indicates that we are managing the local
|
||||||
|
host and not a remote machine.
|
||||||
|
|
||||||
|
Lookup Plugin
|
||||||
|
+++++++++++++
|
||||||
|
|
||||||
|
A lookup plugin is a way to get data into Ansible from the outside world. These are how such things as "with_items", a basic looping plugin, are implemented,
|
||||||
|
but there are also lookup plugins like "with_file" which loads data from a file, and even ones for querying environment variables,
|
||||||
|
DNS text records, or key value stores. Lookup plugins can also be accessed in templates, e.g., ``{{ lookup('file','/path/to/file') }}``.
|
||||||
|
|
||||||
Loops
|
Loops
|
||||||
+++++
|
+++++
|
||||||
|
|
||||||
|
@ -252,6 +244,14 @@ language, including Perl, Bash, or Ruby -- but can leverage some useful communal
|
||||||
have to return JSON or simple key=value pairs. Once modules are executed on remote machines, they are removed, so no long running
|
have to return JSON or simple key=value pairs. Once modules are executed on remote machines, they are removed, so no long running
|
||||||
daemons are used. Ansible refers to the collection of available modules as a 'library'.
|
daemons are used. Ansible refers to the collection of available modules as a 'library'.
|
||||||
|
|
||||||
|
Multi-Tier
|
||||||
|
++++++++++
|
||||||
|
|
||||||
|
The concept that IT systems are not managed one system at a time, but by interactions between multiple systems, and groups of systems, in
|
||||||
|
well defined orders. For instance, a web server may need to be updated before a database server, and pieces on the web server may need
|
||||||
|
to be updated after *THAT* database server, and various load balancers and monitoring servers may need to be contacted. Ansible models
|
||||||
|
entire IT topologies and workflows rather than looking at configuration from a "one system at a time" perspective.
|
||||||
|
|
||||||
Notify
|
Notify
|
||||||
++++++
|
++++++
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue