Hi,
I'm developing a new tracing mode, using kafka. We needed this for our system. I'm planning to sent a PR when it's done completely but it's gonna take a while and there's been issues.
One issue that this topic is for, is that currently I'm using Confluent-kafka-go as my kafka producer, and that depends on librdkafka, which is basically a C library.
But when I try to build traefik, because of CGO_ENABLED=0, the final build would be dynamic and uses this library on the OS that's being run on. The problem arises when we're trying to build for production. Using that Dockerfile that just copies traefik binary to a scratch docker image, this library is not found in that image and therefore the container can't run.
I read about building statically and solutions were either setting CGO_ENABLED=1, or building with -tags static_all flag. As far as I searched, the latter wasn't recommended as it could have some instability issues. The former was that I didn't know the reason behind setting CGO_ENABLED=0.
So the question is, Do we necessarily need to set CGO_ENABLED=0, or is it just for fast building or something? And if we can't set that to 1, then how can we build traefik with this C library in a way that runs and works correctly?
Thanks a lot for your very active community support.
This is an interesting question, to which I'd also like to know an answer. I just wanted to make a few related observations:
Depending on scope, it can get tough to get the PR approved. In order to keep the product quality high, it is inevitable that some PRs has to be reject, and not only if they are of not sufficient quality, but also when they do not mesh with the creators vision of the product. In this light, I would prepare myself for a PR being rejected in the end.
Maintaining a parallel private build of traefik, can be very labour intensive. You will have to merge from upstream often, and the unit and integration tests that they have won't take into account your changes and may clash. Be prepared that any time after merge you spend prolonged amount of finding out why your build is broken, and testing if the result is still works correctly with your features.
Finally, I may be wrong here, but I think that production images of traefik 2.0 are never built from scratch any longer (they used to for 1.x), that could be the reason why dependencies are expected to be available. So to me it looks like the most promising solution to your problem is to NOT change CGO_ENABLED and build an image that contains all the required dependencies.
PS. It is possible that CGO_ENABLED=0 is simply because traefik itself does not need it enabled, so it would be safe to enable it for your purposes if you use an external library, this however needs to be confirmed by the developers. I would imagine that a use of external library like this also could be a reason for declining the PR, if the devs want to keep it "dependency-free".