Openwhisk: publish container images to dockerhub

[seriousme]

Hi,

I managed to get openwhisk running using vagrant. After some fiddling I got the examples to work.
This made me wonder: if the openwhisk specific containers were available on docker hub it would be much easier to give it a spin (e.g. docker-compose up would be enough).
It would have also saved me a truckload of downloads :-)

I also noticed that the images are fairly large, e.g.

• a simple node.js container can be had for about 13 MB instead of the current 400+ MB
• Consul can be had for 18 Mb instead of the current 1347 MB
  etc.

I know that images share layers, but still smaller images are easier to juggle around ;-)

Cheers,
Hans

[domdom82]

Hi @seriousme thanks for your excellent input.

I think it is a great idea to have the stack as compose topology on dockerhub.

Before we do that we should first reduce the image sizes so ppl won't have to download huge chunks.

Most images are based on whisk/scala which itself is pretty large. That itself can be reduced imho.

As for the consul part, we are currently working on moving to ansible for our deployment. During that process we are also looking into ways to reduce overhead on common tools such as consul which we currently build ourselves. So chances are we got rid of that image soon.

[seriousme]

@domdom82 Thanks for the positive feedback :-)

I found a relatively small scala package frolvlad based on Alpine Linux. Now I'm not a Scala expert, so I might be way off here, but alpine-scala is build on alpine-java (oracle jdk) which in turn is build on Alpine.

However if you want to stay main stream there is also a docker java base image which might be used as a starter to a Scala image.

Ideally there would imho be a few docker compose files:

• one that uses cloudant as its DB
• one that uses a couchdb container as its DB (preferably with a separate data volume)

I noticed my repository on the VM also contains a CLI container, I would include that as well in the compose files.

Last point: the couchdb container is the only one started without a predefined name in start-couchdb-box.sh, adding a --name parameter would make it easier to reference it, and it just looks more clean as all the other containers have nice names :-)

Cheers,
Hans

[markusthoemmes]

I've iterated on this a couple of times. Anything actionable that we want to keep from the issue? @domdom82 ?

[skaegi]

I'm also interested in this. Does anyone have a docker-compose file in a repo some where that I might start from?

-- (feeling a bit sheepish) guess I should just start by following the instructions here -- https://github.com/openwhisk/openwhisk/blob/master/tools/macos/README.md

[ddragosd]

In the meanwhile docker-compose support has arrived here: https://github.com/openwhisk/openwhisk-devtools/tree/master/docker-compose . Currently it downloads the code, it compiles it, and it starts an instance of OpenWhisk locally.

[seriousme]

Is there anything site specific in those freshly built containers ?
If not, it would be way more convenient to have the containers uploaded to docker hub and just provide a docker-compose file.
Saves a lot of people the hassle (and CPU cycles) of building openwhisk and the containers.

[ddragosd]

it would be way more convenient to have the containers uploaded to docker hub

👍 @seriousme . Actually docker-compose.yaml is ready for that; there's no build instruction. Once the images are available in Docker Hub we'll skip the build step in the Makefile, leaving it optionally. There's already a separate make docker command in the Makefile that does the build.

At the same time, here's something interesting:

> docker images | grep "whisk/invoker\|whisk/controller\|whisk/nodejs6action\|zoo\|kafka\|openwhisk/apigateway\|consul\|registrator\|redis\|couchdb" | awk '{s+=$7} END {print s " MB"}'
2880.07 MB

[rabbah]

The runtime containers are already on dockerhub fwiw.

[seriousme]

Ehm, docker images looks at your local image cache and not at docker hub AFAIK.

