lnp-bp / docker Goto Github PK

Connected with each other, with ports exposed & done in the same way as bitcoind and c-lightningd images (debian buster) & compose (no need to integrate with them though)

Constructed in a same way as other containers (on Debian Buster, built from sources)

• elements node
• electrs for elements

Both this repo and https://github.com/LNP-BP/nodes serve the same purpose. I think they can be joined into one repo (I will keep both commit histories, git allows that).

@nicbus @zoedberg @crisdut what do you think?

For

• mainnet
• signet? (if possible)

For enabling lightning node customization

when launching bitcoind this log appears: Config options rpcuser and rpcpassword will soon be deprecated. Locally-run instances may remove rpcuser to use cookie-based auth, or may be replaced with rpcauth. Please see share/rpcauth for rpcauth auth generation. (from here)

to generate an rpcauth, from the bitcoin repo, run: ./share/rpcauth/rpcauth.py <username> <password>

for this project, using bitcoin as user and password, the rpcauth is: rpcauth=bitcoin:c15fb70bbb0239f9cfdfc8b5d48d67a2$0c9257124cf65b816e06fb8c657de4c5cc458d3385ca8242ba7ac17b29aeb064

I propose to change the bitcoind command directive in all compose files, putting instead of -rpcuser=bitcoin and -rpcpassword=bitcoin, the rpcauth flag (escaping the dollar symbol for yaml): -rpcauth=bitcoin:c15fb70bbb0239f9cfdfc8b5d48d67a2$$0c9257124cf65b816e06fb8c657de4c5cc458d3385ca8242ba7ac17b29aeb064

One we agree upon them in #19, including, but not limiting to:

• More safe RPC interfaces (with macaroons/cookie files) not exposed to the external world
• streamlined use of environment variables
• run processes from users, not root
• support for external volumes

• create dockerhub tags for signet version numbers
• add wallet support to signet image (since there are no other known wallets supporting signet)
• make sure electrum and lightning are working with signet

From RGB-WG/rgb-node#71

Based on the current mainnet version: just change the ports and ENV variables + provide additional -testnet arg in command

Connected with both LND (#15) and c-lightning

Use https://github.com/krallin/tini, like in c-lightning default docker container, for all shells inside containers

After some discussions with @zoedberg in #17 I propose to discuss and then codify design principles we are using for dockerization (Dockerfile design and docker-compose containers). Right now this is an issue, but later once we agree on it I propose to put it as a part of README.md file in this repo.

So my initial take on that:

1. When you do not need to expose RPC ports to the external world leave them exposed only through docker-compose expose but not port command
2. In docker-compose connectivity always rely on internal network only; since there might be alternative compose files using same ports on the same IP addresses (for instance for scalability purposes)
3. Customize as much as possible with environment variables ARG variables
4. Structure ENTRYPOINT in a way that it can be extended with compose command args later; but if this conflicts with (3) the (3) must have a higher priority and customization in compose file with custom entrypoint is should be preferred.
5. For RPC use macaroons/files whenever possible (not implemented yet, needs a separate issue).
6. Run container processes using an unprivileged user instead of root.

It’s possible to use environment variables in your shell to populate values inside a Compose file

• define default .env file within compose directory using volumes
• define custom macos.env, windows.env & linux.env files using default OS-specific paths for volumes
• use ENV variables in compose file volume dfinitions