Change:
# See the License for the specific language governing permissions and # limitations under the License. <del> # Based heavily on # https://github.com/dylanmei/docker-zeppelin/blob/master/Dockerfile # (which is similar to many others out there), but rebased onto maven # image. # # This image is a composition of the official docker-maven # Docker image from https://github.com/carlossg/docker-maven/ and # spark-base. </del> <ins> # This image relies on the zeppelin-build image to get the zeppelin # binaries built, and the Makefile to put it in this directory. </ins> FROM gcr.io/google_containers/spark-base:latest <del> ENV ZEPPELIN_TAG  v0.5.5 ENV MAVEN_VERSION 3.3.3 ENV SPARK_MINOR   1.5 ENV SPARK_PATCH   1 ENV SPARK_VER     ${SPARK_MINOR}.${SPARK_PATCH} ENV HADOOP_MINOR  2.6 ENV HADOOP_PATCH  1 ENV HADOOP_VER    ${HADOOP_MINOR}.${HADOOP_PATCH} RUN curl -fsSL http://archive.apache.org/dist/maven/maven-3/${MAVEN_VERSION}/binaries/apache-maven-${MAVEN_VERSION}-bin.tar.gz | tar xzf - -C /usr/share  && mv /usr/share/apache-maven-${MAVEN_VERSION} /usr/share/maven  && ln -s /usr/share/maven/bin/mvn /usr/bin/mvn ENV MAVEN_HOME /usr/share/maven # libfontconfig is a workaround for # https://github.com/karma-runner/karma/issues/1270, which caused a # build break similar to # https://www.mail-archive.com/users@zeppelin.incubator.apache.org/msg01586.html RUN apt-get update  && apt-get install -y net-tools build-essential git wget unzip python python-setuptools python-dev python-numpy libfontconfig  && apt-get clean  && rm -rf /var/lib/apt/lists/* RUN git clone https://github.com/apache/incubator-zeppelin.git --branch ${ZEPPELIN_TAG} /opt/zeppelin RUN cd /opt/zeppelin &&  mvn clean package  -Pspark-${SPARK_MINOR} -Dspark.version=${SPARK_VER}  -Phadoop-${HADOOP_MINOR} -Dhadoop.version=${HADOOP_VER}  -Ppyspark  -DskipTests &&  rm -rf /root/.m2 &&  rm -rf /root/.npm &&  echo "Successfully built Zeppelin" </del> <ins> # Expands to /opt/zeppelin/ ADD zeppelin.tgz /opt/ </ins> ADD zeppelin-log4j.properties /opt/zeppelin/conf/log4j.properties ADD zeppelin-env.sh /opt/zeppelin/conf/zeppelin-env.sh ADD docker-zeppelin.sh /opt/zeppelin/bin/docker-zeppelin.sh

Discussion:
The image by is over a gig. Investigate how to trim this down. (Cut out interpretters? Make them more modular somehow, possibly composing them once we have some solution like ?) It's not even clear there's upstream support for making this more modular, though.
cc
remove mvn tooling and all the extra steps, once upstream releases 's like the rest of apache.
I can look at that, but I think I can actually just strip the image of the dev tooling right now. Right now I think the Zeppelin deps themselves are a ridiculous portion of this, though. (I'll poke at it.)
(3) is an install of [bzr git mercurial openssh-client subversion] in the base java image, which seems wasteful to me. you'll have to switch base images to get rid of this. (2) is your install of [curl net-tools build-essential git wget unzip python python-setuptools python-dev python-numpy libfontconfig]. i expect curl is at least redundant, as is git if your using the java image. you should merge this layer w/ (1) and do an uninstall of [python-setuptools python-dev etc] & deps at the end. of course, those are less significant than (1), which is the mvn build. the long term solution here is to use the upstream binaries, when they exist. in the meantime, you should clone zeppelin into tmp, copy out the resulting build artifact and delete the clone. that should at least cut the size of this layer in half, as all the intermediate build artifacts are likely still present and in the final tarball/jar.
I can trim it down some by cutting out the build machinery (and I'll put up a PR shortly), but here's what the looks like: And expanded: (Instead of just deleting, it's actually easy to build, copy out, compose, too.)
Is it me or are all the containers rather large. For example, does spark itself need to be a gig? 1.5.1v3 6 weeks ago 989.7 MB There's some spark binary package that's 73M uncompressed:
Java runtime + baseimage + transitive closer is what is causing most of the bloat. But as we have discussed on other tickets, these images need to move out of the main repository.

I'm afraid I don't understand "transitive closer". For example I see my JDK is around 280M, and the Spark binary is 73M. Then that leaves another 636M for base + whatever. I guess I'll have to look at the imagelayers if I'm really curious.
he means all the dependencies and their dependencies. if you'd like to tackle shrinking the spark image, please open an issue for it. we've done some work on this and you can use the example investigation above to help improve image sizes.