Change:
docker build -t gcr.io/google_containers/spark-driver driver docker tag gcr.io/google_containers/spark-driver gcr.io/google_containers/spark-driver:$(TAG) <del> zeppelin: </del> <ins> zeppelin-build: docker build -t gcr.io/google_containers/zeppelin-build zeppelin-build docker tag -f gcr.io/google_containers/zeppelin-build gcr.io/google_containers/zeppelin-build:$(ZEPPELIN_TAG) zeppelin: zeppelin-build docker create --name=zeppelin-build-tmp gcr.io/google_containers/zeppelin-build:$(ZEPPELIN_TAG) docker cp zeppelin-build-tmp:/zeppelin.tgz zeppelin docker rm -f zeppelin-build-tmp </ins> docker build -t gcr.io/google_containers/zeppelin zeppelin docker tag -f gcr.io/google_containers/zeppelin gcr.io/google_containers/zeppelin:$(ZEPPELIN_TAG)

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.