schaarj
commented
3 years ago As mentioned, I don't see the issue of following the guide step by step, I think as soon as the IDS is part of the core it's also a little more reasonable as this might be part of an initial compose file so you don't start out with an empty nginx. The reason keycloak is not part of the initial config, is, that @henkbirkholz suggested that projects should rather start out connecting to the central SSO than running their own in a non-federated manner.
Also the Keycloak section states as a requirement a running reverse proxy, so I don't see an issue with the setup failing if this is not met.
I agree that the current setup is not ideal, but it was the best intermediate way I came up with, which is not too far away from the automated setup we are moving toward.
If there are concrete improvement changes, I'm happy to discuss and implement them.
milux
The current startup process for running nginx with support for sso (keycloak), and pyiron, in fact in general any auxiliary application container that nginx plays proxy for, requires first starting nginx in its base config (done via docker-compose in the root-directory of this repository), then starting keycloak, then reconfiguring the running nginx-instance to supprt keycloak. This process must be repeated then with pyiron (which additionally requires keycloak), and so on.
Going any other way in this startup sequence fails either due to an external docker network not being present or nginx failing to start due to proxied urls not being existent yet.
If startup sequence is done manually, this process is cumbersome and prone to errors, complicated to document and possibly has drawbacks regarding a smooth error recovery afterwards because of intermediate states the startup process left with.