peer lifecycle chaincode install fails with podman

[rlfnb]

Description

Packaged a chain contract and tried to install it with the following command:

peer lifecycle chaincode install mycc.tar.gz

I'm using on my machine podman instead of docker and basically all the remaining things work like a charm. Is there an existing env variable I can use to make it work with podman?

Steps to reproduce

$ ./peer lifecycle chaincode install mycc.tar.gz 
2024-01-15 20:32:22.307 CET 0001 INFO [grpc] AddTraceEvent -> [core] [Channel #1] Channel created
...
2024-01-15 20:32:22.308 CET 0007 INFO [grpc] AddTraceEvent -> [core] [Channel #1] Resolver state updated: {
  "Addresses": [
    {
      "Addr": "peer0.blue.green.com:7051",
      "ServerName": "",
      "Attributes": null,
      "BalancerAttributes": null,
      "Type": 0,
      "Metadata": null
    }
  ],
  "ServiceConfig": null,
  "Attributes": null
} (resolver returned new addresses)
2024-01-15 20:32:22.308 CET 0008 INFO [grpc] AddTraceEvent -> [core] [Channel #1] Channel switches to new LB policy "pick_first"
2024-01-15 20:32:22.308 CET 0009 INFO [grpc] AddTraceEvent -> [core] [Channel #1 SubChannel #2] Subchannel created
2024-01-15 20:32:22.308 CET 000a INFO [grpc] AddTraceEvent -> [core] [Channel #1] Channel Connectivity change to CONNECTING
2024-01-15 20:32:22.308 CET 000b INFO [grpc] AddTraceEvent -> [core] [Channel #1 SubChannel #2] Subchannel Connectivity change to CONNECTING
2024-01-15 20:32:22.308 CET 000c INFO [grpc] AddTraceEvent -> [core] [Channel #1 SubChannel #2] Subchannel picks a new address "peer0.blue.green.com:7051" to connect
2024-01-15 20:32:22.308 CET 000d INFO [grpc] Infof -> [core] pickfirstBalancer: UpdateSubConnState: 0xc000012300, {CONNECTING <nil>}
2024-01-15 20:32:22.310 CET 000e INFO [grpc] AddTraceEvent -> [core] [Channel #1 SubChannel #2] Subchannel Connectivity change to READY
2024-01-15 20:32:22.310 CET 000f INFO [grpc] Infof -> [core] pickfirstBalancer: UpdateSubConnState: 0xc000012300, {READY <nil>}
2024-01-15 20:32:22.310 CET 0010 INFO [grpc] AddTraceEvent -> [core] [Channel #1] Channel Connectivity change to READY
2024-01-15 20:32:22.310 CET 0011 INFO [grpc] AddTraceEvent -> [core] [Channel #4] Channel created
2024-01-15 20:32:22.310 CET 0012 INFO [grpc] AddTraceEvent -> [core] [Channel #4] original dial target is: "peer0.blue.green.com:7051"
2024-01-15 20:32:22.310 CET 0013 INFO [grpc] AddTraceEvent -> [core] [Channel #4] parsed dial target is: {Scheme:peer0.blue.green.com Authority: URL:{Scheme:peer0.green.com Opaque:7051 User: Host: Path: RawPath: OmitHost:false ForceQuery:false RawQuery: Fragment: RawFragment:}}
2024-01-15 20:32:22.310 CET 0014 INFO [grpc] AddTraceEvent -> [core] [Channel #4] fallback to scheme "passthrough"
2024-01-15 20:32:22.310 CET 0015 INFO [grpc] AddTraceEvent -> [core] [Channel #4] parsed dial target is: {Scheme:passthrough Authority: URL:{Scheme:passthrough Opaque: User: Host: Path:/peer0.blue.green.com:7051 RawPath: OmitHost:false ForceQuery:false RawQuery: Fragment: RawFragment:}}
2024-01-15 20:32:22.310 CET 0016 INFO [grpc] AddTraceEvent -> [core] [Channel #4] Channel authority set to "peer0.blue.green.com:7051"
2024-01-15 20:32:22.310 CET 0017 INFO [grpc] AddTraceEvent -> [core] [Channel #4] Resolver state updated: {
  "Addresses": [
    {
      "Addr": "peer0.blue.green.com:7051",
      "ServerName": "",
      "Attributes": null,
      "BalancerAttributes": null,
      "Type": 0,
      "Metadata": null
    }
  ],
  "ServiceConfig": null,
  "Attributes": null
} (resolver returned new addresses)
2024-01-15 20:32:22.310 CET 0018 INFO [grpc] AddTraceEvent -> [core] [Channel #4] Channel switches to new LB policy "pick_first"
2024-01-15 20:32:22.310 CET 0019 INFO [grpc] AddTraceEvent -> [core] [Channel #4 SubChannel #5] Subchannel created
2024-01-15 20:32:22.310 CET 001a INFO [grpc] AddTraceEvent -> [core] [Channel #4] Channel Connectivity change to CONNECTING
2024-01-15 20:32:22.310 CET 001b INFO [grpc] AddTraceEvent -> [core] [Channel #4 SubChannel #5] Subchannel Connectivity change to CONNECTING
2024-01-15 20:32:22.310 CET 001c INFO [grpc] AddTraceEvent -> [core] [Channel #4 SubChannel #5] Subchannel picks a new address "peer0.blue.green.com:7051" to connect
2024-01-15 20:32:22.311 CET 001d INFO [grpc] Infof -> [core] pickfirstBalancer: UpdateSubConnState: 0xc00011d4b8, {CONNECTING <nil>}
2024-01-15 20:32:22.312 CET 001e INFO [grpc] AddTraceEvent -> [core] [Channel #4 SubChannel #5] Subchannel Connectivity change to READY
2024-01-15 20:32:22.312 CET 001f INFO [grpc] Infof -> [core] pickfirstBalancer: UpdateSubConnState: 0xc00011d4b8, {READY <nil>}
2024-01-15 20:32:22.312 CET 0020 INFO [grpc] AddTraceEvent -> [core] [Channel #4] Channel Connectivity change to READY
Error: chaincode install failed with status: 500 - failed to invoke backing implementation of 'InstallChaincode': could not build chaincode: docker build failed: docker image inspection failed: Get "http://unix.sock/images/dev-peer0.blue.green.com-basic_1.0-8265237dadc929a6d47bbccc41048f4bdb383f0129b6a228f2aa41285012925d-1b119d25d2101140d58957a2027c91f84d64dfbcad69ee5975b1b802d70673e5/json": dial unix /var/run/docker.sock: connect: no such file or directory

[satota2]

@rlfnb
The fabric-samples repository contains an example of using Podman with the test-network.
https://github.com/hyperledger/fabric-samples/blob/02d9f8c58b8416019682120dc179fa8146ae7dad/test-network/README.md#podman

As there is no Docker-Daemon when using podman, only the ./network.sh deployCCAAS command will work. Following the Chaincode-as-a-service Tutorial above should work.

From the above description, it seems that since Podman does not have a Docker-Daemon, it is necessary to use External Chaincode as a Service.

[rlfnb]

sorry for late reply. @satota2 I think, fabric should deprecate the way to deploy chain codes the "old way" relying on docker, because basically no one will use docker to run fabric today and its fully incompatible to run HLF in kubernetes (no docker damon at all). What do you think?

[jt-nti]

@rlfnb I would also like to see Fabric deprecate the old built in chaincode support, although I think there needs to be better out of the box support for the new(ish!) builder and launcher framework first.

Currently the only built in builder/launcher is the chaincode as a server builder, which is great for developing and debugging chaincode but is fiddly to get working and is not well suited to production deployments.

There's also issue #3649 to add an out of the box "binary" builder, which could help with the initial Fabric experience, test networks, etc. but needs a bit more thought... and implementing!

And finally, there's the Kubernetes builder lab project which I hope will provide a better option for production deployments on Kubernetes.

[rlfnb]

sorry for coming back so lately to the topic. IMO, hyperledger need to get rid of the whole docker specifics and targeting podman. Making the whole value chain work with podman would mean having most of all kubernetes specific stuff already done, e.g. pod definitions, yaml files being usable for kubernetes as well. Other advantage would be also having a really lightweight dev setup without any need for minikube (or something else) on a dev machine.
Having the chain contract as a standalone image would even fine for production deployments, but as you said, its too fiddly ATM. Describing the contract better and paving out the way with more meaningful error messages might help already?

[jt-nti]

@rlfnb the purpose of the external builders and launchers is to make Fabric agnostic to deployment environments.

I'm sure it would be possible to create a podman builder but for kubernetes specific deployments, I would definitely recommend using the Kubernetes builder lab project instead.

Similarly, for a really lightweight dev setup, I think the nano test network with the chaincode-as-a-service builder work really well together,— no need for any containers. There's a new Developing and debuging chaincode tutorial which should hopefully help with the dev setup if you're interested in giving it a try.