1. #docker
  2. Deprecation of Docker Runtime in Kubernetes - No access to local docker socket

Re: Deprecation of Docker Runtime in Kubernetes - No access to local docker socket #docker #hyperledger-fabric #fabric

Hakan Eryargi
 

Hi Chintan,

It's still possible to use internal builders with containerd runtime in Kubernetes. This is achievable via dind (Docker-in-Docker). 

Actually our Helm charts are supporting this since a while. See this commit: 

It's only a simple setting:
--set peer.docker.dind.enabled=true

Tested again on Azure AKS, Kubernetes version: v1.19.6

We are attaching a sidecar Docker container to peer pod, but this is not necessary. Docker container can reside in a separate pod and can be shared by multiple peers. Actually Docker daemon can even run outside of Kubernetes, as long as peer can access it through TCP. 

A small correction btw, using host's docker.sock is not dind. Dind is running a Docker daemon inside a Docker container.

Cheers,
Hakan


On Tue, Jan 19, 2021 at 2:15 PM <chintanr97@...> wrote:
Correct! With HLF v2.x external builders and chaincode as an external service, we can easily migrate to remove the dependency on usage of docker socket. That is definitely one of the ways!

Apart from this, I wanted a generic call from HLF maintainers on this topic - as it would be affecting all the HLF users to migrate from internal builders to chaincode as an external service. I consider that it might be simple, but it incurs cost in production stages and also multiple channels of communication if the setup is hosted on cloud compared to on-prem. 

I am not sure of the exact deadline we should be looking for from Kubernetes on this, but I think some sort of modification or highlight is required for sure - for everyone to be supported and migrated with ease.

Regards,
Chintan Rajvir

Join fabric@lists.hyperledger.org to automatically receive all group messages.