External-Mirrors/awx
2
0
Fork 0
mirror of https://github.com/ansible/awx.git synced 2026-03-09 05:29:26 -02:30
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #6688 from ryanpetrello/isolated-docs

Browse Source 
more isolated acceptance doc updates
This commit is contained in:
Ryan Petrello
2017-06-22 12:55:40 -04:00
committed by GitHub
parent adb9f05fbd 5e908bfc50
commit bbcebf295f
1 changed files with 31 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

41
docs/clustering.md
View File

@@ -139,20 +139,41 @@ isolatedB
controller=security controller=security
``` ```
In this example, when a job runs inside of the `govcloud` isolated group, a In the isolated rampart model, "controller" instances interact with "isolated"
managing task runs simultaneously on either one of the two instances in instances via a series of Ansible playbooks over SSH. As such, all isolated instances
the `security` ordinary instance group. must be preconfigured by the installer with passwordless SSH access from any potential
controller instances. In the example above, the `isolatedA` and `isolatedB` hosts
must be reachable from `towerB` and `towerC` hosts via `ssh
awx@<isolated-hostname>` (meaning, `authorized_keys` must be pre-distributed to
the `isolatedA` and `isolatedB` hosts).
Networking security rules must allow When a job is scheduled to run on an "isolated" instance:
connections to all nodes in an isolated group from all nodes in its controller
group. The system is designed such that * The "controller" instance compiles metadata required to run the job and copies
isolated instances never make requests to any of their controllers. it to the "isolated" instance via `rsync`. This metadata includes:
The controlling instance for a particular job will send management commands to
a daemon that runs the job, and will slurp job artifacts. - the entire SCM checkout directory for the project
- a static inventory file
- pexpect passwords
- environment variables
- the `ansible`/`ansible-playbook` command invocation, i.e.,
`bwrap ... ansible-playbook -i /path/to/inventory /path/to/playbook.yml -e ...`
* Once the metadata has been rsynced to the isolated host, the "controller
instance" starts a process on the "isolated" instance which consumes the
metadata and starts running `ansible`/`ansible-playbook`. As the playbook
runs, job artifacts (such as stdout and job events) are written to disk on
the "isolated" instance.
* While the job runs on the "isolated" instance, the "controller" instance
periodically copies job artifacts (stdout and job events) from the "isolated"
instance using `rsync`. It consumes these until the job finishes running on the
"isolated" instance.
Isolated groups are architected such that they may exist inside of a VPC Isolated groups are architected such that they may exist inside of a VPC
with security rules that _only_ permit the instances in its `controller` with security rules that _only_ permit the instances in its `controller`
group to access them. group to access them; only ingress SSH traffic from "controller" instances to
"isolated" instances is required.
Recommendations for system configuration with isolated groups: Recommendations for system configuration with isolated groups:
- Do not put any isolated instances inside the `tower` group or other - Do not put any isolated instances inside the `tower` group or other