FISCO BCOS offline deployment problem recording and resolution

foreword

Due to the requirements of the project requirements team, none of the deployed servers can access the external network, so I tried offline deployment of blockchain underlying network nodes, consoles, Webase, etc. Of course, I also encountered pitfalls, so I recorded them.

Step 1: Deployment and installation of the underlying chain

Refer to this blog post to complete the deployment and installation of the underlying chain, that is, first install it online on a server with a network, and then set the pre-set IP information of the non-network server in advance, and then move the node information to the offline without network on the server.
There are no pitfalls, and the journey is fairly smooth.
Deployment and installation of the bottom chain of FISCO BCOS offline and network-free deployment and installation series tutorials (idea 1)

Step 2: Configure and use the console

Here you can refer to the steps on the FISCO BCOS official website. Inspired by step 1, download the download_console.sh script file in advance and install the official download path.

Configure and use the console

Step 3: Deploy and call the HelloWorld contract

Here you can still refer to the official website steps.
Deploy and invoke the HelloWorld contract

Step 4: build webase

Refer to the official website, you need to install the jdk environment in advance (recommended 1.8)
Webase construction
You can also refer to this more comprehensive and complex version, because our project does not need such complex functions, that is, the official website version can be used
FISCO BCOS offline deployment without network installation series tutorial Deployment and installation of blockchain browser fisco-bcos-browser v2.2.1

Step 5: Contract Compilation

After the webase is built, put the contract file (ie. sol file) required by the project into the page (http://xxxx:5002/WeBASE-Front) contract management page function - contract IDE, compile and deploy the main contract, You can see it in the contract list.

In the contract list, you can see the compiled and deployed contract, and you can test whether the contract method is effective by calling the contract

During this period, you need to create a test user first, and the .pem file of this user will also be used later

Step 6: Distributed storage data – off-chain mysql synchronization on-chain data (world state library)

Due to the query speed requirements of the project, we made the expansion requirements of off-chain mysql to synchronize data on the chain, and pulled the world state database data and historical state database data respectively. This step is to synchronize the world state database data.
Refer to the official website for distributed storage

Stepping on pit 1: mysql version selection

The premise is to install mysql offline (recommended version 5.7). I tried to use docker’s mysql8 version image when deploying offline, but the distributed storage data cannot be synchronized. Therefore, it is recommended to use the version 5.7 used by the official website.

Stepping on the pit 2: group.1.ini configuration file modification

When modifying the group.1.ini configuration file according to the steps on the official website, in addition to the colleagues who need to modify the official database name, user name, password, ip, and port number, you should also pay attention to a small detail that needs to be modified, that is, in the storage There is a type below, the default is rocksdb, but because our project uses mysql, so we have to change it to type=mysql synchronously here, this is really a hidden pit, the official website tutorial also uses mysql but it doesn’t mention it at all and modify here.

Step 7: Data export system components – off-chain mysql synchronization on-chain data (historical state library)

In addition to the world state library, the blockchain needs to query the historical state when more traceability, retrieval and other needs are required, so it is also necessary to synchronize the historical state library. Similarly, refer to the official website deployment method. The data export system components are basically installed on the official website
. The required scripts are downloaded first, then moved to the offline server, and then the purpose is achieved by modifying some configuration files and other operations.

Trample 1: Gradle needs to be downloaded and installed during script execution

But this time the script cannot be run directly on the offline server, because the script involves downloading the gradle wrapper, but there is no way to connect to the external network in the offline server, so this does not work, I also tried to install it on the server myself, but When executing the script, there will still be problems such as dependent packages, in short, this will not work.
Solution: also refer to the idea of ​​step 1, first execute the script in a networkable environment to complete, generate the Data-Export*.jar package after the script is run, and then move it to the offline server.

Stepping on the pit 2: configuration file environment changes

The ip in the application.properties file modification should be modified to the ip of the offline server, replacing 127.0.0.1, otherwise running the jar will fail to access the underlying link

Stepping on the pit 2: configuring the contract

After running the jar package, the contract method and event data are not exported. In the end, according to the official prompt, delete the contract that has been configured under config/solidity/ that failed to export data, and replace the config/solidity/bin/(non-national Replace the content of the bin file under the secret directory /ecc/, and the national secret directory is /sm/) with the binary compiled from the contract deployment location (such as WeBase), then clean the database table and restart

With function prompt

1: port check

Due to the offline server, all ports are not opened by default, so some common ports used in the above operations need to be manually opened by the firewall, such as (3306, 20200, 30300, 8485, 5002), etc.

firewall-cmd --list-ports	#查看已经开放的端口
firewall-cmd --zone=public --add-port=3306/tcp --permanent #开放端口3306
firewall-cmd --reload		#重启firewall
firewall-cmd --list-ports	#检查3306是否开放

2. docker starts mysql time zone selection

Because I later changed to docker to start mysql5.7 version, the server's time zone check (date command) showed that it was CST, but the default time zone of the mysql version started through docker was UTC, so the time zone was inconsistent, and the jar of the historical version library was started at that time I couldn’t create the data-export library when I packaged it. I thought it was a problem with the time zone.
When docker creates a container, set the time zone as follows:

docker run -p 3306:3306 --name mymysql -v $PWD/conf:/etc/mysql/conf.d -v $PWD/logs:/logs -e TZ=Asia/Shanghai -v $PWD/data:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=123456 -d mysql:8.0

Three ways to modify the mysql time zone in the Docker container
Mysql how to modify the time zone

3. Other blog post references

CentOS7.5 offline installation jdk1.8
centos7 offline installation MySQL5.7