Default configuration yields `502 Bad Gateway`

[GTLangseth]

Using the basic setup, I am getting a 502 error when I visit 127.0.0.1:8443/.

I've tried starting just the postgres and mongo instances first as well as all containers together.

[mjstealey]

It’s been some time since I’ve looked at this repository and I did notice some things that have not aged well…
The OHIF/Viewer code has changed a fair bit since I originally wrote this, and I’d need to do some digging to re-wire things based on their updates.

In the meantime I’ve updated the repository to use an older, but known working tag for the OHIF viewer, and have set all other docker references to be the most recent working version for this configuration.

Starting with a clean clone of the updated repository, all things worked as expected on a CentOS 7 box for me, but depending on your host, you may have to tweak permissions for the database/data related directories that get created.

[twloehfelm]

Really appreciate you sharing this repo Michael. I experienced the same issue as @GTLangseth yesterday. Retried again today with your new versions and worked flawlessly on a Ubuntu 18.04 LTS server. I edited ./nginx/default.conf to replace 127.0.0.1 with the server's IP prior to docker-compose - not sure that was necessary, but it didn't hurt.

[GTLangseth]

Awesome, thanks for the support @mjstealey! I plan to try later this weekend.

[mjstealey]

I experienced the same issue as @GTLangseth yesterday. Retried again today with your new versions and worked flawlessly on a Ubuntu 18.04 LTS server. I edited ./nginx/default.conf to replace 127.0.0.1 with the server's IP prior to docker-compose - not sure that was necessary, but it didn't hurt.

Glad to hear things worked out for you :-)
Always a good idea to use your fully qualified domain name (FQDN) or IP instead of 127.0.0.1 to minimize reverse proxy / redirection issues.
As noted in the README, the viewer container being used is not the most recent one, but it is the one that works with the configuration in this repository. Once I have some cycles to spare I'll go ahead and figure out what's different in the new OHIF Viewer container code.

[GTLangseth]

Also tested on Ubuntu 18.04 LTS and it is working for me! Tried to build locally on macOS Catalina 10.15.2 and ran into the 502 error, which based on your response must have to do with proxy / redirection issues or the default set of macOS system-level permissions. I'm going to trouble shoot to see if there is a quick fix to get running locally in case other users want to develop on macOS but happy it is working for my Ubuntu instance :-) Thanks again for the help!

[ekariz]

Where is the DNS done for the below domains ?
http://orthanc:8042
http://viewer:3000/

[mjstealey]

Where is the DNS done for the below domains ?
http://orthanc:8042
http://viewer:3000/

Locally on the subnet created by Docker Compose.

All containers that are defined within a single docker-compose.yml file will have "knowledge" of each others network routing and can reference one another via their Compose short name.

Using the viewer container as an example, it's defined as:

  viewer:
    image: ohif/viewer:v1.x
    container_name: viewer
    depends_on:
      - mongo
      - orthanc
    restart: always
    networks:
      - frontend
      - backend
#    ports:
#      - 3000:3000
...

And even though the ports mapping section is commented out, the service is still exposed on the subnet named backend where it can be reached by other containers on that same subnet and port.

Had the containers not been defined together in a docker-compose file they'd need to have their docker-based IP address discovered at runtime using a docker inspect call to figure out where they are running. At that point you could modify the /etc/hosts file of each container to be aware of one another. Using Compose makes this easier to do, though not completely transparent as to how it occurs.