I have a scenario in which it would be required for the chaincode to call an external application to do a complex proprietary job.
I know that it is basically possible (also not recommended) to call an external service e. g. via HTTP.
However, I'd like to call a binary that is locally installed on the peer simply by for example exec.Command("some application") from the chaincode and work with its result.
The problem I am facing is that Fabric runs the chaincode itself in another docker container and not directly in the peer container, making the binary unavailable. Is there a way to share maybe a peer's volume with the runtime containers created by Fabric for chaincode execution?
You can package the binary with the chaincode package and then it will be able to execute it at the time of the chaincode execution.
Related
I am using Fabric 2.0 and external chaincode feature. I have an organization with 2 endorsing peers. I tested external chaincodes with one peer and it works, but how to use it with multiple peers?
Fabric docs says: "Instead of building and launching the chaincode on every peer, chaincode can now run as a service whose lifecycle is managed outside of Fabric". Does it mean that I need only one external chaincode container regardless of the number of peers?
Do I need to install chaincode on a second peer too? Also during the chaincode installation it gives me CCID which I use inside the chaincode. But if I install the chaincode on a second peer it gives me another CCID and I don’t know what to do with it.
External builders give you the flexibility to determine how/where/when your chaincode is actually built. You could for instance:
Build your chaincode as a docker container, push it to a docker repository, and simply pull the image during the 'external builder' process.
Have each peer build a copy of a chaincode binary locally using a toolchain in the local filesystem.
Build a binary and push it out as part of the install package, and simply execute it.
Regardless of where/how/when your chaincode is actually built, you will need to install a chaincode package on every peer which will execute it. You will also need to have your peers configured with the correct external builder to consume your package type.
After digging in to the HLF chaincode documentation and many practical experiments, I found the answers to my questions.
Does it mean that I need only one external chaincode container regardless of the number of peers?
You can use one external container for the same chaincode packages (with identical CCIDs).
Do I need to install chaincode on a second peer too?
Yes, you need to install chaincode package on all endorsing peers of the organization.
If I install the chaincode on a second peer it gives me another CCID and I don’t know what to do with it.
If you want to use the same external chaincode container for the several organization peers, you must install the same chaincode package on these peers, instead of creating new package for each peer (this was my fail, I created new package for the second peer and it generated different CCID).
We are running fabric (1.4.4) in an essentially closed network (no direct internet access, only private docker/npm/maven registries requiring authentication are accessible through a proxy).
While golang chaincode works just fine in this setup, node chaincode prove to be impossible to instantiate, as fabric-ccenv is executing npm install --production, which obviously won't work without internet access. In fabric 1.4, the only thing customizable about fabric-ccenv seems to be the image to be used.
But even if security would allow proxy settings, private registry addresses and credentials to be included in a custom fabric-ccenv image, some native npm builds (x509, grpc) seem to need direct internet access, as they are loading e.g. openssl header files or grpc pre-built binaries. Even if we were able to 'hack' that for a particular node chaincode, it would still preclude the use of arbitrary node chaincode, with arbitrary dependencies.
In fabric 2.0 it seems to be possible to build chaincode containers externally - is there any chance to make this work for fabric 1.4, too?
Are there any other ways to influence that node chaincode container build in fabric 1.4 that we might have missed?
here's my problem.
I have set a development env for HLF using Vagrant, made some changes to HLF source and built new docker images.
Then I deployed a network with 3 peers and 1 orderer, starting from custom HLF images and installed the basic chaincode that uses 'a' and 'b' variable as assets, making some operation (chaincode_example02).
Now I would like to see blockchain info such as blocks hash, ledger height and so on. How can access this info? Is there a way without using any app made with SDKs? For instance, some command executed by CLI.
If not, what's the fastest way to get this info? Thanks.
Ok, solved the problem.
This does what i needed:
docker exec -it cli bash peer channel getinfo -c <channel-name>
I have prototyped a basic network using Hyperledger Composer and now working on migration of the solution to completely Fabric-based.
Since there is a network with pre-published testing data, I just composed a new CC in Golang and copy the sources into my channel's peer for deploying it.
Peer is connected to composer_default network's channel, which was created by composer-tools/fabric-dev-servers startFabric.sh script.
Then I replaced my bna chaincode from Fabric network by Golang chaincode build, with using the same CC name and incremented CC version (peer chaincode upgrade).
So the question is: does it possible for the new Fabric CC to get through existing State filed by Composer bna previously? Like we access it using GetState method of ChaincodeStubInterface:
marbleAsBytes, err := stub.GetState(marbleName)
Or perhaps the data can be pulled with Queries to CouchDB (channel's current store)? Don't know the real key identifiers used by Composer to store their write sets.
P.S. Actually I don't want to invoke Composer bna transactions/queries from Fabric CC and vice versa. It's just a kind of upgrade of business logic for existing network environment.
I think it should be possible as assets are stored as key value pairs, you can first try to query any key through native golang chaincode. As previously I had tried upgrading one composer chaincode with completely different chaincode, and if I tried entering data for previously used key in my old composer chaincode, it was throwing error. So even if the chaincode is different you should be able to access the already created asset through its key.
Hyperledger Fabric installs chaincode on several peers with the chaincode package which includes the compressed source code, and compile it in the ccenv docker container launched by the process of chaincode instantiation. I am wondering why it does not directly install the binary in the container for those peers. Any special purpose? thanks.
Compiling chaincode within ccenv container ensures that outcome will be the same for all participants in the network, otherwise there might be an issues and diffs caused by differences of compilers version, dependencies available and etc. This is also necessary for cross platform compilation.
I think the reason is, all participating peers need to achieve agreements on the code (smart contract), with binary it would be harder to inspect what the code does. Before a peer to endorse a chaincode installation proposal it supposes to inspect the content.