Distroless orchestratord

[alex-hunt-materialize]

Uses distroless as the base image for orchestratord.

Also adds a new function to Composition to pull/build images without launching containers.

Motivation

Smaller and more secure image.

Resolves https://linear.app/materializeinc/issue/CLO-28/migrate-orchestratord-to-distroless

Verification

Ran all the orchestratord tests.

[github-actions]

Thanks for opening this PR! Here are a few tips to help make the review process smooth for everyone.

PR title guidelines

• Use imperative mood: "Fix X" not "Fixed X" or "Fixes X"
• Be specific: "Fix panic in catalog sync when controller restarts" not "Fix bug" or "Update catalog code"
• Prefix with area if helpful: compute: , storage: , adapter: , sql:

Pre-merge checklist

• The PR title is descriptive and will make sense in the git log.
• This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
• If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).

[def-]

This looks interesting! Planning to look into it for environmentd/clusterd too?

[alex-hunt-materialize]

Planning to look into it for environmentd/clusterd too?

I think we should, but those will likely be harder. They subprocess out to other things, like SSH.

[def-]

What is the main motivation for this? I assumed it's to reduce image size, but the image has gotten larger:

• Before: 59 MB https://hub.docker.com/layers/materialize/orchestratord/latest
• After: 102 MB https://hub.docker.com/layers/materialize/orchestratord/mzbuild-6EPEBLVMDFCVZI3IXQVL6VDYE2B5257Y/images/sha256-e52213e2373f08376438509714145a72fae3cfbb77fb5266ac4bec5f545dcf6e

Maybe I'm missing something. Edit: I see, security is also a concern.

[def-]

26 MB, sweet! https://hub.docker.com/layers/materialize/orchestratord/mzbuild-PVPQF24A6HWY5JAFBRTNC4RLHOQQICLX/images/sha256-24914c13098065fe15e6a0ce711a3a906057335fceed19ad01aa1c45c4907eae
About using this: How do you then locally debug if something goes wrong with orchestratord since you can't ssh into it?
Do you plan to look into converting other containers to be distroless? If not, I might be interested in looking into that, we'd gain some CI speedup from smaller images too. I'd probably have to check in with how people in the database team feel about it, since it will make local debugging more annoying from what I can tell.

[alex-hunt-materialize]

About using this: How do you then locally debug if something goes wrong with orchestratord since you can't ssh into it?

You can use an ephemeral container for that (ie: kubectl debug). I've never felt the need to exec into orchestratord, though. It's all in the single rust binary, there isn't much it interacts with in the surrounding container.

Do you plan to look into converting other containers to be distroless? If not, I might be interested in looking into that, we'd gain some CI speedup from smaller images too.

I don't have as much knowledge of what is required for the other containers, so if you want to take that on, be my guest.

I'd probably have to check in with how people in the database team feel about it, since it will make local debugging more annoying from what I can tell.

I think they can use nsenter to get a pretty nice debugging experience. It would be roughly the same as with kubectl debug.