@ -142,6 +142,8 @@ A Bitcoin node can also be operated in _regtest_ mode, where the node creates a
The container for Bitcoin Core is +bitcoind+ that runs Bitcoin Core in regtest mode and mines a new block every 10 seconds. It's RPC port is exposed on port 18443 and accessible for RPC calls with the username +regtest+ and the password +regtest+. You can also access it with an interactive shell and run +bitcoin-cli+ commands locally.
===== Building the Bitcoin Core Container
Let's start by building and running the +bitcoind+ container. First, we use the +docker build+ command to build it:
----
@ -161,10 +163,12 @@ Successfully built 758051998e72
Successfully tagged lnbook/bitcoind:latest
----
Next, let's run the bitcoind container and have it mine some blocks. We use the +docker run+ command, with the flags for _interactive (i)_ and _terminal (t)_:
===== Running the Bitcoin Core Container
Next, let's run the bitcoind container and have it mine some blocks. We use the +docker run+ command, with the flags for _interactive (i)_ and _terminal (t)_, and the +name+ argument to give the running container a custom name:
----
$ docker run -it lnbook/bitcoind
$ docker run -it --name bitcoind lnbook/bitcoind
Starting bitcoind...
Bitcoin Core starting
bitcoind started
@ -189,7 +193,54 @@ Balance: 100.00000000
As you can see, bitcoind starts up and mines 101 blocks to get the chain started. This is because under the bitcoin consensus rules, newly mined bitcoin is not spendable until 100 blocks have elapsed. By mining 101 blocks, we make the 1st block's coinbase spendable. After that initial mining activity, we mine a new block every 10 seconds, to keep the chain moving forward.
For now, there are no transactions. But we now have some test bitcoin that has been mined in the wallet and is available to spend. When we connect some Lightning nodes to this chain, we will send some bitcoin to their wallets so that we can open some Lightning channels between the Lightning nodes.
For now, there are no transactions. But we now have some test bitcoin that has been mined in the wallet and is available to spend. When we connect some Lightning nodes to this chain, we will send some bitcoin to their wallets so that we can open some Lightning channels between the Lightning nodes.
===== Interacting with the Bitcoin Core Container
In the mean time, we can also interact with the +bitcoind+ container by sending it shell commands. The container is sending a log file to the terminal, displaying the mining process of the bitcoind process. To interact with the shell we can issue commands in another terminal, using the +docker exec+ command. Since we previously named the running container with the +name+ argument, we can refer to it with that name when we run the +docker exec+ command. First, let's run an interactive +bash+ shell:
----
$ docker exec -it bitcoind /bin/bash
root@e027fd56e31a:/bitcoind# ps x
PID TTY STAT TIME COMMAND
1 pts/0 Ss+ 0:00 /bin/bash /usr/local/bin/mine.sh
7 ? Ssl 0:03 bitcoind -datadir=/bitcoind -daemon
97 pts/1 Ss 0:00 /bin/bash
124 pts/0 S+ 0:00 sleep 10
125 pts/1 R+ 0:00 ps x
root@e027fd56e31a:/bitcoind#
----
Running the interactive shell puts us "inside" the container and logged in as the +root+ user, as we can see from the new shell prompt +root@e027fd56e31a:/bitcoind#+. If we issue the +ps x+ command to see what processes are running, we see both +bitcoind+ and the script +mine.sh+ are running in the background. To exit this shell, type +CTRL-D+ or +exit+ and you will be returned to your operating system prompt.
Instead of running an interactive shell, we can also issue a single command that is executed inside the container, for example to run the +bitcoin-cli+ command, like this:
As you can see, we need to tell +bitcoin-cli+ where the bitcoind data directory is, with the +datadir+ argument. We can then issue RPC commands to the Bitcoin Core node and get JSON encoded results.
All the docker containers also have +jq+ installed, which is a command-line JSON encoder/decoder, to help us process JSON on the command-line or from inside scripts. You can send the JSON output of any command to +jq+ using the +|+ character ("pipe" notation). For example, if we pipe the +getblockchaininfo+ JSON result we got above, we can extract the specific field +blocks+ like this:
The +jq+ JSON decoder extract the result "189" from the +getblockchaininfo+, which we could use in a subsequent command.
As you will see in the following sections, we can run several containers and then interact with them individually, issuing commands to extract information (such as the Lightning node public key), or to take an action (open a Lightning channel to another node). The +docker run+ and +docker exec+, together with +jq+ for JSON decoding are all we need to build a working Lightning Network that mixes many different node implementations and allows us to try out various experiments, all on our own computer.
=== c-lightning
@ -197,6 +248,8 @@ C-lightning is a lightweight, highly customizable, and standard-compliant implem
https://github.com/ElementsProject/lightning
==== Building c-lightning as a Docker container
==== Installing c-lightning from source code
The c-lightning developers have provided detailed instructions for building c-lightning from source code. We will be following the instructions here:
@ -353,70 +406,9 @@ v0.8.1rc2
You may see a different version from that shown above, as the software continues to evolve long after this book is printed. However, no matter what version you see, the fact that the commands execute and show you version information means that you have succeeded in building the c-lightning software.
=== eclair
=== lightning network daemon (lnd)
==== The _devenv_ bundle container
As stated above, we have not optimized these containers for size. In that spirit, the +devenv+ folder has everything in a single container. It allows you to run any of the examples in a single environment.
[NOTE]
====
The devenv image is more than 2GB in size. The first time you build the image it will download a lot of data and take quite a while to finish building. However, docker efficiently caches each step, so if you rebuild it or make changes to it, it will be much faster next time!
====
Let's build our +devenv+ container and see how it works. Follow the steps below, while :
[docker-build-devenv]
----
$ cd code/docker
$ docker build devenv/ -t lnbook/devenv
Sending build context to Docker daemon 3.072kB
Step 1/20 : FROM ubuntu:18.04
---> 72300a873c2c
[...]
Step 20/20 : RUN curl -SLO https://github.com/ACINQ/eclair/releases/download/v0.3.3/eclair-node-0.3.3-12ac145.jar
---> Using cache
---> 3a38f85ba558
Successfully built 3a38f85ba558
Successfully tagged lnbook/devenv:latest
----
Once the +devenv+ docker container is built, we can run it and access and interactive command shell like this:
----
$ docker run -it lnbook/devenv
root@6b5c904d899f:/lnbook#
----
You see a prompt +root@6b5c904d899f:/lnbook#+, which shows you the user (root), the container fingerprint (6b5c904d899f) and the current working directory (/lnbook). The prompt ends in +#+ instead of +$+ because you are the root user inside this container.
Let's give it a quick test, by trying to run the Lightning Network Daemon command +lnd+ and see if it is installed correctly:
----
root@6b5c904d899f:/lnbook# lnd --version
lnd version 0.9.0-beta commit=v0.9.0-beta-148-g38b521d87d3fd9cff628e5dc09b764aeabaf011a
----
[TIP]
====
To exit the container, press +CTRL-D+ or type +exit+. You are returned to the prompt of your own computer's command-line terminal.
====
Great! You have built and ran your first docker container. In order to be able to access the book examples, we will need to connect the folder containing the book repository to our docker container. This is achieved with the +volume+ parameter, which specifies a local volume (where you cloned the book repository) and a container volume (a folder in the container) where the local volume will be mounted.
[TIP]
====
Docker's volume parameter needs an _absolute_ path, so that will depend on your local configuration and where you cloned or extracted the book repository files.
====
In the following example, we will be connecting the book repository files that were extracted in +/home/ubuntu/lnbook+ to the container volume +lnbook+. Your configuration is likely different, so you need to replace +/home/ubuntu/lnbook+ with the absolute path to the folder where you extracted the book repository:
=== lightning network daemon (lnd)
----
$ docker run --volume /home/ubuntu/lnbook:/lnbook -it lnbook/devenv
root@a7da66010491:/lnbook# ls
code images CONTRIBUTING.md README.md
[...]
----
=== Building a complete Lightning Network
You should now see all the book repository files inside your container, under the folder +/lnbook+. Now you can access the examples from the code directory with all the tools, applications and utilities that are in the container.
Andreas M. Antonopoulos
4 years ago