Support private Docker registry

[sebgl]

When using our own private docker registry, we need the swarm cluster to be able to pull images (functions) from it.

Expected Behavior

When a new function service is created in Swarm, images from a private registry should be correctly pulled provided the registry credentials are available somewhere.

Current Behavior

Images cannot be pulled by Swarm workers.

Possible Solution

We can rely on the mechanism provided by the --with-registry-auth flag in the docker stack command, which forwards the registry credentials to all swarm nodes.
When creating a service using the golang Docker sdk, we can pass the appropriate encoded registry auth (base64 encoding of the json string representation).
I have a proposal there, based on environment variables configuration: sebgl@e7d2deb
If you think that makes sense I can open a pull request.

Steps to Reproduce (for bugs)

1. Push function image to a private Docker registry
2. Try to invoke the function with FaaS (making sure the docker image is not already available locally on swarm nodes)

Context

We would like to use FaaS with private Docker registries (not only hub.docker.com but any registry).

Your Environment

• Docker version: Docker 17.05.0-ce

[alexellis]

Hi @sebgl - this request makes sense and I'd like to support private registries.

Questions:

• Can swarm secrets replace the plaintext environmental variables?

• Could you have to support multiple private registries at once? If that were the case how would that be possible with the proposal?

• Do you have a 1-liner to start a private registry with username/password enabled (TLS?)

• Could the existing credentials store be used instead? ~/.docker/config.json

https://github.com/moby/moby/blob/69c35dad8e7ec21de32d42b9dd606d3416ae1566/docs/reference/commandline/login.md#credentials-store

https://github.com/docker/cli/blob/6686ada6a4cf4e872af4d9bf3f61c387be934d87/cli/config/credentials/native_store.go#L60

https://github.com/docker/cli/blob/dee8e6ab2da3fe1f57f57de6c009a9256040d1d0/cli/command/cli.go#L110

[sebgl]

Hi @alexellis , thanks for the quick answer.

My use case (having only one single registry) is a tiny subcase of the more general one.
Since this might interest you: we're basically adding another API in front of the gateway to handle authentication, permissions, etc. This API is also responsible for building and pushing docker images, since we want users to give us code, not docker images. Hence we only need one private registry (ours, not the user's one). For now this is just a prototype, for fun :)

You're right in all questions that this should be handled in a more general way in FaaS gateway.

• Multiple private registries
  Yes ! Should this be a fixed list of allowed registries? Or should users be able to "add" access to new registries whenever they want via the gateway API (can play nice with registry permissions)? The latter seems more interesting but also a bit more complex to handle. I love how small and simple the codebase of FaaS is.

• Credential store & swarm secrets
  Indeed, environment variables do not seem right. Unless I have misunderstood something, we need all deployed gateways to be in possession of all registry secrets, so that they can pass the appropriate one (based on the docker image name prefix) to the swarm service create API.
  Best choice seems to store registries credentials as swarm secrets available from all deployed gateways. Could be as a /run/secrets/config.json file store. I'm just a bit concerned about updating this file if registries can be added/removed at runtime as discussed above.

Another way of handling both points above could be to allow users to provide registry credentials as a parameter in POST /system/functions: then we don't need to store credentials at all. What do you think?

• 1-liner to start a private registry
  That's not exactly one line, but I've set up this gist with instructions: https://gist.github.com/sebgl/3c97c379ddc77c65c44d47e6b745fa10
  Easiest way I found is to spawn a VM somewhere with DNS registered and port 443 open to the world for LetsEncrypt certificates generation, then run the docker-compose file as described in the gist.
  Running with self-signed certificates on localhost with swarm involves more tricks.

[alexellis]

What are you calling your API for building Docker images from code? it sounds like it has overlap with the FaaS CLI - https://github.com/alexellis/faas-cli

Are we already connected on Twitter or Linked in? If you can send me your email address I'll invite you the slack community where we're collaborating around FaaS.

I recently moved the UI under the /ui/ prefix, so that for security you could effectively keep /ui and /system within a blacklist and just expose /function via reverse proxy.

Who are you working with when you say we?

[sebgl]

Let's discuss it on Slack :)

[alexellis]

Fixed by #87