search

virtualeconomy / v-systems

V Systems Reference Full Node
Other
115 stars 45 forks source link

Document a known-good configuration for full nodes #210

Open faddat opened 4 years ago

faddat commented 4 years ago

At present, our recommended documented deploy path (the .deb file) described in #194 does not result in a stable VSYS node.

I'm going to update our documentation so that when users follow our recommended deployment setup exactly, VSYS works perfectly, and this issue has been created to gather the needed information.

Changes planned currently:

1) Make these default:

add more in/out bound connections in conf (120 or larger)

network {
    # How many network inbound network connections can be made
    max-inbound-connections = 120

    # Number of outbound network connections
    max-outbound-connections = 120
}
add more outbound buffer size in conf (64M or larger)
network {
    # Network buffer size
    outbound-buffer-size = 64M
}

2) Document use of the JAR by default, stop shipping the .deb and stop referring to the .deb in documentation

use jar directly (may not use the .deb service one, the stable issue may cause by the service logic), in this case, I used java -jar v-systems-v***.jar, vsys.conf

3) When the JAR is run, inform users that they should run it like this:

java -Xmx4096m -jar *.jar .conf allocated more threads in

java -Dscala.concurrent.context.maxExtraThreads=1024 -jar *.jar .conf

Is there anything else that we need to include in a default configuration that should work flawlessly every time?

Peerchemist has made mention of using Docker. Should we?

faddat commented 4 years ago

https://github.com/virtualeconomy/v-systems/releases/tag/v0.3.1

Makes a number of usage suggestions, reflected above, including using the jar directly.

Is there anything else that should be included in an opinionated bash script that stands up a VSYS node in one line?

faddat commented 4 years ago

Here is the plan for the bash launch script:

faddat commented 4 years ago

214 begins process by modifying the default configuration.

Per #208 , a commit can be added to #214 which removes the wallet section of vsys-mainnet.conf

When fully completed, this issue should result in the closure of

208 - keys should no longer be automatically generated and printed to the log

211 - I tend towards not shipping the debs anymore

194 - stability issues should be resolved and the default shipped state of vsys should be stable.

faddat commented 4 years ago

After encountering apparent issues with the Java environment on my node, it's clear to me that the Docker route suggested by Peerchemist will make for the easiest known-good deployment of VSYS nodes. I am creating an automatic docker image generator for us on my gitlab, and will make a PR that includes the Dockerfile here.

https://gitlab.com/faddat/vsys-docker

images will be accessible at:

registry.gitlab.com/faddat/vsys-docker:latest

faddat commented 4 years ago

running like:

java -Xmx4096m -Dscala.concurrent.context.maxExtraThreads=1024 -jar vsys-all-0.3.1.jar ../vsys-mainnet.conf
2020-07-12 11:57:26 INFO  [main] vsys.Application$ - Starting...
2020-07-12 11:57:27 INFO  [main] kamon.Kamon$Instance - Initializing Kamon...
2020-07-12 11:57:27 INFO  [lt-dispatcher-3] a.event.slf4j.Slf4jLogger - Slf4jLogger started
2020-07-12 11:57:27 INFO  [main] vsys.Application$ - VSYS Core v0.3.1 Blockchain Id: M
2020-07-12 11:57:27 INFO  [main] v.b.s.BlockchainUpdaterImpl - Constructing BlockchainUpdaterImpl, total blocks: 0, persisted: 0, topMemDiff: 0, bottomMemDiff: 0
2020-07-12 11:57:27 INFO  [main] v.b.s.BlockchainUpdaterImpl - State rebuild started, total blocks: 0, persisted: 0, topMemDiff: 0, bottomMemDiff: 0
2020-07-12 11:57:27 INFO  [main] v.b.s.BlockchainUpdaterImpl - State rebuild finished, total blocks: 0, persisted: 0, topMemDiff: 0, bottomMemDiff: 0
2020-07-12 11:57:27 INFO  [main] v.wallet.Wallet$WalletImpl - Your randomly generated seed is 3HTZrvPuT6fGhYPAqszZQkS62jwF1ST48NGANikyLKZaJVGgDwEubUQU1ULN1vFWQNySUvtMokR7wnB4NCACcHMt
2020-07-12 11:57:28 INFO  [main] vsys.Application$$anon$1 - Genesis block has been added to the state
2020-07-12 11:57:28 INFO  [main] v.wallet.Wallet$WalletImpl - Added account #1
2020-07-12 11:57:28 INFO  [main] vsys.Application$$anon$1 - REST API was bound on 127.0.0.1:9922
2020-07-12 11:57:29 INFO  [ntLoopGroup-3-2] vsys.network.NetworkServer - [e170a63a 3.121.94.10:9921] Connection established
2020-07-12 11:57:29 INFO  [ntLoopGroup-3-2] v.n.HandshakeHandler$Client - [e170a63a 3.121.94.10:9921] Accepted handshake Handshake(V SYSTEMSM,(0,3,1),Node-259698,259698,Some(/3.121.94.10:9921))
^C2020-07-12 11:57:33 INFO  [ntLoopGroup-3-2] vsys.network.NetworkServer - [e170a63a 3.121.94.10:9921] Connection closed, 0 outgoing channel(s) remaining
^C^C^C^C2020-07-12 11:57:39 INFO  [shutdownHook1] vsys.Application$$anon$1 - Stopping network services
2020-07-12 11:57:39 INFO  [shutdownHook1] vsys.Application$$anon$1 - Closing db
2020-07-12 11:57:39 INFO  [shutdownHook1] vsys.Application$$anon$1 - Shutdown complete

VSYS runs successfully, but still creates a seed and prints it to the log, even when the wallet section is removed from vsys-mainnet.conf

faddat commented 4 years ago

Known-good run command:

java -Xmx4096m -Dscala.concurrent.context.maxExtraThreads=1024 -jar vsys-all-0.3.1.jar ../vsys-mainnet.conf
faddat commented 4 years ago

Gitlab has superior CI and integrated docker image hosting, allowing for jobs like this:

https://gitlab.com/faddat/vsys-docker/-/jobs/634764544

faddat commented 4 years ago

It is now possible to run VSYS in the recommended configuration like this:

docker run -d registry.gitlab.com/faddat/vsys-docker:latest

That'll allow outbound traffic and the node will be able to sync, but you may not be able to access the web UI.

To give only yourself access to the web UI, try:

docker run -d -p 127.0.0.1:9922:9922 registry.gitlab.com/faddat/vsys-docker:latest

To give the world access to your node's API / web UI:

docker run -d -p 9922:9922 registry.gitlab.com/faddat/vsys-docker:latest

this does not yet deal with volumes, which will be approached later.

Merging #214 and re-building the docker image would mean that VSYS runs with 100% of recommended settings using this approach.

ncying commented 4 years ago

All conf which in the release is for some high-performance usage, not for the default. If we need to change the default configuration, we will change the code level files.