OpenDJ/AM scaling with Docker

This topic contains 3 replies, has 3 voices, and was last updated by  Warren Strange 4 months, 3 weeks ago.

  • Author
    Posts
  • #21756
     rcr129 
    Participant

    Hi
    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.
    Thanks
    ~R

    #21781
     Warren Strange 
    Participant

    Short answer, yes this is possible with Kubernetes.

    Have a look at https://github.com/ForgeRock/forgeops

    And the DevOps guide (6.0 soon to be published).

    #23971
     taylor_dr 
    Participant

    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.

    #23972
     Warren Strange 
    Participant

    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.

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.

©2019 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?