PyCharm remote debugging support

[thaeli]

This is a WIP. Still needs documentation, updating the .idea files, and possibly better error handling.

However, it's possible to add this locally. Add a remote interpreter to your project, localhost:22 rams/rams and it should Just Work. It does for me.

Note - do NOT deploy this anywhere port 22 is open to the world. The password on the container is pretty trivial in this initial commit.

[binary1230]

This method is fine, though I think you may be able to accomplish the same thing without ssh. You can run commands inside a running container with 'docker exec'. Though I guess if you need directory support to view the files and such then you would still need SSH/SFTP

Pycharm also has some kind of built in docker debugging though never used it

Anyway, this is all solid if it turns out SSH is the way to go, just means you'd be running ssh in production too

[thaeli]

Unfortunately, the only way Pycharm would actually work requires it to ssh and scp/sftp in. (I'm not quite sure which it's doing, but it's one of those) Pycharm's built in docker debugging (which would be docker exec and so forth) doesn't seem to like Docker For Windows. Definitely something to keep an eye on in future releases; they keep adding to PyCharm's Docker support. And it's possible I'm just doing something wrong?

Note that we can actually keep ssh out of production with this too. The ssh daemon is installed in a Dockerfile that ultimately should only be used for developer deployments. This is a good point though; before merging this I should add new instructions to the "how to do a production deployment" documentation with notes about making your own Dockerfile instead of using this development one.

I would still MUCH rather use a separate container that only provides ssh support, but the best option currently available (jeroenpeeters/docker-ssh) doesn't support scp/sftp so Pycharm won't work with it.

Another note: Somehow I've broken access through the load balancer on my local machine with these changes, though the web container itself is serving fine. Will look into that tomorrow.