Docker images for each service

[b5]

We should be providing docker images for each cloud service. Doing rust + containers the right way should lead to super small production images in a multi-stage build with a much more full-featured build image.

Not having these is blocking contributions like n0-computer/iroh#440.

• decide on a multi-stage build / prod image that'll work for each service, start with the store service as an example
• build out each service image
• make sure the iroh CLI can be configured to talk to those images
• do a one-off for iroh-one that puts everything in one image

[gotjoshua]

Thanks for thinking this through @b5 !

I think adding a check box for making these images not root user configurable is also an important addition

I like the idea that someone from the team takes this on.

[b5]

I like the idea that someone from the team takes this on.

Roger that. I'll assign to myself as a start 😄 .

I think adding a check box for making these images not root user configurable is also an important addition

Just to confirm what you mean by this, I'm assuming you mean any iroh service binaries within production images should only have execute permissions for a non-root user, correct? I'd make an iroh user and iroh group that can execute. Sound good?

[gotjoshua]

an iroh user and iroh group that can execute. Sound good?

well, that is a great start!

annnd, its really cool to also offer build options to configure the uid and gid for that user. This provides the advantage that one can make a matching user on the host machine, set restrictive perms, and see the user name in the host when watching processes with (b)top.

linuxserver images and bitnami images use different strategies, but both offer their reasons.

[b5]

update on this, we now have a working docker-compose example on main: https://github.com/n0-computer/iroh/blob/main/docker/docker-compose.yaml

PR that landed the work: n0-computer/iroh#501

@gotjoshua, I'd love it if you could take a look at the dockerfiles, and ideally give that docker-compose setup a try. It's working will for me locally, but would be great to confirm. I'd also like to get your input on the prod image user. It doesn't have all the flexibility of uid/gid build options, but does follow idiomatic patterns for running as nonroot on distroless.

I'm marking this as closed, please feel free to open new issues as we work on our docker story

[Winterhuman]

@b5 Just in case, does the docker-compose file make sure not to expose any API to the public? (it's hard to tell if this is an issue for grpc or not) This was a previous issue with Kubo's docker-compose file and caused it's API to be publicly accessible: ipfs/kubo#8773

Kubo's current docker-compose file: https://github.com/ipfs/kubo/blob/master/docker-compose.yaml

[b5]

oh this is a very good idea. We don't currently do this, and should. I'll open an issue. Thanks @Winterhuman!