May 5, 2018 at 8:46 pm #21756rcr129Participant
We are planning to build a Forgerock backend with docker containers for AM,IDM and DS
A single container per component is successfully built.
Has anyone considered/applied a scenario where we need to scale these containers and achieve DS replication and AM site registration automatically ? Scaling IDM seems straight forward.
~RMay 7, 2018 at 3:21 pm #21781Warren StrangeParticipantNovember 24, 2018 at 8:39 pm #23971taylor_drParticipant
How does AM cope with the random hostnames?
From the doco I have found (https://backstage.forgerock.com/docs/platform/6/devops-guide/#devops-deploy-openam-opendj-k8s-scale), it seems that on scaling up new instances are added, and they just don’t show up in the list of servers.
Is that really the only side-efect? How does that work with stateful sessions?
How do the new server instances know which site they are part of?
These things may not matter if stateless sessions are used, but are there not still things that rely on persistent sessions, e.g. SAML 2.0 (last mention of a problem in 5.1, but I can’t find a note saying the issue is resolved either), or possibly using short inactivity timeouts.November 25, 2018 at 10:49 pm #23972Warren StrangeParticipant
AM >= 6.0 are “cattle”[*], and do not require a stable hostname. You won’t see multiple servers showing up in servers->sites because they are all the same “server”.
This works with stateful or stateless sessions. The session state is coordinated through the CTS – so any server can issue a token and any other server can validate it. You will get better performance with stateless tokens as the load on the CTS is much less.
[*] The remaining corner case (from memory) is SAML single log out. This is not synchronized through the CTS. Using sticky load balancing mitigates this issue.
You must be logged in to reply to this topic.