toggle quoted messageShow quoted text
From what I have found so far in a limited bit of looking into the effects of the deprecation when it actually happens is that it will cause a breaking change to the Dind container. Although there is an alternative, I find it may be cleaner to continue on the path I was going down to use the launcher and then change the CRI runtime from Docker to Containerd for my implementation.
Disclaimer: I have not tested this yet but will post results in this thread.
Using DinD in the short term should work ok, but be aware that you will need to run the Dind container with elevated privileges which can be problematic in many environments. The best course of action is to plan for an upgrade and use a launcher.
On Tue, Apr 27, 2021 at 3:52 PM Chris Gabriel <alaskadd@...
Also, I forgot to mention that when running on Kubernetes I set the environment variable for the CORE_VM_ENDPOINT to “http://localhost:2375
” and not
There is more detail on this if you examine the CORE VM ENDPOINT section of core.yaml
I am still looking into the ramifications of the Deprecation of Docker Runtime in Kubernetes for my network. I’ll post what I find out.
As far as your second question, you can do either. I am currently running HLF 2.3 on Kubernetes 1.20.2 with dind and all works fine. I plan on migrating this to run the external chaincode builders in the near future however.
Hope this helps,
Any further updates on this issue? I am facing the same issue, currently using HLF 1.4 version on Kubernetes 1.18 version and trying to upgrade kubernetes version to 1.19 version.
Which is the best way to implement HLF setup on kubernetes latest versions.
1. Upgrading to 2.x versions using external chaincode builders and chaincode as an external service
2. Or via dind (Docker-in-Docker)