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).
Related
I have an hyperledger fabric network (v2.2.0) running in a kubernetes cluster deployed using baf. Initially the network had 5 orgs (Org1, Org2, Org3, Org4 and Org5), later I tried to join an org (Org6) into the network using the baf script. Since using baf script didn't add the org to the channel successfully, I have manually joined the org6 to the network using the configtxlator tool.
Now during Chaincode installation, I am facing an issue. Tested the fabcar chaincode (from the github repo - fabric-samples-2.0.0-beta), this chaincode installation resulted in same package id for all the 6 orgs in the network. But when I tried to deploy my own chaincode, I am getting different package id for the newly added 6th org, and different package id for all the remaining 5 orgs. Can anyone explain the cause of this?
I need to quote a statement that I am using the chaincode that I was using in hyperledger fabric 1.4.2. Would the chaincode written for fabric v1.4.x work against fabric v.2.2.0? Also I am using peer lifecycle chaincode commands to deploy the chaincode.
It's not impossible to get different package IDs as they are the hash of the chaincode package. With the same code and the same peer version, you've get the same ID it's true.
If, as far as you know, the chaincode package is exactly the same and the peer is exactly the same version - that it's worth double-checking the code is correct.
However, different package ids are permitted. It's used when you are talking to a peer to say "that chaincode I just installed with ID:xxx, please approve it, and then commit"
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.
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.