Change:
<ins> # Copyright 2015 The Kubernetes Authors All rights reserved. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # #     http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. # This is the Zeppelin *build* image. It spits out a /zeppelin.tgz # alone, which is then copied out by the Makefile and used in the # actual Zeppelin image. # # 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. FROM maven:3.3.3-jdk-8 ENV ZEPPELIN_TAG  v0.5.5 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} # 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 RUN git clone https://github.com/apache/incubator-zeppelin.git --branch ${ZEPPELIN_TAG} /opt/zeppelin RUN cd /opt/zeppelin &&  mvn clean package  -Pbuild-distr  -Pspark-${SPARK_MINOR} -Dspark.version=${SPARK_VER}  -Phadoop-${HADOOP_MINOR} -Dhadoop.version=${HADOOP_VER}  -Ppyspark  -DskipTests &&  echo "Successfully built Zeppelin" RUN cd /opt/zeppelin/zeppelin-distribution/target/zeppelin-* &&  mv zeppelin-* zeppelin &&  tar cvzf /zeppelin.tgz zeppelin </ins>

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.