docker search whisk list a whole slew of images with the name whisk in there but no whisk/invoker nor whisk/controller and the whisk/kafka is over a year old (which might be prefectly ok, but I can't tell as the repo description is empty).

Is "whisk" the official open whisk docker repo on docker hub ? I guess not, since the profile points to https://whisk.com/

There is also an openwhisk docker repo (https://hub.docker.com/u/openwhisk/) which seems to be an (the ?) official openwhisk repo, but the profile is rather empty.

It would be nice if the quickstart page ( https://github.com/openwhisk/openwhisk#quick-start) would mention the openwhisk/* containers and ideally point to the compose file so people can skip the whole compilation if they just want to try it out.

[rabbah]

https://hub.docker.com/u/openwhisk is it. @csantanapr we should populate the profile.
Locally images are tagged as whisk - this can be changed via a gradle parameter @markusthoemmes please advise.

[markusthoemmes]

Advisory on its way:

To be able to push to openwhisk we'll need to tag the images accordingly. gradle distDocker -PdockerImagePrefix=openwhisk should do the trick there.

[csantanapr]

https://hub.docker.com/u/openwhisk is it. @csantanapr we should populate the profile.

@rabbah done

[rabbah]

Profile updated yes. But we need to automate the image push or build for our containers.

[seriousme]

Looking at the compose file from the sidelines I notice the following:

The images are required to get a working service are:

• image: couchdb:1.6
• image: wurstmeister/zookeeper
• image: wurstmeister/kafka
• image: consul:v0.7.0
• image: gliderlabs/registrator
• image: whisk/controller:latest
• image: whisk/invoker:latest
• image: redis:2.8
• image: adobeapiplatform/apigateway:1.1.0

I presume whisk would then be replaced by openwhisk however the openwhisk docker repository holds no invoker nor 'controller` image.
It does however hold 2 api-gateway images (??) which are not referenced in the compose file.

Its also a bit remarkable that the setup uses both Zookeeper and Consul, but also both Kakfa and Redis. I can see how it got there (e.g. Kafka needs Zookeeper) but from a distance it looks like the setup can be optimized a bit and the repo can be cleaned up a bit ;-)

[csantanapr]

Profile updated yes. But we need to automate the image push or build for our containers.

@rabbah I was just asking if when you said "profile" you were referring only to the the picture

[csantanapr]

@rabbah I see we have automated builds already for the runtimes.

Why we can't setup invoker and controller in the same way?

[csantanapr]

@seriousme

It does however hold 2 api-gateway images (??) which are not referenced in the compose file.

I clean up one of them there should be only one now openwhisk/apigateway

And docker compose file should be updated to use it https://github.com/openwhisk/openwhisk-devtools/issues/2

[csantanapr]

@seriousme

Its also a bit remarkable that the setup uses both Zookeeper and Consul, but also both Kakfa and Redis.

Redis it's only use by nginx/lua apigateway, this is by design. You can ask questions about Redis usage on that repo, as the SMEs are actively working on the repo and looking at open issues.

[rabbah]

The runtime builds are not automated - I occasionally click the build now button. That's of course not a long term answer. Either automated builds (pull model) or travis does the publishing (push model). I think all our components should have images on docker hub, that's the point of this issue, isn't it?

[markusthoemmes]

@csantanapr Invoker and Controller currently cannot be build automatically because we compile outside of the container. We can certainly change that but there might be sideeffects to consider.

[csantanapr]

The runtime builds are not automated - I occasionally click the build now button.

Why? I configured other images for pulling, I will enable automatic pulling then if there are no objections for the runtimes.

[csantanapr]

@rabbah I see errors in automatic builds for example openwhisk/pythonaction

Build failed: Error: image library/dockerskeleton:latest not found

Here https://hub.docker.com/r/openwhisk/pythonaction/builds/

It tried to build an hour ago

[csantanapr]

@markusthoemmes Would doing the compile with the docker build would have less side effects? then when the image is build/done the code is compiled and the image done, no window for errors if trying to compile in a different environment that can introduce side effects.

[rabbah]

Isn't the easiest path through this to have travis do a travis push/tag at the end of a build from master?

[csantanapr]

Yes let's configure Travis do it. I heard that open source projects from Netflix do the same because they got same problems of custom steps that docker hub build service doesn't handle.

[rabbah]

@csantanapr is this a duplicate of #2017 now?

[csantanapr]

Let's close new one and keep this old one

[csantanapr]

It should be possible to configure Travis to push the docker images for controller, invoker, and runtimes to dockerhub openwhisk.

The push should happen only from master branch, and using Travis credentials to store the dockerhub credentials.

The only thing to be careful is not going over the 50 max time for a travis build.

[seriousme]

A description of the process of building Docker images using Travis can be found at https://sebest.github.io/post/using-travis-ci-to-build-docker-images/