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

Go implementation, resolves #5 #20

Merged
merged 3 commits into from Dec 10, 2017

Conversation

@xfernando
Copy link
Contributor

commented Dec 7, 2017

No description provided.

}

func writeDockerfile(name string) error {
contents := `FROM golang:1.9

This comment has been minimized.

Copy link
@brendandburns

brendandburns Dec 9, 2017

Contributor

Rather than doing it this way, I thought that the right way to do it would be to pull the static binary from argv[0] and just add that to a simple image.

Of course that will only work on Linux, so that's a bit of a limitation, but maybe we can take a go build ... directive as part of the configuration.

I'm not sure that we can assume a specific go project layout.

@brendandburns

This comment has been minimized.

Copy link
Contributor

commented Dec 9, 2017

Thanks for this. When I was thinking about a golang impl, I was thinking that we could just pull the binary name from argv[0]

I'm ok to merge this and iterate from there though, if you prefer.

@xfernando

This comment has been minimized.

Copy link
Contributor Author

commented Dec 9, 2017

I just wanted to get something running quickly since I figured you would only take a look after getting back from kubecon.

I thought a bit about this when doing this first pass. First I tried using the alpine golang image so that the final image could be smaller, but that didn't work because it doesn't have git, so dependencies failed to download with go get. So I decided using the fat image for a first pass to get it working and getting some feedback would be a better approach.

Using a scratch image with just a statically compiled binary is definitely the best option when the project allows it.

However, projects that use cgo and rely on external libraries wouldn't be able to be compiled and deployed on a scratch image.

So maybe this would need to be parameterized in metaparticle somehow? The fewer parameters we have on metaparticle that the user needs to fill in and understand to get it working on his/her project the better, in my opinion.

@brendandburns

This comment has been minimized.

Copy link
Contributor

commented Dec 10, 2017

@xfernando yeah, definitely don't want to slow things down, I want to build excitement!

I'm going to merge this for now, and we can iterate...

Thanks!

@brendandburns brendandburns merged commit 8c92d59 into metaparticle-io:master Dec 10, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.