Add debugpy to Dockerfile for service containers #239
Conversation
|
Do we need documentation for configuring a Helm chart/Kubernetes resources, such that the documentation for how to remote debug can be added to it? Or can we defer to the developer guide/ helm create? I don't know how beginner friendly I really need to be to enable people with less experience to get involved here. |
template/Dockerfile.jinja
Outdated
| ENTRYPOINT ["python" "-m"] | ||
| # Allows for modifying the ENTRYPOINT for debugging, e.g. | ||
| #ENTRYPOINT ["python", "-m", "debugpy", "-m"] | ||
| CMD ["{{ repo_name }}", "--version"]{% endif %} |
There was a problem hiding this comment.
While we're at this, should we remove --version as the default use of the container is far more likely to be "run the cli", not "check the version of the cli"?
| CMD ["{{ repo_name }}", "--version"]{% endif %} | |
| CMD ["{{ repo_name }}"]{% endif %} |
There was a problem hiding this comment.
I vote to leave the Dockerfile as something that exits successfully and make it obvious how to modify it.
I think that depends how DLS specific the guide is. If it can be made generic then it probably belongs in the copier template, but if not then the developer portal is better. |
|
I am going to test out these new docs by following them along. |
|
Does not as hoped support hot swapping of code through the debugpy protocols |
Adds debugpy to the container that is built for deploying services with.
This, along with documenting how to make use of it when deploying with e.g. Kubernetes, will allow for remote debugging of the code, and provide a standard approach to solve #234