googlecontainertools / distroless

🥑 Language focused docker images, minus the operating system.

"Distroless" Container Images.

"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.

For more information, see this talk (video).

Since March 2023, Distroless images use oci manifests, if you see errors referencing application/vnd.oci.image.manifest.v1+json or application/vnd.oci.image.index.v1+json, update your container tooling (docker, jib, etc) to latest.

Why should I use distroless images?

Restricting what's in your runtime container to precisely what's necessary for your app is a best practice employed by Google and other tech giants that have used containers in production for many years. It improves the signal to noise of scanners (e.g. CVE) and reduces the burden of establishing provenance to just what you need.

Distroless images are very small. The smallest distroless image, gcr.io/distroless/static-debian11, is around 2 MiB. That's about 50% of the size of alpine (~5 MiB), and less than 2% of the size of debian (124 MiB).

How do I use distroless images?

These images are built using bazel, but they can also be used through other Docker image build tooling.

What images are available?

The following images are currently published and updated by the distroless project (see SUPPORT_POLICY for support timelines)

Debian 12

Image	Tags	Architecture Suffixes
gcr.io/distroless/static-debian12	latest, nonroot, debug, debug-nonroot	amd64, arm64, arm, s390x, ppc64le
gcr.io/distroless/base-debian12	latest, nonroot, debug, debug-nonroot	amd64, arm64, arm, s390x, ppc64le
gcr.io/distroless/base-nossl-debian12	latest, nonroot, debug, debug-nonroot	amd64, arm64, arm, s390x, ppc64le
gcr.io/distroless/cc-debian12	latest, nonroot, debug, debug-nonroot	amd64, arm64, arm, s390x, ppc64le
gcr.io/distroless/python3-debian12	latest, nonroot, debug, debug-nonroot	amd64, arm64
gcr.io/distroless/java-base-debian12	latest, nonroot, debug, debug-nonroot	amd64, arm64, s390x, ppc64le
gcr.io/distroless/java17-debian12	latest, nonroot, debug, debug-nonroot	amd64, arm64, s390x, ppc64le
gcr.io/distroless/nodejs18-debian12	latest, nonroot, debug, debug-nonroot	amd64, arm64, arm, s390x, ppc64le
gcr.io/distroless/nodejs20-debian12	latest, nonroot, debug, debug-nonroot	amd64, arm64, arm, s390x, ppc64le

Debian 11

Image	Tags	Architecture Suffixes
gcr.io/distroless/static-debian11	latest, nonroot, debug, debug-nonroot	amd64, arm64, arm, s390x, ppc64le
gcr.io/distroless/base-debian11	latest, nonroot, debug, debug-nonroot	amd64, arm64, arm, s390x, ppc64le
gcr.io/distroless/base-nossl-debian11	latest, nonroot, debug, debug-nonroot	amd64, arm64, arm, s390x, ppc64le
gcr.io/distroless/cc-debian11	latest, nonroot, debug, debug-nonroot	amd64, arm64, arm, s390x, ppc64le
gcr.io/distroless/python3-debian11	latest, nonroot, debug, debug-nonroot	amd64, arm64
gcr.io/distroless/java-base-debian11	latest, nonroot, debug, debug-nonroot	amd64, arm64, s390x, ppc64le
gcr.io/distroless/java11-debian11	latest, nonroot, debug, debug-nonroot	amd64, arm64, s390x, ppc64le
gcr.io/distroless/java17-debian11	latest, nonroot, debug, debug-nonroot	amd64, arm64, s390x, ppc64le
gcr.io/distroless/nodejs18-debian11	latest, nonroot, debug, debug-nonroot	amd64, arm64
gcr.io/distroless/nodejs20-debian11	latest, nonroot, debug, debug-nonroot	amd64, arm64

These images refer to image indexes with references to all supported architectures. Architecture specific images can be directly referenced using an additional architecture suffix on the tag, like gcr.io/distroless/static-debian11:latest-amd64

Any other tags are considered deprecated and are no longer updated

How do I verify distroless images?

All distroless images are signed by cosign. We recommend verifying any distroless image you use before building your image.

Keyless

Distroless images are signed with cosign in keyless mode, this is the only supported mechanism starting November 2023. You can verify the keyless signature of any distroless image with:

cosign verify $IMAGE_NAME --certificate-oidc-issuer https://accounts.google.com  --certificate-identity [email protected]

Key (DEPRECATED)

Verifying using the distroless keys is deprecated in favor of keyless. These signing events are not uploaded to the transparency log. You can use the distroless public key to verify any distroless image with:

Images built after November 2023 will not be verifiable with cosign.pub, use keyless signature verification

cat cosign.pub
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZzVzkb8A+DbgDpaJId/bOmV8n7Q
OqxYbK0Iro6GzSmOzxkn+N2AKawLyXi84WSwJQBK//psATakCgAQKkNTAA==
-----END PUBLIC KEY-----

cosign verify --key cosign.pub $IMAGE_NAME --insecure-ignore-tlog

Entrypoints

Note that distroless images by default do not contain a shell. That means the Dockerfile ENTRYPOINT command, when defined, must be specified in vector form, to avoid the container runtime prefixing with a shell.

This works:

ENTRYPOINT ["myapp"]

But this does not work:

ENTRYPOINT "myapp"

For the same reasons, if the entrypoint is set to the empty vector, the CMD command should be specified in vector form (see examples below). Note that by default static, base and cc images have the empty vector entrypoint. Images with an included language runtime have a language specific default (see: java, nodejs, python3).

Docker

Docker multi-stage builds make using distroless images easy. Follow these steps to get started:

• Pick the right base image for your application stack. We publish the following distroless base images on gcr.io:

  • gcr.io/distroless/static-debian12
  • gcr.io/distroless/static-debian11
  • gcr.io/distroless/base-nossl-debian12
  • gcr.io/distroless/base-nossl-debian11
  • gcr.io/distroless/base-debian12
  • gcr.io/distroless/base-debian11
  • gcr.io/distroless/java11-debian11
  • gcr.io/distroless/java17-debian12
  • gcr.io/distroless/java17-debian11
  • gcr.io/distroless/cc-debian12
  • gcr.io/distroless/cc-debian11
  • gcr.io/distroless/nodejs18-debian12
  • gcr.io/distroless/nodejs18-debian11
  • gcr.io/distroless/nodejs20-debian12
  • gcr.io/distroless/nodejs20-debian11
  • gcr.io/distroless/python3-debian12

• The following images are also published on gcr.io, but are considered experimental and not recommended for production usage:

  • gcr.io/distroless/python3-debian11

• Write a multi-stage docker file. Note: This requires Docker 17.05 or higher.

  The basic idea is that you'll have one stage to build your application artifacts, and insert them into your runtime distroless image. If you'd like to learn more, please see the documentation on multi-stage builds.

Examples with Docker

Here's a quick example for go:

# Start by building the application.
FROM golang:1.18 as build

WORKDIR /go/src/app
COPY . .

RUN go mod download
RUN CGO_ENABLED=0 go build -o /go/bin/app

# Now copy it into our base image.
FROM gcr.io/distroless/static-debian11
COPY --from=build /go/bin/app /
CMD ["/app"]

You can find other examples here:

• Java
• Python 3
• Go
• Node.js
• Rust

To run any example, go to the directory for the language and run

docker build -t myapp .
docker run -t myapp

To run the Node.js Express app node-express and expose the container's ports:

npm install # Install express and its transitive dependencies
docker build -t myexpressapp . # Normal build command
docker run -p 3000:3000 -t myexpressapp

This should expose the Express application to your localhost:3000

Bazel

For full documentation on how to use bazel to generate Container images, see the bazel-contrib/rules_oci repository.

For documentation and example on how to use the go-based debian package manager (current) to generate bazel config, see ./debian_package_manager For documentation and examples on how to use the bazel package manager rules (not used in this repo), see ./package_manager

Examples can be found in this repository in the examples directory.

Examples with Bazel

We have some examples on how to run some common application stacks in the /examples directory. See here for:

• Java
• Python 3
• Go
• Node.js

See here for examples on how to complete some common tasks in your image:

• Adding and running as a non-root user
• Including Debian Packages
• Including CA certificates

See here for more information on how these images are built and released.

Base Operating System

Distroless images are based on Debian 11 (bullseye) and Debian 12 (bookworm). Images are explicitly tagged with Debian version suffixes (e.g. -debian11). Specifying an image without the distribution will currently select -debian11 images, but that will change in the future to a newer version of Debian. It can be useful to reference the distribution explicitly, to prevent breaking builds when the next Debian version is released.

Operating System Updates for Security Fixes and CVEs

Distroless tracks the upstream Debian releases, using Github actions to automatically generate a pull request when there are updates.

Debug Images

Distroless images are minimal and lack shell access. The :debug image set for each language provides a busybox shell to enter.

For example:

cd examples/python3/

edit the Dockerfile to change the final image to :debug:

FROM gcr.io/distroless/python3-debian12:debug
COPY . /app
WORKDIR /app
CMD ["hello.py", "/etc"]

then build and launch with an shell entrypoint:

$ docker build -t my_debug_image .

$ docker run --entrypoint=sh -ti my_debug_image

/app # ls
BUILD       Dockerfile  hello.py

Note: If the image you are using already has a tag, for example gcr.io/distroless/java17-debian11:nonroot, use the tag debug-<existing tag> instead, for example gcr.io/distroless/java17-debian11:debug-nonroot.

Note: ldd is not installed in the base image as it's a shell script, you can copy it in or download it.

Who uses Distroless?

• Kubernetes, since v1.15
• Knative
• Tekton
• Teleport

If your project uses Distroless, send a PR to add your project here!

Community Discussion

• distroless-users Google Group
• Kubernetes slack #distroless channel

distroless's Issues

Create a first-class deb WORKSPACE rule

This rule should make it easier for users to depend on debs from package repositories without needing to use http_file.

For UX, we should consider something like:

deb_package(
  name = 'openssl',
  version = '1.0.1f-1ubuntu2.22'
)

How should the apt sources fit in here though? Maybe we could add a list of those to the deb_package rule, or create another type of rule to reference apt sources, and depend on those in dep_package?

Write deb manifest data from the package_manager rule in the built container image somehow

@mattmoor you had some ideas here I believe?

Basically we need a sharded manifest, where each package we unpack dumps it's version/metadata right?

Where should we stick this?

Add a Groovy example

I believe the blocker I hit before should be resolved by: bazelbuild/rules_groovy#8

Missing the latest

Hi Matthew,

I attended you session at SwampUp and wanted to try distroless: As Python is the thing for me, I started with Python27. Unfortunately, Docker refuses to pull it - it claims there's no image tagged latest.

The base image and the Java image works fine.

Regards,
Lars

Docker image scan vulnerabilities

I found no other guideline for how to report this, so creating an issue. Doing a vulnerability scan on images extending gcr.io/distroless/base in hub.docker.com reveals:

glibc 2.19-18+deb8u10 LGPL:Lgpl License
CVE-2017-15670 Critical
CVE-2017-15804 Critical
CVE-2017-15671 Major

E.g. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15671

Setup automated builds to GCR

Missing dependencies in python2.7 image

The python2.7 image installs the following packages:

        packages["zlib1g"],
        packages["python2.7-minimal"],
        packages["libpython2.7-minimal"],
        packages["libpython2.7-stdlib"],

However, libpython2.7-stdlib depends on more: (note - this is from the debian:jessie-backports image, which already has some packages that distroless doesn't - eg libreadline6).

The following extra packages will be installed:
  libexpat1 libffi6 libpython2.7-minimal libsqlite3-0 libssl1.0.0 mime-support
Recommended packages:
  file

Are these dependencies intentionally excluded? Should/could the deb extractor check dependencies or is this out-of-scope?

I ran into this while trying to use defusedxml inside a container: tiran/defusedxml#10

Test failure on Mac OS

Running the tests for //base:certs_test fails on Mac OS:

$ bazel test --test_output=errors //base:certs_test
INFO: Found 1 test target...
FAIL: //base:certs_test (see /private/var/tmp/_bazel_hwright/817cf73ae050ac2393ca14df34010263/execroot/distroless/bazel-out/darwin_x86_64-fastbuild/testlogs/base/certs_test/test.log).
INFO: From Testing //base:certs_test:
==================== Test output for //base:certs_test:
+ base/check_certs_image
Loaded image ID: sha256:aa3c5ff77b6399ac44c46c4932f6dc34756744117a007d297f6122a9091d3ef6
Tagging aa3c5ff77b6399ac44c46c4932f6dc34756744117a007d297f6122a9091d3ef6 as bazel/base:check_certs_image
+ ../runtimes_common/structure_tests/ext_run -i bazel/base:check_certs_image -c base/testdata/certs.yaml
Using default tag: latest
latest: Pulling from gcp-runtimes/structure_test
Digest: sha256:eaa3d87858f06447663029e08b6d5166c73d40b9a7b7880e5eea9a57dd762faf
Status: Image is up to date for gcr.io/gcp-runtimes/structure_test:latest
2017/11/14 15:18:17 Running tests for file /cfg/certs.yaml
--- FAIL: TestAll (0.00s)
    --- FAIL: TestAll/Command_Test:_certs (0.00s)
    	structure_test_v1.go:171: Executing: [/check_certs]
    	structure_test_v1.go:194: Error running command: fork/exec /check_certs: exec format error. Continuing.
    	structure_test_v1.go:200: Command failed to start! Unable to retrieve error info!
	structure_test.go:45: Total tests run: 1
FAIL
================================================================================
Target //base:certs_test up-to-date:
  bazel-bin/base/certs_test
INFO: Elapsed time: 12.790s, Critical Path: 12.44s
//base:certs_test                                                        FAILED in 12.4s
  /private/var/tmp/_bazel_hwright/817cf73ae050ac2393ca14df34010263/execroot/distroless/bazel-out/darwin_x86_64-fastbuild/testlogs/base/certs_test/test.log

Executed 1 out of 1 test: 1 fails locally.
$

I suspect this is because the host toolchain is used to build the test binary, which on Mac OS produces Mach-O binaries, whereas the docker environment expects Linux-type elf binaries. A possible solution would be to use a cross compiler to build for the appropriate target platform, no matter the host. A cursory reading of the latest rules_go release suggests they now have better toolchain and crosscompiler support: https://github.com/bazelbuild/rules_go/releases/tag/0.7.0

Why busybox 1.21?

In WORKSPACE you manually pull in a busybox binary from a remote source for the debug image. However you don't use a recent version, but one from 2013 (https://busybox.net/downloads/binaries/1.21.1/).

Why?

nodejs distroless contains 14MB tar archive

In the nodejs distroless image, it seems that the extraced nodejs/ folder contains a (potentially) unnecessary .tar.gz.tgz archive that isn't in the original unpacked tar for the nodejs release. Here are the commands I ran to verify that this .tar.gz.tgz is being added into the image:

$ docker save gcr.io/distroless/nodejs -o distroless-nodejs-latest.tar
$ mkdir tar-dir; cd tar-dir
$ tar -xvf ../distroless-nodejs-latest.tar
$ cd f3949351cf4b78aa05b57646d2d7da70 # the layer w/ nodejs
$ mkdir layer-tar; cd layer-tar
$ tar -xvf ../layer.tar
$ cd nodejs
$ ls -lh
total 14M
drwxr-x--- 2 aprindle eng 4.0K Dec 31  1969 bin
-r-xr-x--- 1 aprindle eng  287 Dec 31  1969 BUILD.bazel
-r-xr-x--- 1 aprindle eng  55K Dec 31  1969 CHANGELOG.md
drwxr-x--- 3 aprindle eng 4.0K Dec 31  1969 include
drwxr-x--- 3 aprindle eng 4.0K Dec 31  1969 lib
-r-xr-x--- 1 aprindle eng  59K Dec 31  1969 LICENSE
**-r-xr-x--- 1 aprindle eng  14M Dec 31  1969 node-v6.10.3-linux-x64.tar.gz.tgz**
-r-xr-x--- 1 aprindle eng  20K Dec 31  1969 README.md
drwxr-x--- 5 aprindle eng 4.0K Dec 31  1969 share
-r-xr-x--- 1 aprindle eng  107 Dec 31  1969 WORKSPACE

How to deal with pip installs

A lot of current Python based containerized apps make use of pip to install module dependencies.

The Python example makes use of https://github.com/google/subpar and I guess we could also use grumpy to get a binary. This works in relatively simple cases but becomes quite complex when we need thirdparty modules.

A practical distroless python example would show how to deal with pip install foo

Add a python base

tag and make a release

Could you tag the repo and make a github release, so that we can load the package_manager rules remotely ?

Right now your python image for example has a build that assumes local package_manager rules.

as much as I understand bazel :(

Python does have xz in its standard library

https://docs.python.org/3/library/lzma.html

Just read the comment in cacerts.sh (https://github.com/GoogleCloudPlatform/distroless/blob/master/cacerts/extract.sh) that you wanted to write this in Go or Python - so in case you want to write this as a standalone script, it is easily possible since Python 3.3.

Problems creating docker entrypoint with '--' as last argument

Hi,

I'd really like to create a few base containers which can be used in production, but i couldn't get entrypoint of the docker_build rule in bazel to work properly.

Every time i need a closing '--' in an docker entrypoint bazel removes it and outputs an empty array, generating invalid docker metadata which docker refuses to load.

Is there a workarround i simply do not know in bazel to get this to work?

Generated metadata:

% cat bazel-bin/init/init-base.config
{"architecture": "amd64", "author": "Bazel", "config": {"Entrypoint": ["/tini", []], "User": "user"},
                                                                                ^^^

bazel log output

exec ${PAGER:-/usr/bin/less} "$0" || exit 1
-----------------------------------------------------------------------------
+ init/init-base
Skipping 2115094ee05658502a4cc9c28712baf34771c16b3de76f4a33499b463b8d7db5, already loaded.
Skipping 59fcdb78566467803b3ace1801501ca8b6754e55abe23d737be5a4245c1f21ea, already loaded.
Loading d58de6f97f4bb229e55abb7d6a13fbaf19590dc39b8939b66ede14fb6cd2e841...
json: cannot unmarshal array into Go value of type string
Use --strategy=TestRunner=standalone to disable sandboxing for the failing actions.

Bazel BUILD file example

docker_build(
    name = "init-base",
    base = "//base:base",
    entrypoint = ["/tini", "--"],
    tars = [
        ":tini.tar",
        ":init_passwd.passwd.tar",
    ],
    user = "user",
)

Link to my experiment (my redis branch contains both the init and redis container)
https://github.com/mgit-at/distroless/blob/redis/init/BUILD#L28

package_manager support for specific versions of packages

In using the distroless/package_manager, I can't seem to find a way to pull specific versions of a package. Is there a method currently to pull specific versions of a package? Thanks.

Support .NET distroless

FR to support coreCLR distroless builds once we actually support coreCLR in bazel

FWIW, here's a sample coreCLR distroless build where the coreCLR binary is generated outside of bazel

Python 3

Having a python 3 distro would make many machine learning tasks easier!

Feature Request: Anaconda Python 3

A distroless version of Anaconda Python 3 will make life much easier for many data science applications!

Building images requires installing `gcloud`

On a fresh clone of the git repository, on a clean vm of one's choice, building a distroless image requires first installing the gcloud commandline tool. It seems that print-workspace-status.sh is using gcloud for something:

$ bazel build python2.7:python27
INFO: Found 1 target...
ERROR: Process exited with status 127: Process exited with status 127.
./print-workspace-status.sh: line 8: gcloud: command not found
Target //python2.7:python27 failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 107.303s, Critical Path: 0.05s
$

This would appear to be an extraneous dependency. We should consider removing it.

Incorporate cacerts into base.

I think it makes sense for our base to contain cacerts by default.

wrong build dates for provided images (47 years ago)

when pulling the current images, the build date says 47 years ago, e.g.:

$ docker images
REPOSITORY                 TAG                 IMAGE ID            CREATED             SIZE
gcr.io/distroless/nodejs   latest              3a4657735d4c        47 years ago        73.7MB
gcr.io/distroless/base     latest              60e504d8f1de        47 years ago        15.7MB

$ docker -v
Docker version 17.09.0-ce, build afdb6d4

Add a copyright/boilerplate presubmit test.

Genrule for generating busybox.tar is broken on non Linux

I'm trying to build a docker image on my mac laptop and push it to a locally running linux VM, where I will run it. When trying to build //base:debug and run it I found that it fails to run because /busybox/sh doesn't exist.

This is because there are multiple issues which are broken about //busybox:busybox.tar

• It doesn't check errors from commands that it runs and so if they don't run it silently passes.
• It attempts to run the busybox on the host machine even though busybox may not be built for the host configuration.
• It uses a value from srcs as a tool, which is not supposed to be done. https://docs.bazel.build/versions/master/be/general.html#genrule

This means that when building from a mac it 'successfully' builds but is lacking all the right symlinks.

Add a WAR / jetty example

e.g. https://github.com/mattmoor/java-docs-samples/blob/master/flexible/helloworld/docker/BUILD#L8

Add language linters to travis

We should add linters for our language specific examples and the extra code that we may have in this repo. Probably the two biggest ones are gofmt and a python linter. Maybe flake8 or pylint? I'm not sure the standard for python projects.

Busybox not working in debug CC image on GKE

If I try to use busybox inside the gcr.io/distroless/cc:debug image on GKE, I get the following error:

> ls /
ls: can't open '.': Value too large for defined data type

Listing individual files (eg ls /etc/passwd) works. It also works fine if I run on a local minikube cluster. I haven't seen any other surprising problems.

Cluster description:

• Zone: europe-west1-c
• Size: 1
• Total cores: 4 vCPUs
• Total memory: 15.00 GB
• Node version: 1.7.8-gke.0

Repro

This assumes kubectl is already set up to use a GKE cluster.

> kubectl version
Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.2", GitCommit:"bdaeafa71f6c7c04636251031f93464384d54963", GitTreeState:"clean", BuildDate:"2017-10-24T19:48:57Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"7+", GitVersion:"v1.7.8-gke.0", GitCommit:"a7061d4b09b53ab4099e3b5ca3e80fb172e1b018", GitTreeState:"clean", BuildDate:"2017-10-10T18:48:45Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}
> kubectl run testdep --image=gcr.io/distroless/cc:debug --command -- sleep 999999
deployment "testdep" created
> kubectl exec -it testdep-3687734506-mp5c7 sh 
/ # ls
ls: can't open '.': Value too large for defined data type
/ # command terminated with exit code 1
> kubectl delete deployment testdep

Document that go apps need "CGO_ENABLED=0" to work

[Question] Docker multi-stage builds with Bazel

Hi,

I'm looking for best practices to build a nodejs Docker container using Bazel.
Ideally I would use a two-stage docker build (first to build node modules + compile, second to add the compiled assets). However, I can't find how to do that using Bazel.
Is this possible?

Best,

Olivier

Add a test to ensure node.js/grpc works with our glibc

There have been some issues with node.js and grpc with alpine and other minimal containers. We should make sure it works here.

dpkg/dpkg_src re-design / update and security

Hi,

after a short look into dpkg/dpkg_src i'm still not sure how they are thought to be used (securely).

They do not validate signatures, they do not check the hash of packages and download from http, which all in all excludes them IMHO from use on production infrastructure.

Additionally i find it strange, that a core part of distroless now creates non-repeatable builds as neither a fixed version number is used nor a hash checked.

Thus i propose to split out what dpkg/dpkg_src currently does in skylark rules into an external script which just modifies/updates the WORKSPACE file to update packages and uses normal http_file declarations.
This would fix all the problems introduced with the current dpkg/dpkg_src rules and further clearly show what changed with debian dependencies in the repository diff.

This external tool then could also properly validate the signatures and provide secure download of debian packages with a sha256 sum it should automatically include (i can provide help with this if you want)

An additional nice feature would be to add an additional link to the same debian package in the http_file rule to point to http://snapshot.debian.org/, because mirrors typically don't hold on old packages for long.

btw... if it's really the case that currently no security check/validation is done on the included debian packages what so ever, then the last versions of distroless images currently on gcr.io should be considered compromised and be removed ASAP.

base: wrong permissions of /tmp

/tmp should have the permissions 01777
the created tmp diretory has 755

so ony root can write to tmp, any app running with other permissions fails

sudo docker run -ti bazel/busybox:debug 
/ # ls -l /
total 24
drwxr-xr-x    2 1000     1000          4096 Jan  1  1970 busybox
drwxr-xr-x    5 root     0              360 Jul 20 14:57 dev
drwxr-xr-x    1 root     0             4096 Jul 20 14:57 etc
drwxr-xr-x    1 root     0             4096 Jan  1  1970 lib
drwxr-xr-x    2 root     0             4096 Jan  1  1970 lib64
dr-xr-xr-x  238 root     0                0 Jul 20 14:57 proc
dr-xr-xr-x   13 root     0                0 Jul 19 12:38 sys
drwxr-xr-x    2 root     0             4096 Jan  1  1970 tmp
drwxr-xr-x    1 root     0             4096 Jan  1  1970 usr

What would it take to add "apk" extraction to `docker_build`

In the pursuit of tiny images, udeb came up, but wasn't sufficient for the JRE.

We should consider whether simply using APK provides smaller footprints.

Here's where pkg_tar is extracting the deb's data: https://github.com/bazelbuild/bazel/blob/master/tools/build_defs/pkg/build_tar.py#L147

Basic java app does not seem to be able to resolve its own hostname

I have tried running this up inside k8s with Java applications we have. They cannot resolve their own hostname into an ip. I have confirmed by having the Java app "cat" the /etc/hosts file is in the /etc/file, and it is there.

For some weird reason, many Java libraries (such as Jedis, Quartz, Mule, etc) get very upset if they can't determine what their hostname's ip is.

This isn't necessarily an "issue" - it may be by design, but I cannot find any reference to it, so I thought I should ask if it was intended.

http_file should use sha256

in WORKSPACE, sorry for setting a bad example in my prototype :)

request to have debian package tzdata in distroless/base

Not sure if other language runtimes use this, but the Go time package does. It would be nice if at least the directory /usr/share/zoneinfo and files under it are packaged into distroless/base.

Add a tips/tricks doc to the README with info on how to do common Dockerfile tasks

• How to do the equivalent of adduser
• How to create extra directories
• How to install a deb
• How to find all the transitive dependencies of a deb

Add a Scala example

e.g. https://github.com/mattmoor/bazel-glibc/blob/master/java/examples/BUILD#L25

bazel test only finishes one test successfully per run

hi,

i know the subject reads strange, but after observing the this problem on my laptop and also on a fresh instance of ubuntu 16.04LTS on GCP i thought i should report it.

Fresh build without cache works beautifully

$ bazel build ...
INFO: Found 39 targets...
INFO: Elapsed time: 25.746s, Critical Path: 7.28s

But bazel test does not work

$ bazel test ...
INFO: Found 30 targets and 9 test targets...
FAIL: //base:certs_test (see /home/gebi/.cache/bazel/_bazel_gebi/c1cea03837e172d9edf04f24bd390468/execroot/distroless/bazel-out/local-fastbuild/testlogs/base/certs_test/test.log).
FAIL: //examples/java:hello_test (see /home/gebi/.cache/bazel/_bazel_gebi/c1cea03837e172d9edf04f24bd390468/execroot/distroless/bazel-out/local-fastbuild/testlogs/examples/java/hello_test/test.log).
FAIL: //java:java8_test (see /home/gebi/.cache/bazel/_bazel_gebi/c1cea03837e172d9edf04f24bd390468/execroot/distroless/bazel-out/local-fastbuild/testlogs/java/java8_test/test.log).
FAIL: //examples/nodejs:hello_test (see /home/gebi/.cache/bazel/_bazel_gebi/c1cea03837e172d9edf04f24bd390468/execroot/distroless/bazel-out/local-fastbuild/testlogs/examples/nodejs/hello_test/test.log).
FAIL: //examples/nonroot:passwd_test (see /home/gebi/.cache/bazel/_bazel_gebi/c1cea03837e172d9edf04f24bd390468/execroot/distroless/bazel-out/local-fastbuild/testlogs/examples/nonroot/passwd_test/test.log).
INFO: Elapsed time: 7.420s, Critical Path: 3.67s
//base:base_test                                                         PASSED in 2.9s
//busybox:debug_test                                                     PASSED in 2.2s
//package_manager:parse_metadata_test                                    PASSED in 0.1s
//python2.7:python27_test                                                PASSED in 2.9s
//base:certs_test                                                        FAILED in 1.7s
  /home/gebi/.cache/bazel/_bazel_gebi/c1cea03837e172d9edf04f24bd390468/execroot/distroless/bazel-out/local-fastbuild/testlogs/base/certs_test/test.log
//examples/java:hello_test                                               FAILED in 3.6s
  /home/gebi/.cache/bazel/_bazel_gebi/c1cea03837e172d9edf04f24bd390468/execroot/distroless/bazel-out/local-fastbuild/testlogs/examples/java/hello_test/test.log
//examples/nodejs:hello_test                                             FAILED in 3.6s
  /home/gebi/.cache/bazel/_bazel_gebi/c1cea03837e172d9edf04f24bd390468/execroot/distroless/bazel-out/local-fastbuild/testlogs/examples/nodejs/hello_test/test.log
//examples/nonroot:passwd_test                                           FAILED in 2.9s
  /home/gebi/.cache/bazel/_bazel_gebi/c1cea03837e172d9edf04f24bd390468/execroot/distroless/bazel-out/local-fastbuild/testlogs/examples/nonroot/passwd_test/test.log
//java:java8_test                                                        FAILED in 3.6s
  /home/gebi/.cache/bazel/_bazel_gebi/c1cea03837e172d9edf04f24bd390468/execroot/distroless/bazel-out/local-fastbuild/testlogs/java/java8_test/test.log

Executed 9 out of 9 tests: 4 tests pass and 5 fail locally.
There were tests whose specified size is too big. Use the --test_verbose_timeout_warnings command line option to see which ones these are.

A second run managed to successfully finish one more test

$ bazel test ...
FAIL: //base:certs_test (see /home/gebi/.cache/bazel/_bazel_gebi/c1cea03837e172d9edf04f24bd390468/execroot/distroless/bazel-out/local-fastbuild/testlogs/base/certs_test/test.log).
FAIL: //examples/nodejs:hello_test (see /home/gebi/.cache/bazel/_bazel_gebi/c1cea03837e172d9edf04f24bd390468/execroot/distroless/bazel-out/local-fastbuild/testlogs/examples/nodejs/hello_test/test.log).
FAIL: //examples/java:hello_test (see /home/gebi/.cache/bazel/_bazel_gebi/c1cea03837e172d9edf04f24bd390468/execroot/distroless/bazel-out/local-fastbuild/testlogs/examples/java/hello_test/test.log).
FAIL: //examples/nonroot:passwd_test (see /home/gebi/.cache/bazel/_bazel_gebi/c1cea03837e172d9edf04f24bd390468/execroot/distroless/bazel-out/local-fastbuild/testlogs/examples/nonroot/passwd_test/test.log).
INFO: Elapsed time: 2.513s, Critical Path: 2.21s

And for every bazel test ... run one test finishes successfully

As for logfiles, here are 2 example logs:

$ cat   /home/gebi/.cache/bazel/_bazel_gebi/c1cea03837e172d9edf04f24bd390468/execroot/distroless/bazel-out/local-fastbuild/testlogs/examples/java/hello_test/test.log
exec ${PAGER:-/usr/bin/less} "$0" || exit 1
-----------------------------------------------------------------------------
+ examples/java/hello
Skipping 2115094ee05658502a4cc9c28712baf34771c16b3de76f4a33499b463b8d7db5, already loaded.
Skipping 5449844ec8c81fa232f21a132fcde8f675ce0070be01bf7928d462de8707a4d5, already loaded.
Skipping 9253cb0eea928b5673acaee550771fdfede44abaf572a2ea6fdfd4bf742ca078, already loaded.
Skipping 0437ef9cd431a7030fdce21a1d27bdc9a0b7e584fc11f1eda15e95d23728a9f3, already loaded.
Skipping 71152401d8a446d1d16e260ff9e492526bffbea261b7354f263c0a8660fa1069, already loaded.
Tagging 71152401d8a446d1d16e260ff9e492526bffbea261b7354f263c0a8660fa1069 as bazel/examples/java:hello
+ ../runtimes_common/structure_tests/ext_run -i bazel/examples/java:hello -c examples/java/testdata/hello.yaml
Using default tag: latest
latest: Pulling from gcp-runtimes/structure_test
Digest: sha256:eaa3d87858f06447663029e08b6d5166c73d40b9a7b7880e5eea9a57dd762faf
Status: Image is up to date for gcr.io/gcp-runtimes/structure_test:latest
Use --strategy=TestRunner=standalone to disable sandboxing for the failing actions.

$ cat   /home/gebi/.cache/bazel/_bazel_gebi/c1cea03837e172d9edf04f24bd390468/execroot/distroless/bazel-out/local-fastbuild/testlogs/examples/nonroot/passwd_test/test.log
exec ${PAGER:-/usr/bin/less} "$0" || exit 1
-----------------------------------------------------------------------------
+ examples/nonroot/passwd_image
Skipping 2115094ee05658502a4cc9c28712baf34771c16b3de76f4a33499b463b8d7db5, already loaded.
Skipping 5449844ec8c81fa232f21a132fcde8f675ce0070be01bf7928d462de8707a4d5, already loaded.
Skipping 955de1f286d535efb26b379665a40492f22cc1a77a0810cb91af0780f271679f, already loaded.
Tagging 955de1f286d535efb26b379665a40492f22cc1a77a0810cb91af0780f271679f as bazel/examples/nonroot:passwd_image
+ ../runtimes_common/structure_tests/ext_run -i bazel/examples/nonroot:passwd_image -c examples/nonroot/testdata/user.yaml
Using default tag: latest
latest: Pulling from gcp-runtimes/structure_test
Digest: sha256:eaa3d87858f06447663029e08b6d5166c73d40b9a7b7880e5eea9a57dd762faf
Status: Image is up to date for gcr.io/gcp-runtimes/structure_test:latest
Use --strategy=TestRunner=standalone to disable sandboxing for the failing actions.

After executing bazel test ... often enough it finishes all test successfully

$ bazel test ...
INFO: Found 30 targets and 9 test targets...
INFO: Elapsed time: 0.246s, Critical Path: 0.00s
//base:base_test                                                (cached) PASSED in 2.9s
//base:certs_test                                               (cached) PASSED in 1.8s
//busybox:debug_test                                            (cached) PASSED in 2.2s
//examples/java:hello_test                                      (cached) PASSED in 2.1s
//examples/nodejs:hello_test                                    (cached) PASSED in 1.9s
//examples/nonroot:passwd_test                                  (cached) PASSED in 2.0s
//java:java8_test                                               (cached) PASSED in 2.2s
//package_manager:parse_metadata_test                           (cached) PASSED in 0.1s
//python2.7:python27_test                                       (cached) PASSED in 2.9s

Executed 0 out of 9 tests: 9 tests pass.

Maybe someone has an idea why only one test every finishes successfully per bazel test run.

Upgrading node to 8 LTS

Would it be possible to upgrade the nodejs image to run v8 of node?

dpkg rule does not create output reproducibly

If I run the exact same rule today and in three weeks, I might get a completely different version of the specified package.

Please add a hash to the rule, so it is possible to pin down exact versions.

Also it would be nice to be able to specify several package sources, since not all mirrors might keep older versions of packages around.

Clarify examples on what their WORKSPACE would look like if standalone

The examples use the repo WORKSPACE file and the BUILD files for examples rely on that by at least using the shortcut syntax for the in-workspace targets. The examples would be more useful if they would clarify in some way on what their WORKSPACE would look like if each example would be a standalone thing / part of another repo.

Jetty archive needs a sha256

Setup travis for PR testing

We should test:

• That everything builds
• That all bazel tests pass
• That buildifier passes

swamup talk link does not contain more information

I followed the
'For more information, see this talk.'
but I did not notice any new information or link to presentations or video at the destination:
https://swampup2017.sched.com/event/A6CW/distroless-docker-containerizing-apps-not-vms

dpkg rules: Not all package names are valid bazel rule names

In the dpkg rules, the bazel rule name is also the name of the package to be downloaded. Not all package names are valid bazel rule names, e.g.

http_file(
    name = "libstdcpp6",
    sha256 = "f1509bbabd78e89c861de16931aec5988e1215649688fd4f8dfe1af875a7fbef",
    url = "http://deb.debian.org/debian/pool/main/g/gcc-4.9/libstdc++6_4.9.2-10_amd64.deb",
)

Ideally, I'd like to avoid

dpkg(
    name = "libstdc"
    package_name = "libstdc++"
    source = "@debian_jessie//file:Packages.json",
)

document "missing /bin/sh" as needing to use `entrypoint`, instead of `cmd`

This is now a documentation bug. See #62 (comment) for why

With the latest rules_docker (df9d21334be0d45b6995f5f46024a3d2ea22eca9) and bazel 0.5.1, my Go images that are built using a docker_pull of distroless/base and a docker_build target are not working correctly.

When I run my docker_build images using distroless/base locally with docker run without specifying a command argument (that is, using the default command that image is built with) or running it in kubernetes, I get errors about /bin/sh not existing[1][2].

I've put up a reproduction in a GitHub repository. See the README.md there for instructions. I'll describe what's going on a little bit more below.

Previous uses of bazel's docker_build using base images built with the docker command directly did not have this problem. To work around this, I have to duplicate the cmds in my bazel targets and kubernetes Deployments.

(That is, the cmd in the docker_build bazel target is "./hello", and I have to configure that a second time elsewhere in order for these images to work correctly.)

Using the @distroless//base:base external directly (by copying a bunch of the repository set up from distroless's WORKSPACE) causes the same error to occur. (I did not include that version in my reproduction as the bazel BUILD code increase is significant. There is a use_ext branch in my reproduction you can look at, though)

[1] From docker: docker: Error response from daemon: oci runtime error: container_linux.go:247: starting container process caused "exec: \"/bin/sh\": stat /bin/sh: no such file or directory".
[2] From kubernetes: Error response from daemon: Container command '/bin/sh' not found or does not exist..

Go apps which need time zone info fail.

There is no timezone data in the Go distroless container. So calls to time.LoadLocation fail with an error.

Add sh_tests to verify base images work correctly

We probably want to actually run the built images in a docker daemon. We could use an sh_test to load the resulting tar and run some tests.

describe how folks can view all of the images generated

Folks who are new to this might not know how to view all the distroless images available to be used in their browser. In fact, I've forgotten how to do it again in my browser. I had to hand hack my own personal registry URLs in order to figure it out.

It might help to link to https://console.cloud.google.com/gcr/images/distroless/GLOBAL/base or similar explicitly.