search

bloomberg / goldpinger

Debugging tool for Kubernetes which tests and displays connectivity between nodes in the cluster.
Apache License 2.0
2.51k stars 179 forks source link

Upload a docker image to a public registry #27

Closed twexler closed 5 years ago

twexler commented 5 years ago

Currently blocks #21

albf commented 5 years ago

Related: Quickstart would also benefit from better instructions. After running the first command:

$ go get github.com/bloomberg/goldpinger/cmd/goldpinger
$ goldpinger --help

The "Goldping version" seems to be an empty string and now users have to look for more information since matching the versions used for the Docker image and the CLI seems important.

My suggestions/ideas:

Interesting tool, by the way.

seeker89 commented 5 years ago

You're making fair point.

All three are good suggestions. We are a little restraint considering the docker hub, for compliance reasons, but let's see what we can do.

Interesting tool, by the way.

Thanks, appreciate it !

twexler commented 5 years ago

@albf Thanks for the feedback!

Push an official stable version to docker hub. Provide a ready to use stable binary.

We're definitely actively working to get a docker image published publicly, hence this issue. As for a ready-to-use binary, that's a good idea (imho)

Use helm or add a way for deploying a default configuration with the CLI (maybe calling kubectl or generating the required recipes) instead of the "make your own YAML" approach. (#21, basically)

Yeah, that's definitely what we're going to do with #21. We need to tackle this issue first.

XBeg9 commented 5 years ago

@seeker89 what's wrong with docker hub? :) why you can't publish image there?

seeker89 commented 5 years ago

@seeker89 what's wrong with docker hub? :) why you can't publish image there?

@kpfleming will be able to give you more details on that.

Use helm or add a way for deploying a default configuration with the CLI (maybe calling kubectl or generating the required recipes)

Actually, something like this would be nice, self-contained and pretty easy to add.

goldpinger --generate-yaml --image docker.io/something/goldpinger:1.1.0 | kubect apply -f -
kpfleming commented 5 years ago

Our company policy is that we do not publish images on DockerHub because we do not have a good way to satisfy the source code delivery obligations of the licenses on the software contained in the images, and we don't want to be responsible for producing updated images to address security vulnerabilities.

ivkalita commented 5 years ago

@seeker89 

goldpinger --generate-yaml --image docker.io/something/goldpinger:1.1.0 | kubect apply -f -

it looks very similar to ksonnet approach 😄 image

jkroepke commented 5 years ago

Our company policy is that we do not publish images on DockerHub because we do not have a good way to satisfy the source code delivery obligations of the licenses on the software contained in the images, and we don't want to be responsible for producing updated images to address security vulnerabilities.

@kpfleming If your go binary is static you can build images FROM scratch. So your image does only contain your go app nothing more.

kpfleming commented 5 years ago

In the specific case of Go, you are correct that the situation is better than it would be for other applications. It's not just 'your application' in the binary, though, it's your application plus the Go runtime and any other Go modules on which your application depends.

jkroepke commented 5 years ago

OK.

If this is your view of things ...

kpfleming commented 5 years ago

I'm certainly willing to consider this specific request if we can document the dependencies (and their licenses/obligations) thoroughly; obviously the dependencies themselves are already known, but I'm not familiar enough with the Go build system to know whether license information will be harvested from them.

@seeker89 is it possible to build an image for this tool starting from the 'scratch' base?

seeker89 commented 5 years ago

This is precisely how we're building it (and what the documentation suggests).

If it's about computing the dependencies trees.and extracting their licences, unfortunately judging by the reaction to https://github.com/golang/dep/issues/1855 it doesn't look like dep will support that any time soon.

A 10 second search does reveal some other, promising-looking options, like https://github.com/pmezard/licenses for example. On Wed, 2 Jan 2019 at 17:52, Kevin P. Fleming notifications@github.com wrote:

I'm certainly willing to consider this specific request if we can document the dependencies (and their licenses/obligations) thoroughly; obviously the dependencies themselves are already known, but I'm not familiar enough with the Go build system to know whether license information will be harvested from them.

@seeker89 https://github.com/seeker89 is it possible to build an image for this tool starting from the 'scratch' base?

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/bloomberg/goldpinger/issues/27#issuecomment-450933048, or mute the thread https://github.com/notifications/unsubscribe-auth/AAdUOr4Un7skTQLpLV-EqA4FSytF4DIfks5u_PHDgaJpZM4ZcRPn .

-- Mikolaj Pawlikowski

audip commented 5 years ago

Howdy @seeker89, any updates on this?

We are maintaining a fork of this project to build it on GCR, but an official docker hub image will help us delete our fork and rely on the releases of goldpinger.

seeker89 commented 5 years ago

Howdy. We made some progress, hopefully shouldn't take long from here. Fingers crossed 🤞

kpfleming commented 5 years ago

I'm working on this now as I'll need to manage the credentials on the Travis-CI end of things.

seeker89 commented 5 years ago

This has now been done via https://github.com/bloomberg/goldpinger/pull/55

You can now grab a prebuilt image from https://hub.docker.com/r/bloomberg/goldpinger/tags with a simple docker pull bloomberg/goldpinger