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

rebase acme-dns docker image on google distroless #275

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

slippycheeze
Copy link

Improvements over the current Dockerfile are:

It uses the GoogleContainerTools/distroless static image as base,
removing everything from the container including the shell, dynamic
linker, etc.

It builds a fully static acme-dns binary, including static-linking the
CGO components, to be able to run without any dynamic linking, or libc,
on the target system.

It assembles the "release" layout of the application and support
directories on the builder, then copies them wholesale to the
final image.

It only copies the acme-dns binary; it exclused the .git
directory, and all other files, that are shipped in the current image.

It uses a shallow checkout to build, which is appropriate since the
builder is a throw-away image and will be destroyed when the build
process is done.

It uses the latest version of golang 1.*, ensuring that improvements and
security fixes are picked up automatically.

Limitations:

The distroless image doesn't provide anything beyond the bare minimum to run
the static binary – notably, no /bin/sh is present.

If this is a concern the best strategy would be to add a second image,
deploying FROM gcr.io/distroless/static:debug which provides busybod as
/bin/sh and the rest of the standard utilities.

I have not implemented this solution at this time.

Background:

The Google distroless images provide a base for running software containers
with the absolute bare minimum of files. For more details see
https://github.com/GoogleContainerTools/distroless

This bases the acme-dns docker image off the distroless "static" image,
gcr.io/distroless/static, which is suitable for running fully static
application in languages like go – it has no dynamic linker.

Improvements over the current Dockerfile are:

It uses the GoogleContainerTools/distroless static image as base,
removing everything from the container including the shell, dynamic
linker, etc.

It builds a fully static acme-dns binary, including static-linking the
CGO components, to be able to run without any dynamic linking, or libc,
on the target system.

It assembles the "release" layout of the application and support
directories on the builder, then copies them wholesale to the
final image.

It *only* copies the `acme-dns` binary; it exclused the `.git`
directory, and all other files, that are shipped in the current image.

It uses a shallow checkout to build, which is appropriate since the
builder is a throw-away image and will be destroyed when the build
process is done.

It uses the latest version of golang 1.*, ensuring that improvements and
security fixes are picked up automatically.

Limitations:

The distroless image doesn't provide anything beyond the bare minimum to run
the static binary – notably, no `/bin/sh` is present.

If this is a concern the best strategy would be to add a second image,
deploying `FROM gcr.io/distroless/static:debug` which provides busybod as
`/bin/sh` and the rest of the standard utilities.

I have not implemented this solution at this time.

Background:

The Google distroless images provide a base for running software containers
with the absolute bare minimum of files.  For more details see
https://github.com/GoogleContainerTools/distroless

This bases the acme-dns docker image off the distroless "static" image,
`gcr.io/distroless/static`, which is suitable for running fully static
application in languages like go – it has no dynamic linker.
@slippycheeze
Copy link
Author

note: tested locally, but only on x86 / amd64 platforms.

linuxgemini added a commit to linuxgemini/acme-dns that referenced this pull request Feb 9, 2022
Co-authored-by: Daniel Pittman <[email protected]>
Signed-off-by: İlteriş Yağıztegin Eroğlu <[email protected]>
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

1 participant