Stream: inferno
Topic: Run inferno Docker image with https redirect URI
Cooper Thompson (Jul 12 2021 at 15:37):
I feel like I'm missing something obvious, but I'm running the Inferno docker containers pretty much out of the box. However, the redirect, launch, and JWK URLs that are auto-generated using request.base_url are picking up the "http" scheme (vs. https). I think this is because the docker/nginx.conf file is set up to listen on port 80. I have an Apache server in front of the container that is fronting the https endpoint, however I ProxyPass to http://inferno.epic.com:4597. I think in order to get the inferno container to generate a redirect URI that is https (which we require), I'd need to either update the nginx.conf to use port 443, and bind a certificate, or get Inferno to update the ruby code to have an option to specify an override for request.base_url in config.yml such that we can tell Inferno to use a proxy URL.
Cooper Thompson (Jul 12 2021 at 15:38):
I did submit https://github.com/onc-healthit/inferno-program/issues/317, but if anyone has ideas on how to get the Inferno container to pick up an https scheme without a code fix, please let me know.
Stephen MacVicar (Jul 12 2021 at 15:49):
I saw the github issue before I saw this message, so I left a response there.
As a quick workaround, the configuration for our deployed instances (which use https) lives here: https://github.com/onc-healthit/inferno.healthit.gov
That repo deploys more than just program, so you could either comment out the services you don't need from that docker-compose and have it load your certs, or use its nginx configuration as a model for yours.
I am also not an nginx expert, so I basically look at that repo whenever I need to figure out how to do something deployment related.
Stephen MacVicar (Jul 12 2021 at 16:07):
Actually, we describe some options for this in response to a previous issue: https://github.com/onc-healthit/inferno-program/issues/314#issuecomment-875616942
Cooper Thompson (Jul 12 2021 at 18:11):
Thanks for this info. It was helpful. I'm working through it now, and I think I'm starting to get the picture. Here is my understanding of how the architecture works:
1) Client connects to the https port on the nginx container.
2) Nginx terminates the SSL connection and forwards traffic to the inferno container over http (port 4567).
3) The Inferno container is running the main ruby code on a jetty web server on 4567.
Because the ruby code that generates the base URL is running in jetty, and not in nginx, it relies on the X-Forwarded-* headers to know what the request.base_url is.
The nginx.conf in inferno-program doesn't do any scheme forwarding. However your nginx.conf in inferno.healthit.gov does. Ultimately, all I needed was to add this to the nginx.conf:
proxy_set_header X-Forwarded-Proto https;
This is hard-coding https, instead of relying on the actual schemed used, but since I couldn't figure out how to get the nginx->jetty to use http (which would involve diving into jetty and ruby), I'm satisfied with this solution for now.
Cooper Thompson (Jul 12 2021 at 18:13):
However, I don't really understand how inferno.healthit.gov is working. Do you have the jetty server set up to run https there, such that the nginx->jetty connection is over https? I didn't see any jetty changes in the overlay repo.
Robert Scanlon (Jul 12 2021 at 18:17):
main ruby code on a jetty web server on 4567.
We aren't using Jetty for Inferno (Jetty is for Java, right?) -- but the same basic concept in Ruby I think (Sinatra running on the Thin webserver). We may be using Jetty for the "reference server" that we use to demonstrate our tests against, as it is based on HAPI.
Robert Scanlon (Jul 12 2021 at 18:31):
For the docker-compose for 'inferno-program', we stand up an nginx server that doesn't expect SSL (it doesn't terminate SSL, and we didn't try to configure it properly if something else in front of it is terminating SSL).
Robert Scanlon (Jul 12 2021 at 18:34):
For the docker-compose for 'inferno.healthit.gov', we stand up an nginx server with a different configuration, that terminates SSL and passes along a header to the services running behind (including Inferno running on Thin in Ruby) that they should act as if they are https, so they can create absolute urls properly.
Robert Scanlon (Jul 12 2021 at 18:39):
Both situations use the same copy of the inferno container, which is smart enough to pay attention to the X-Fowarded-Proto header if it is available. We just may not make it available in the docker-compose in 'inferno-program' if you terminate SSL in front of the nginx server.
Robert Scanlon (Jul 12 2021 at 18:59):
This is hard-coding https, instead of relying on the actual schemed used, but since I couldn't figure out how to get the nginx->jetty to use http (which would involve diving into jetty and ruby), I'm satisfied with this solution for now.
Could you try having Apache send the x-forwarded-* headers to nginx instead? I think nginx may just pass them through automatically, but I'm not sure. Something like this (disclaimer, I just found this on StackOverflow, I have not configured Apache in a long time)
RequestHeader set X-Forwarded-Proto "https"
or dynamically
RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
If you are sure that Apache is sending that, and it appears that nginx is stripping them instead of passing them through, we can upgrade our nginx config on inferno-program to make sure that it allows those headers through.
Robert Scanlon (Jul 12 2021 at 19:10):
Separately, have you had any problems with tests appearing to hang if they run for longer than a certain duration, but if you refresh the page the results continue to be updated? Be aware that Inferno requires long-running connections to receive updates on tests during a test run, and if the server closes the connection the test progress bar will stop updating. Some of the other lines in our nginx config file are there to make sure that nginx doesn't time-out the connection. I do not know if Apache needs anything like that too. Not a huge deal, since you can just keep refreshing the page to get updated results, but it is not a good user experience.
Last updated: Apr 12 2022 at 19:14 UTC
