Docker support - just keep it simple! Follow
This isn't a support request, and it isn't an issue... it's the result of trying to work with PyCharm's docker support since it first came out, up until giving up on it yesterday.
The Docker support follows a common pattern in JetBrains IDEs. The IDE tries to do everything for you, and hides the details deep inside, without logs or configuration. It's the same as remote debugging support - unless you dig deep, deep into a problem, you don't realise that the IDE is trying to set up listening sockets on the remote interpreter, or that it invokes your Python code via a complex debug wrapper. When it works, this pattern is great. When it fails, it's truly bad.
Docker support is the same. Building support for a very, very simple use case that can be met with one Dockerfile is easy... but the real world doesn't have simple use cases. We have a complex multi-tier app that runs three different sorts of containers, with supporting services, and PyCharm fails badly. I can describe my setup with a docker-compose file, but PyCharm doesn't use that file - it augments it with a separate "hidden" file (you have to go searching in ~/Library/Caches/PyCharm/tmp to find it), and then complains about illegal characters in those files. It does open ports for the service you're debugging, so working on a webserver becomes almost impossible. Starting multiple interpreters sometimes works. The Python console starts but is actually dead, only failing if you try to type into it. And none of this shows useful errors in the PyCharm logs, so reporting issues is an awkward exercise.
So I gave up. Docker for Mac allows me to run containers with sshd, and tell PyCharm that they're remote ssh-based interpreters. Suddenly everything works again. I can debug. I can get my work done.
So hey, JetBrains - you make great software, much of the time. I spend my working life in PyCharm, and I pay you for it. But please, stop trying to build big, complex docker support. Expose what the IDE does - let us edit the docker commands in use. Document how the debugger is supposed to operate. Log what's happening so we can help you with issues. And above all - keep it simple. Docker already runs. You don't have to bury it all, deep in the IDE.
Please sign in to leave a comment.
This. A hundred time this.
Working with docker compose (and even remote debugging) in Pycharm is such a PITA, i feel like half the money I'm paying for it is wasted. The only advantages over Sublime for me is the fancy introspection, refactoring and coding shortcuts. MysqlWorkbench comes for free you know..
It's so useless for me that I :
- cant run a console and the dev server together (since it decided to enforce its service ports always open rule)
- cant run multiple consoles together. Again, because of the dumb assumption above.
- cant run tests, cause since it decided to kill all your containers, who knows what will happen now?
Run the docker machine inside the IDE and that's 15 minutes gone trying to give CPR to the IDE lest it hangs and dies. And i work on a 16GB core i5 mac, which seems to be good enough for kitematic. But no... Pycharm HAS TO MAKE 76+ CONTAINERS CAUSE HELL YEAH DOCKER SUPPORT BABY!
Now one might argue that maybe my container setup is wrong, or that maybe I should persist my containers data somehow and make it a fault tolerant setup. To this I ask, really? Why the hell is my IDE my supervisord now? When my startup is falling through the sky trying to hack together a plane, why did my team decide to use Pycharm? To help us, or make life harder?
And if the answer is just don't use that feature, then great! Let me just open my 10 other terminal windows now in the next workspace, and I'll get back to you.
Part of the reason I bought Pycharm was because of its advertised in-place terminal, remote debugging and basically replacing the terminal capabilities. Things that are completely unusable for folks with docker/compose.
I am still a user, at the end of the day, cause the other stuff works so well. But if there ever comes up another IDE, with similar ease of use but workable docker support, well, I know whom my money is going to..
@Ben you mention "Docker for Mac allows me to run containers with sshd". Do you have a link to more information about that?
I build the main image with a standard Dockerfile (we base on Ubuntu 16). I then run a bash script that generates an SSH keypair (or uses an existing one), and builds a second Docker image that installs and configures `openssh-server`. Here's an example: https://gist.github.com/benlast/b95d568ff61cc4c0b88de35e7aafe931
Once that's done, I can manually run the ssh server image as a container (I generally do this using docker-compose) and then tell PyCharm that the remote interpreter is available via ssh to localhost, using the generated key to authenticate.
I can also ssh into that same sshd server from a terminal to run stuff directly, or to keep an eye on memory or cpu load via `htop`.
We'd never deploy that sshd server image to production, of course, but it lets us develop and test in the same Docker environment that we run for production.
I still find JetBrain's approach to Docker support frustrating; the ssh setup is more complex, but it has the advantage that it gives me back control of how I configure and run my containers, without having to work through the IDE's flaky and unreliable tools.
@ben thanks for this! I still had an hour or two of headscratching to do, this is the complete solution that worked for me.
@gabe thanks for posting that! I could say that I left the full solution as an exercise for the student, but the truth is that I was way too busy to rip out a proof-of-concept from one of our already-excessive Dockerfiles:)
Hey, posting this wherever I can to share
I tried to debug through PyCharm with docker-compose on Ubuntu and ended up making it work with a remote Docker interpreter:
1. Enable docker remote API: following this article http://www.virtuallyghetto.com/2014/07/quick-tip-how-to-enable-docker-remote-api.html I did from my terminal "$ sudo vim /etc/default/docker" and replaced the line which starts with "#DOCKER_OPTS" and replaced it with "DOCKER_OPTS='-H tcp://0.0.0.0:2376 -H unix:///var/run/docker.sock'" and saved the file. Then, I did "$ service docker restart"
2. Add loopback interface to 10.0.2.2: following the comment by ameriks in https://youtrack.jetbrains.com/issue/IDEA-153973 by doing from terminal (to make it persistent after boot) "$ sudo vim /etc/network/interfaces" and I appended to the file this:
iface lo:0 inet static
name Ethernet alias LAN card
And saved it. After so, I did "$ /etc/init.d/networking restart"
3. Configure remote docker-compose debugger in PyCharm - after the first two steps, this was just pointing the docker-compose.yml and choosing the container I wanted to debug.
After these steps I was able to debug through PyCharm
Agree with everything said here - I am about ready to give up on their docker-compose support - just refreshing the skeletons it killed all the containers in my stack, and then it looks like it's stuck. One of our other engineers ran into the 76+ container issue, it's just really bad. It's obvious the PyCharm team doesn't use docker/docker-compose in their day to day development.
+1. Even the support article doesn't cover entirely how to set it up.
Thank you for this issue... I know that it post about Mac OS, but on linux i get so many problems too. And i hate docker-machine. I spend 2 month in my life for setup normal working docker in PyCharm in Linux. I think I alone with this problems, but no... Thank you for you post and for your solution. I will be use ssh and forgot fot pycharm docker problems.
This has still not been fixed by Jetbrains. You're lack of support is quickly forcing my team to a decision point: Abandon Docker or abandon PyCharm. Guess which way management will have us go....
Come on, guys, this is docker, not some obscure, out of the way, weirdness.
I'm under serious pressure from pointy-hairs to stop holding up progress with our enterprise docker projects because some "tool" doesn't work with it.
I already went through much pain and embarrassment with those same pointy hairs when we found lack of support for making things in the browser work with the env vars found in a heroku build. Now this. What on earth is the PyCharm team doing buy building things on their own machines, unlike the rest of the paying world....
Docker! As it becomes the industry standard for deployments, it is kind of a surprise how difficult it is with the leading IDE to setup a docker-compose for standard testing of an app. Please make it happen asap.