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

Build distroless debug image variants #749

Closed
jzelinskie opened this issue Aug 16, 2022 · 3 comments · Fixed by #750
Closed

Build distroless debug image variants #749

jzelinskie opened this issue Aug 16, 2022 · 3 comments · Fixed by #750
Labels
area/tooling Affects the dev or user toolchain (e.g. tests, ci, build tools) hint/good first issue Someone new could handle this priority/3 low This would be nice to have

Comments

@jzelinskie
Copy link
Member

We currently build SpiceDB container images based on distroless which ships an extremely minimal environment (it doesn't even include a shell). This makes debugging quite difficult if you aren't using a platform with debugging built-in (e.g. Kubernetes has kubectl debug).

Users today could write their own Dockerfiles that copy the SpiceDB binary from our image into a new base image (e.g. Alpine or Debian) to work around this, but it'd require that build their own images.

We could offer variants of our images using the distroless debug base so that debugging is as simple as changing their image name to authzed/spicedb:$VERSION-debug.

@jzelinskie jzelinskie added hint/good first issue Someone new could handle this priority/3 low This would be nice to have area/tooling Affects the dev or user toolchain (e.g. tests, ci, build tools) labels Aug 16, 2022
@dlorenc
Copy link

dlorenc commented Aug 16, 2022

cc @jdolitsky @imjasonh

@imjasonh
Copy link
Contributor

Adding a debug variant for static that includes busybox would be pretty straightforward. So much so that it already exists at distroless.dev/busybox 😄

It should be pretty easy to swap out the base image with a --build-arg and tag a new authzed/spicedb:$VERSION-debug based on distroless.dev/busybox. Let me know if that sounds good, and I can start sending PRs.

@jzelinskie
Copy link
Member Author

That sounds good to me. Just make sure you check out the goreleaser configuration first -- it uses the Dockerfile.release environment to copy built binaries into. I'm not sure if there's a better way to do this, but in the ideal case we'd have only a single Dockerfile.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/tooling Affects the dev or user toolchain (e.g. tests, ci, build tools) hint/good first issue Someone new could handle this priority/3 low This would be nice to have
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants