diff options
author | STEVEN ADAMS <166521727+hugehope@users.noreply.github.com> | 2024-04-17 21:18:25 +0200 |
---|---|---|
committer | GitHub <noreply@github.com> | 2024-04-17 21:18:25 +0200 |
commit | 3d6a8fd4ef0075a4beb7a0199290467a3ff1d8ff (patch) | |
tree | 2d41092d02dec8f5879a69efc4841e0162e5fe9d /tools/docker-compose | |
parent | Fix wsrelay connection leak (#15113) (diff) | |
download | awx-3d6a8fd4ef0075a4beb7a0199290467a3ff1d8ff.tar.xz awx-3d6a8fd4ef0075a4beb7a0199290467a3ff1d8ff.zip |
chore: remove repetitive words (#15101)
Signed-off-by: hugehope <cmm7@sina.cn>
Diffstat (limited to 'tools/docker-compose')
-rw-r--r-- | tools/docker-compose/README.md | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/tools/docker-compose/README.md b/tools/docker-compose/README.md index d43a96e639..8ac287945c 100644 --- a/tools/docker-compose/README.md +++ b/tools/docker-compose/README.md @@ -387,7 +387,7 @@ Now we are ready to configure and plumb Keycloak with AWX. To do this we have pr * Backup and configure the SMAL and OIDC adapter in AWX. NOTE: the private key of any existing SAML or OIDC adapters can not be backed up through the API, you need a DB backup to recover this. Before we can run the playbook we need to understand that SAML works by sending redirects between AWX and Keycloak through the browser. Because of this we have to tell both AWX and Keycloak how they will construct the redirect URLs. On the Keycloak side, this is done within the realm configuration and on the AWX side its done through the SAML settings. The playbook requires a variable called `container_reference` to be set. The container_reference variable needs to be how your browser will be able to talk to the running containers. Here are some examples of how to choose a proper container_reference. -* If you develop on a mac which runs a Fedora VM which has AWX running within that and the browser you use to access AWX runs on the mac. The the VM with the container has its own IP that is mapped to a name like `tower.home.net`. In this scenario your "container_reference" could be either the IP of the VM or the tower.home.net friendly name. +* If you develop on a mac which runs a Fedora VM which has AWX running within that and the browser you use to access AWX runs on the mac. The VM with the container has its own IP that is mapped to a name like `tower.home.net`. In this scenario your "container_reference" could be either the IP of the VM or the tower.home.net friendly name. * If you are on a Fedora work station running AWX and also using a browser on your workstation you could use localhost, your work stations IP or hostname as the container_reference. In addition, OIDC works similar but slightly differently. OIDC has browser redirection but OIDC will also communicate from the AWX docker instance to the Keycloak docker instance directly. Any hostnames you might have are likely not propagated down into the AWX container. So we need a method for both the browser and AWX container to talk to Keycloak. For this we will likely use your machines IP address. This can be passed in as a variable called `oidc_reference`. If unset this will default to container_reference which may be viable for some configurations. |