Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggest replacing Python with Go binary #35

Closed
chuck-alt-delete opened this issue Oct 7, 2021 · 1 comment
Closed

Suggest replacing Python with Go binary #35

chuck-alt-delete opened this issue Oct 7, 2021 · 1 comment

Comments

@chuck-alt-delete
Copy link

I think Christoph Schubert from professional services has already done this, but I don’t see a PR for it. It would be preferable to remove the Python dependency and opt for static Go binaries instead. This reduces the size and attack surface area of the docker images. Reach out to Christoph for more information.

@andrewegel
Copy link
Contributor

It would be preferable to remove the Python dependency and opt for static Go binaries instead. This reduces the size and attack surface area of the docker images.

"Sort of" - You're merely replacing python with go. Go modules suffer from the same issue, CVEs are disclosed, Go module updates are released that fix it, requiring downstream projects such as this to consume those updates to get around the CVE. That doesn't really address the maintenance problem IMO. Maybe go has a better reputation with respect to CVEs, but at that point, I would then say "Rewrite it in Rust" at that point.

In general I don't see the usefulness of this tool. Using a combination of docker secrets, docker config and the right docker-compose.yaml files (or docker run invocations) you can accomplish the same effect of configuring Confluent Platform's services inside the container to utilize those "mounted" config / secret files instead of having this tricky framework that reads data in from ENV variables passed to the container. About the only thing that couldn't be replicated would he health checks for dependent services (ie: kafka -> zookeeper, schema-registry -> kafka, etc).

But a lot of this has been around since before I started maintaining cp-docker, so theres little chance of this changing in existing releases.

Your inquiry has piqued my interest, but I'm afraid that there are more important features (confluentinc/common-docker#117) to get across the line, and I don't have a lot of resources [1] to develop cp-docker image features any further outside of maintenace and major feature support. I would be happy to look at a fork or anther project of @christophschubert 's though.

[1] https://www.confluent.io/careers/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants