I'm glad these tools work for you and I hope the community keeps making them, I just threw in my perspective.
I'm glad these tools work for you and I hope the community keeps making them, I just threw in my perspective.
Why?
1. Because you end up with a more complex Dockerfile. I've seen curls, clones etc during build - having a remote call for random tools in our build _feels_ like a bad practice.
2. There is also the issue that a fleet of application servers will have different tooling available, which can be frustrating in a pinch. I've done some gnarly things across many hosts, expecting a common set of tools. At AWS, we were responsible for non-nuclear team's services during oncall and would ssh to their boxes. Logging into a box with a different shell would be annoying.
[2] > for i in `cat hosts.txt`; do ssh $i '...'; done
For companies whose main activity is processing data, various build pipelines (not necessarily compiles) might be what production servers do all day.
To answer you, I meant on a Docker image build step- which is where you’d want to install the tool so it’s accessible to people debugging the application during the container run context.