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

Use distroless for runtime images? #19

Open
cpswan opened this issue May 7, 2021 · 4 comments
Open

Use distroless for runtime images? #19

cpswan opened this issue May 7, 2021 · 4 comments

Comments

@cpswan
Copy link
Contributor

cpswan commented May 7, 2021

GoogleContainerTools/distroless

"Distroless" images contain only your application and its runtime dependencies. They do not contain package managers, shells or any other programs you would expect to find in a standard Linux distribution.

The main benefit would seem to be image signing with cosign, though BusyBox might come in handy at times.

@subfuzion
Copy link
Collaborator

We have a PR for the docs for the official image where we document how to use a scratch image to be about as lightweight as possible for the final image. Without a shell, etc, is there some other advantage to using distroless (since it's around ~19 MB) as the base image of the final image?

@cpswan
Copy link
Contributor Author

cpswan commented May 17, 2021

We're already using FROM scratch to have a minimal run image. The two things that distroless brings to the party that might justify its extra bulk are:

  1. Image signing - which perhaps gets more important as we deal with supply chain attacks and provenance of a software bill of materials (SBOM)
  2. BusyBox for debugging.

PS Nice job getting the runtime dependencies tidily arranged in the build image :)

@subfuzion
Copy link
Collaborator

subfuzion commented May 18, 2021

Thanks! So I think we could probably provide an example in the distro repo, but that's really all we'd be providing there, similar to the Dockerfile example for Go.

Even without a published example, you can do something like this example (which can probably be improved upon):

FROM dart:stable AS build

# Resolve app dependencies.
WORKDIR /app
COPY pubspec.* ./
RUN dart pub get

# Copy app source code and AOT compile it.
COPY . .
# Ensure packages are still up-to-date if anything has changed
RUN dart pub get --offline
RUN dart compile exe bin/server.dart -o bin/server

# Build minimal serving image from AOT-compiled `/server` and required system
# libraries and configuration files stored in `/runtime/` from the build stage.
FROM gcr.io/distroless/base
COPY --from=build /app/bin/server /app/bin/

# Start server.
EXPOSE 8080
CMD ["/app/bin/server"]

Note that you can attach a debugging container, like in shown for this redis example in the Docker docs:

If you really want a shell in the container, you would have to add it to the image or use a different base image, but I don't think we want to maintain another image right now. If you're trying to debug containers and you want to exec a shell in it, or you want more sophisticated remote debugging support, then we recommend using the full development tools image from either dart:stable or dart:beta.

I'm not exactly sure what you mean about image signing and what that has to do with distroless. Are you saying you want us to maintain a signed distroless image?

@cpswan
Copy link
Contributor Author

cpswan commented May 18, 2021

Per the distroless README:

All distroless images are signed by cosign.

Which seems like it would be useful for build provenance.

I think this boils down to - maybe the Golang Googlers are onto something that could be useful to the Dart Googlers?

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