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

Add Dockerfile for building cloud-sql-proxy images. #296

Merged
merged 7 commits into from Jul 25, 2019
Merged

Conversation

kurtisvg
Copy link
Contributor

Addresses #286

Dockerfile Outdated Show resolved Hide resolved
Dockerfile Outdated Show resolved Hide resolved
Dockerfile Outdated Show resolved Hide resolved
Dockerfile Outdated Show resolved Hide resolved
Dockerfile Outdated Show resolved Hide resolved
Dockerfile Outdated
WORKDIR /go/src/cloudsql-proxy
COPY . .

RUN go get ./cmd/cloud_sql_proxy && go build -ldflags "-X 'main.versionString=$VERSION'" \
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be safer if you don't rely on the libc from the distroless image, and use Go’s static compilation flags.

Most of the time people use this to truly statically compile Go binaries:

 go build -a -tags netgo -ldflags '-w -extldflags "-static"'  ...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why's it safer? The glibc dependency is the most tested and most used in production. Unless there's a concrete reason not to use it, I'd go with the defaults.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only reason would be if someone tries to use this binary like:

FROM this_image AS dep
FROM their_alpine
COPY -from=dep /this_binary /bin

And libc would cause issues

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm going to revert for now - it's probably safer for users to dl the binary from one of the links over pulling it out of this image.

@kurtisvg kurtisvg requested a review from broady July 25, 2019 19:41
Copy link
Contributor

@broady broady left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM after ahmets comments are resolved

Dockerfile Outdated
# Build Stage
FROM golang:1 as build

ARG VERSION="1.14-develop"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does this work? Can we please instead read the version from the git repo?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So right now the git repo isn't using any version, it has to be handed a version when it's compiled (see here)

This changes it so the argument can be passed in during the docker build command, and has a reasonable default so if compiled by hand it lets us know.

@kurtisvg kurtisvg requested a review from broady July 25, 2019 21:29
@kurtisvg kurtisvg merged commit 253d1ed into master Jul 25, 2019
@kurtisvg kurtisvg mentioned this pull request Aug 27, 2019
@amq amq mentioned this pull request Oct 2, 2019
2 tasks
@kurtisvg kurtisvg deleted the dockerfile branch October 10, 2019 21:00
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

Successfully merging this pull request may close these issues.

None yet

4 participants