Proposal: solution of docker image for Pod without public registry

[metrue]

Related discussion threads on Kubernetes repo:

• https://github.com/kubernetes/kubernetes/issues/1319
• https://github.com/kubernetes/kubernetes/issues/1668

Problem:

The workflow of the current solution of fx deploy a function to be a service,

You can see that Pod pulls Docker images from the public registry (hub.docker.com) during the Deployment creation and that's why current fx requires DOCKER_USERNAME and DOCKER_PASSWORD since it pushed Docker image to public registry first to make sure the Docker image is ready during the Pod creation.

There are problems in the current solution,

• Requires DOCKER_USERNAME and DOCKER_PASSWORD is bad and inconvenient
• Push Docker image to and Pull Docker image from the public registry is not just because the request from the public registry takes an amount of time but also because the code (Docker image) is private for a user.
• It requires network connected with outside, the deploy process should be able to happen only inside of fx network (Docker environment or Kubernetes environment)

Proposal

To fix the above issue, we should be able to build Docker image inside Kubernetes cluster.

the workflow of a service deployment of fx will be like,

Why this solution works?

• How the source code of function's Docker project passed into InitiContainer

The source code of function's Docker project will be store into ConfigMap, then the InitContainer can read it from ConfigMap.

• Why the InitContainer can build the docker image?

The InitContainer is run Docker container (https://hub.docker.com/_/docker), and mount the /var/run/docker.sock of node into it, then we can invoke docker against the node's Docker daemon, and the image built is store in node.

• The Docker image has to be able accessed on the node the Pod is running on.

Since the InitContiainer (image build) and Container (functional running) is running on same node, so the image built by InitContainer is available for Container.

• The Docker image has to be built before Kubernetes start the functional container (the container of our function is to run on). The image is built in InitContainer (it runs at the initializing stage of the Pod) so the image will be ready before the Kubernetes start the functional container.

Limitation

• ConfigMap has limited on data storage, so the source code function's Docker project could be too big