Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow for reverse proxies #13

Closed

Conversation

captain-kark
Copy link

Feel free to drop the extra commits for setting up the demo with docker-compose, unless you feel like keeping it around for your own uses.

This is a really cool project, thanks for making it!

This change makes it so that the frontend looks for the already
in-use hostname and path from the user's session, instead of
assuming that they will always be using the default as set up
by web-pdb. Since I'm using a proxy and docker-compose, I can
make the task of finding a debugger on a per-microservice basis
much easier than if everything is assumed to go to

```
ws://localhost:5555/ws
```

for the websocket connection, and

```
http://localhost:5555/frame-data
```

for the actual pdb session state.

Being able to configure nginx to serve back the per-container
version of the installed web-pdb would be great, that way I
could give each service a unique url that developers could
hit to view that service's debugger running.

Otherwise, they have to run commands like `docker-compose ps`,
figure out what port the web-pdb process got set to on the host
machine, and visit that. Being able to go to something like

```
localhost/debuggers/servicename/
```

would be so much nicer!

As an example, here is one of the current microservice's nginx
entries for setting up a proxy to the api itself, and a couple
extra entries for the web-pdb proxies:

```
location /api/v1/service1/ {
  rewrite ^/api/v1/service1/?(.*) /$1 break;
  proxy_pass http://service1_api:5000;
}

location /debuggers/service1/api/ {
  proxy_pass http://service1_api:5555/;
}

location /frame-data {
  proxy_pass http://service1_api:5555/frame-data;
}

location /ws {
  proxy_pass http://service1_api:5555/ws;
  proxy_http_version 1.1;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "Upgrade";
}
```

With this change, you can instead write:

```
location /api/v1/service1/ {
  rewrite ^/api/v1/service1/?(.*) /$1 break;
  proxy_pass http://service1_api:5000;
}

location /debuggers/service1/api/ {
  rewrite ^/debuggers/service1/api/?(.*) /$1 break;
  proxy_pass http://service1_api:5555;
  proxy_http_version 1.1;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "Upgrade";
}
```
To get this going, install docker, and docker-compose.

Make sure you've already built the frontend part of the app by
following the instructions in the README.md file as this
dockerfile doesn't do any building of the js part of the project.

Run

```
docker-compose up
```

To build and install everything.

Once it comes up, you can visit these three urls to see that the
application can be proxied, and still facilitate the expected
user experience:

```
http://localhost/debuggers/tests/db/
http://localhost/debuggers/tests/db_pm/
http://localhost/debuggers/tests/db_ps/
```
@romanvm
Copy link
Owner

romanvm commented Feb 20, 2019

Thank you for your contribution. I will check this out.

@romanvm
Copy link
Owner

romanvm commented Aug 23, 2022

This is sitting here for a long time and I don't see any motivation behind those changes. Could you explain what will this PR achieve? Otherwise it will be closed as stale.

@romanvm romanvm closed this Aug 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants