How do you know what you're getting when you pull an existing Docker image?

When you create your own docker image, you usually start a Docker file with FROM, and base your image off something that already exists on docker hub. How can I learn more about what is actually in the image I am referencing?

For example, I’m interested in starting with this image:

  • Copying file from host to container
  • how to provide environment variables to AWS ECS task definition?
  • insecure-registry in DOCKER_OPTS
  • How to escape Fish shell variable to use as awk pattern?
  • Setting the docker server IP as an environment variable using the gradle-docker-plugin
  • How to add users to docker container running on a vm
  • Besides what’s listed in the description fields on that webpage, how can I verify what is actually getting installed? Is there a way to view a Dockerfile for an existing image on docker hub?


  • Single file volume mounted as directory in Docker
  • Docker: how to work with local files?
  • non-privileged execution FROM scratch
  • Docker Service Separation
  • Using docker volume with a NFS partition
  • How does Docker create environment variables in the container?
  • One Solution collect form web for “How do you know what you're getting when you pull an existing Docker image?”

    Dockerfile links

    Many images, especially “official” images, will contain Dockerfile links. You’ll find them in the description on Docker Hub. For instance, right now at the link you posted in your question, you’ll find a few image tags and a couple of links to Dockerfile.

    3.1.0, 3.1, 3, latest (Dockerfile)

    Simply click on “Dockerfile” and it will take you to the Dockerfile that was used to build that version of the image.

    It should be noted that this is metadata associated with the Docker Hub account. You can’t completely trust that it is correct, because it’s just a link. (To GitHub, in this case, but it can be anywhere.)

    Since you can’t completely trust that, you may want to look also at…

    Docker history

    If you docker pull swift to fetch the image, you can then use the docker history command to take a closer look at it. Currently, that looks like this:

    IMAGE               CREATED             CREATED BY                                      SIZE                COMMENT
    d505ae70cb39        2 weeks ago         /bin/sh -c swift --version                      0B
    <missing>           2 weeks ago         /bin/sh -c SWIFT_URL=   403MB
    <missing>           2 weeks ago         /bin/sh -c #(nop)  ENV SWIFT_PLATFORM=ubun...   0B
    <missing>           2 weeks ago         /bin/sh -c #(nop)  ARG SWIFT_VERSION=swift...   0B
    <missing>           2 weeks ago         /bin/sh -c #(nop)  ARG SWIFT_BRANCH=swift-...   0B
    <missing>           2 weeks ago         /bin/sh -c #(nop)  ARG SWIFT_PLATFORM=ubun...   0B
    <missing>           2 weeks ago         /bin/sh -c apt-get -q update &&     apt-ge...   626MB
    <missing>           2 weeks ago         /bin/sh -c #(nop)  MAINTAINER Haris Amin <...   0B
    <missing>           2 weeks ago         /bin/sh -c #(nop)  CMD ["/bin/bash"]            0B
    <missing>           2 weeks ago         /bin/sh -c mkdir -p /run/systemd && echo '...   7B
    <missing>           2 weeks ago         /bin/sh -c sed -i 's/^#\s*\(deb.*universe\...   2.76kB
    <missing>           2 weeks ago         /bin/sh -c rm -rf /var/lib/apt/lists/*          0B
    <missing>           2 weeks ago         /bin/sh -c set -xe   && echo '#!/bin/sh' >...   745B
    <missing>           2 weeks ago         /bin/sh -c #(nop) ADD file:5aff8c59a707833...   118MB

    You’ll notice that the commands used to build each layer of the image are truncated for display. That makes this display not especially useful, but you can use the --no-trunc flag to get a much more verbose output.

    docker history --no-trunc swift:latest

    Then you will get a lot of output (more than I will paste here), but here is a one-entry sample:

    <missing> 2 weeks ago /bin/sh -c SWIFT_URL=$SWIFT_BRANCH/$(echo "$SWIFT_PLATFORM" | tr -d .)/$SWIFT_VERSION/$SWIFT_VERSION-$SWIFT_PLATFORM.tar.gz && curl -fSsL $SWIFT_URL -o swift.tar.gz && curl -fSsL $SWIFT_URL.sig -o swift.tar.gz.sig && export GNUPGHOME="$(mktemp -d)" && set -e; for key in 7463A81A4B2EEA1B551FFBCFD441C977412B37AD 1BE1E29A084CB305F397D62A9F597F4D21A56D5F A3BAFD3556A59079C06894BD63BC1CFE91D306C6 ; do gpg --quiet --keyserver --recv-keys "$key"; done && gpg --batch --verify --quiet swift.tar.gz.sig swift.tar.gz && tar -xzf swift.tar.gz --directory / --strip-components=1 && rm -r "$GNUPGHOME" swift.tar.gz.sig swift.tar.gz 403MB

    Most of the text is simply the commands executed by Dockerfile RUN statements. You will also see the other Dockerfile commands like ARG, CMD, ADD, COPY, etc.

    Since this is encoded into the image layers, it is probably more reliable (if less readable) than the Dockerfile links found in the Docker Hub readme file.

    Docker will be the best open platform for developers and sysadmins to build, ship, and run distributed applications.