Grouper Users - Open Discussion List

[Darren Boss <>]

One option would be to set up a reverse proxy in front of the
containers that directs traffic to the correct container based on the
url pattern. That reverse proxy is grouper.example.edu and it has
rules so traffic to /grouper goes to the ui container while
/grouper-ws goes to the web services container. In Kubernetes, this is
a core part of the platform and called the ingress controller which is
typically done via Nginx.

On Mon, Jul 13, 2020 at 8:15 PM Baron Fujimoto <> wrote:
>
> On Thu, Jul 02, 2020 at 05:15:31PM -1000, Baron Fujimoto wrote:
> >We're dipping our toes in the water of containerized Grouper, generally 
> >upgrading from 2.2 to 2.5. Upgrade issues aside, I have some basic 
> >questions about containerized Grouper that I hope aren't too stupid. I 
> >poked around the Grouper doucmentation I could find but didn't find what I 
> >was looking for – I'm happy to RTFM if someone will point me to TFM.
> >
>
> Different question:
>
> Our current grouper UI and WS deployments share a common hostname and port 
> (443).  E.g.:
>
> UI: <https://grouper.example.edu.grouper/grouper>
> WS: <https://grouper.example.edu.grouper/grouper-ws>
>
> We achieve this by running both services out of a shared Tomcat servlet 
> container. With dockerized Grouper the the best practice seems to be to run 
> each service in its own docker container (each with its own Tomcat servlet 
> container)?  Since each service can't listen to the same port (right?), 
> what is the recommended way of handling this? Just having, say, the WS, 
> listen to a different port? (Assuming we want to retain the same hostname.) 
> E.g.:
>
> UI: <https://grouper.example.edu.grouper/grouper>
> WS: <https://grouper.example.edu.grouper:9443/grouper>
>
> --
> UH Information Technology Services : Identity & Access Mgmt, Middleware
> minutas cantorum, minutas balorum, minutas carboratum desendus pantorum



-- 
Darren Boss
Senior Programmer/Analyst
Programmeur-analyste principal