This moves the container-based code location and venvs. The goal here is that the paths of Tower source for isolated vs normal nodes matches (both in prod and local development) so that we don't have to add a bunch of additional bwrap argument logic for <location-of-isolated-tower-venv>.
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.
tower-expect start 57