.. | ||
Dockerfile | ||
playbook@.service | ||
Procfile | ||
README.md |
Instructions on using an isolated node
The building of the isolated node is done in the make docker-compose-build
target. Its image uses a different tag from the tools_tower container.
Given that the images are built, you can run the combined docker compose target. This uses
the base docker-compose.yml
with modifications found in docker-isolated-override.yml
.
You will still need to give COMPOSE_TAG with whatever your intended
base branch is. For example:
make docker-isolated COMPOSE_TAG=devel
This will automatically exchange the keys in order for the tools_tower_1
container to access the tools_isolated_1
container over ssh.
After that, it will bring up all the containers like the normal docker-compose
workflow.
Running a job on the Isolated Node
Create a job template that runs normally. Add the id of the instance
group named thepentagon
to the JT's instance groups. To do this, POST
the id (probably id=2) to /api/v2/job_templates/N/instance_groups/
.
After that, run the job template.
The models are automatically created when running the Makefile target, and they are structured as follows:
+-------+ +-------------+
| tower |<----+ thepentagon |
+-------+ +-------------+
^ ^
| |
| |
+---+---+ +-----+----+
| tower | | isolated |
+-------+ +----------+
The controller
for the group "thepentagon" and all hosts therein is
determined by a ForeignKey within the instance group.
Development Testing Notes
Test the SSH connection between containers
While the environment is running, you can test the connection like so:
docker exec -i -t tools_tower_1 /bin/bash
Inside the context of that container:
ssh root@isolated
(note: awx user has been deprecated)
This should give a shell to the tools_isolated_1
container, as the
tools_tower_1
container sees it.
Start the playbook service
The following command would run the playbook for job 57.
systemctl start playbook@57.service