POC Docker compose for small libp2p node network

[bacv]

POC for testnet using Docker compose, the same approach that waku is using for simulations.

Before going further, it would be great to discuss some nuances using this approach:

• Should node private key be persistent? At the moment libp2p node keys depends on container name - that means it will likely change between the runs (consensus private key is ignored atm). This might be a problem with persistence in the future, if we decide to write some node state into a file and load it when restarting.
  Writing and loading can be done from the host system using volumes, the problem is to determine which node should load a particular state and how not to load the same state twice.
• Should the network be managed by some hypervisor? For a small number of nodes, every container could be defined explicitly and specific configuration file provided. However, when dealing with an indefinite number of nodes, there might be a need for a "hypervisor" where nodes can register and be configured. This could be solved with libp2p discovery or the node client.

Alternative tools to Docker Compose include Ansible and bash scripts; however, these may not function seamlessly on local setups. Another advantage of using Docker Compose is the straightforward integration of Prometheus and Grafana.

[bacv]

These changes had it's own PR (#346) and was merged into this branch.

[codecov-commenter]

Codecov Report

Patch has no changes to coverable lines.

Files Changed	Coverage
nodes/nomos-node/src/config.rs	ø
nomos-libp2p/src/lib.rs	0.00%

📢 Thoughts on this report? Let us know!.

[vpavlin]

• Should node private key be persistent? At the moment libp2p node keys depends on container name - that means it will likely change between the runs (consensus private key is ignored atm). This might be a problem with persistence in the future, if we decide to write some node state into a file and load it when restarting.
  Writing and loading can be done from the host system using volumes, the problem is to determine which node should load a particular state and how not to load the same state twice.

We could not figure out how to deal with this in Compose directly (since, sadly, Docker Compose does not expose the container name in the container itself)

I wrote this simple golang tool to generate our compose based on simple (?:)) manifest

waku-org/waku-simulator#6

It was just a few hours PoC, so it is very simplistic, but it feels like a reasonable approach, unless someone can figure out a more general way how to figure out "who am I?" from the container perspective

[bacv]

We could not figure out how to deal with this in Compose directly (since, sadly, Docker Compose does not expose the container name in the container itself)

I wrote this simple golang tool to generate our compose based on simple (?:)) manifest

waku-org/waku-simulator#6

It was just a few hours PoC, so it is very simplistic, but it feels like a reasonable approach, unless someone can figure out a more general way how to figure out "who am I?" from the container perspective

Thank you very much for sharing your approach! I've taken a look and I believe that for our case it's too coupled with docker compose. I think it's perfectly fine for your use case, but even if nomos goes with docker compose for now, I'm not too sure about the long run. It's very likely that parts of infra will be provisioned by Ansible, especially the machines running nodes.

Ideally Docker Compose will stay for local tests and new users, by some parts being reused on the public testnet.

Having that in mind, I've been experimenting with observability tools like etcd and consul. I'll share results this week and would really value your insights. The basic idea is to have service registrar container, bootstrap node, and other nodes. The run_somekind_of_node.sh would do registering and config retrieval using the KV store provided by observability tool.

[jakubgs]

Looking good for the most part.

[danielSanchezQ]

🎸