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:

  • Docker calling unit tests
  • Docker 1.9 overlay network - access from host
  • Docker, what is it and what is the purpose
  • How to setup unit test in Docker for nodejs application?
  • docker + haproxy on mac 10.11.5 doesn't work
  • Proxy request through Apache host to docker container
  • 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?


  • Gitlab & Mattermost OAUTH Time out
  • Bluemix Kubernetes docker deployment query
  • How to warmup application inside Docker Container?
  • Grails 3.1.4 and Docker - grails commands return “No profile found for name web”
  • Extending Rancher's Auth-service to use other (OAuth) provider
  • Golang Mac OSX build for Docker machine
  • 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.