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

Parameterise runtime image #1478

Merged
merged 7 commits into from Apr 14, 2022
Merged

Parameterise runtime image #1478

merged 7 commits into from Apr 14, 2022

Conversation

omBratteng
Copy link
Contributor

@omBratteng omBratteng commented Dec 17, 2021

Description

Adds a build-arg for setting which docker image to be used as runtime.

Motivation and Context

Enables future implementation of building distroless versions of the oauth2-proxy docker image.

How Has This Been Tested?

Checklist:

  • My change requires a change to the documentation or CHANGELOG.
  • I have updated the documentation/CHANGELOG accordingly.
  • I have created a feature (non-master) branch for my PR.

@omBratteng
Copy link
Contributor Author

I am unfamiliar what Name Service Switch does, and if it works as intended in a distroless image.

Another thing I noticed when doing this PoC, is the line COPY . . is making the layer caching a tad bit ineffective.
Since any changes I do, forces Docker to start from the line, which is not necessary if I e.g. just change a line in the Dockerfile below that line.
Now, the building of the binary is quite fast, so not much time is lost.

@JoelSpeed
Copy link
Member

Since any changes I do, forces Docker to start from the line, which is not necessary if I e.g. just change a line in the Dockerfile below that line.

There are a couple of things we could do here, either we can add more files to the .dockerignore or we can change the COPY to be more specific. I'm not sure whether we can tell the copy just to include go files recursively or not, that may make things a little better

Dockerfile Outdated
@@ -37,12 +37,11 @@ RUN case ${TARGETPLATFORM} in \
GOARCH=${GOARCH} VERSION=${VERSION} make build && touch jwt_signing_key.pem

# Copy binary to alpine
FROM alpine:3.15
FROM gcr.io/distroless/static-debian11:nonroot
Copy link
Member

Choose a reason for hiding this comment

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

I would expect to publish a separate image so that we maintain the old alpine image for those that rely on it. Is there a way we can parameterise this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There is, I will take a look and update the PR

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've parameterised the runtime image, so it's possible to adjust which image to be used in the make file.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Which would you prefer to be default, distroless or alpine image?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Just a question, is it necessary to create a separate tag for different platforms? The $(DOCKER_BUILDX_X_PLATFORM) -f Dockerfile -t $(REGISTRY)/oauth2-proxy:${VERSION} . does cover all of them in one

Copy link
Member

Choose a reason for hiding this comment

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

At the moment, we can only push one version right? Perhaps we need a separate target that pushes a set of distroless tags?

For now I think the default should remain as alpine so that it's not a surprising change to users

Dockerfile Outdated Show resolved Hide resolved
@omBratteng
Copy link
Contributor Author

Since any changes I do, forces Docker to start from the line, which is not necessary if I e.g. just change a line in the Dockerfile below that line.

There are a couple of things we could do here, either we can add more files to the .dockerignore or we can change the COPY to be more specific. I'm not sure whether we can tell the copy just to include go files recursively or not, that may make things a little better

If I’m not mistaken, the .dockerignore would not help with layer caching. But I will do some more testing in that regards, could be another PR down the line.

Dockerfile Show resolved Hide resolved
Copy link
Member

@JoelSpeed JoelSpeed left a comment

Choose a reason for hiding this comment

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

Looks good, lets add a changelog entry and in particular I would like to see an important note denoting the change in the UID:GID for the file

Dockerfile Show resolved Hide resolved
Comment on lines +47 to +50
# UID/GID 65532 is also known as nonroot user in distroless image
USER 65532:65532
Copy link
Member

Choose a reason for hiding this comment

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

Do we expect users will be relying on the existing user number? We probably won't consider this a breaking change but we should definitely add an important note to the changelog for this

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 really doubt it would break for anyone. Only if they've added some restrictions to what UIDs can start processes on the host machine.

But a note in the changelog about the change sounds good.

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've added an entry under Important Notes

  • #1478 Changes the UID and GID of the runtime user to 65532.
    Which also is known as nonroot user in distroless images.

@omBratteng omBratteng changed the title Use distroless debian11 docker image Parameterise runtime image Feb 24, 2022
@omBratteng
Copy link
Contributor Author

Not exactly sure how you want to release the docker images and the following changes required in the Makefile, so I have changed the PR title to Parameterise runtime image, and is ready for proper review.

@omBratteng omBratteng marked this pull request as ready for review February 24, 2022 18:48
@omBratteng omBratteng requested a review from a team as a code owner February 24, 2022 18:48
Makefile Show resolved Hide resolved
DOCKER_BUILDX_ARGS ?=
DOCKER_BUILDX := docker buildx build ${DOCKER_BUILDX_ARGS} --build-arg VERSION=${VERSION}
DOCKER_BUILDX := docker buildx build ${DOCKER_BUILDX_ARGS} --build-arg VERSION=${VERSION} --build-arg RUNTIME_IMAGE=${DOCKER_BUILD_RUNTIME_IMAGE}
DOCKER_BUILDX_X_PLATFORM := $(DOCKER_BUILDX) --platform ${DOCKER_BUILD_PLATFORM}
DOCKER_BUILDX_PUSH := docker buildx build --push ${DOCKER_BUILDX_ARGS} --build-arg VERSION=${VERSION}
Copy link
Member

Choose a reason for hiding this comment

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

The new build args will need to be added here as well else the push won't recognise the cached builds/won't have the correct RUNTIME_IMAGE

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 moved it to DOCKER_BUILDX_ARGS, as it's used in both DOCKER_BUILDX and DOCKER_BUILDX_PUSH

Copy link
Member

@JoelSpeed JoelSpeed left a comment

Choose a reason for hiding this comment

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

Apologies for the delay in getting back to this, LGTM

@JoelSpeed JoelSpeed merged commit 2e9c30a into oauth2-proxy:master Apr 14, 2022
@omBratteng omBratteng deleted the distroless-dockerimage branch April 14, 2022 14:10
@polarctos polarctos mentioned this pull request Sep 5, 2023
3 tasks
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

2 participants