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 host information and cluster
  • Docker exposing ports madness
  • App running in Docker on EB refuses connecting to self
  • How to automatically remove old Docker images?
  • docker postgres failed to start with specified port
  • I can't run rails console with Docker and Passenger/nginx image
  • 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?


  • connect to MySQL database
  • Docker can't expose mesos port 5050
  • Docker Compose with Scale and multiple linked containers
  • how to properly build spring boot docker image using Dockerfile?
  • Docker-compose: get linked container adress inside other container (in bash)
  • Connecting an Oracle DB Container and a Java application Container (Docker)
  • 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.