Add sa-prod/rails-admin deployment to service heavier, longer running requests

[decimalator]

Descriptive summary

Like we had done for Oregon Digital, we should add a dedicated Rails deployment for handling heavier requests.

Inbound requests to ir.library.oregonstate.edu come in through BRPX, the Beavernetes Reverse ProXy service. This is a set of nginx web servers that accept incoming requests from the Internet and forward requests to a working Beavernetes Ingress Controller to be forwarded on to the application.

To forward heavier requests to its own set of Rails Pods we will create a new deployment, sa-prod/rails-admin. This will be almost identical to sa-prod/rails, the primary Rails deployment that handles all of ir.library.oregonstate.edu right now. The only major difference will be the name of the deployment and its child Pods.

We will adjust the Ingress for ir.library.oregonstate.edu to selectively forward requests to either sa-prod/rails or sa-prod/rails-admin based on the URL path. For example:

• / will continue to go to sa-prod/rails, this is the default
• heavier request paths like /admin, /sidekiq, etc. (eventually anything doing writes/updates/deletes) will be sent to sa-prod/rails-admin

Functionally this will have the exact same behavior that we have now. The only difference is that instead of 3x Rails Pods, we will have 3x Rails Pods for handling heavy requests plus 3x more for handling everything else.

Expected behavior

Requests that create, delete or update data in SA@OSU should go through their own set of Rails Pods and leave the primary Rails Pods to serve shorter read requests. This should allow smaller requests to finish much more quickly and avoid using up all existing server threads on long running requests.

Actual behavior

All requests go through the same sa-prod/rails deployment.