We create the base directory structure and files.

Table of contents

• Create the directories
• Create the env file
• Create the docker compose file

Log in to your node as admin user via Secure Shell (SSH).

Create the base directory structure and access it:

$ mkdir -m 700 -p apps/mobybolt
$ cd apps/mobybolt

Create the base env file and populate it as follows:

$ nano .env

# base env
COMPOSE_PROJECT_NAME=mobybolt

# networking
NETWORK_SUBNET=172.16.21.0/24
NETWORK_GATEWAY=172.16.21.1
NETWORK_IPRANGE=172.16.21.128/25

Create the base docker compose file and populate it as follows:

$ nano docker-compose.yml

⚠️ Be sure to follow the exact indentation below... YAML is very sensitive to this! ⚠️

include:

networks:
  default:
    name: ${COMPOSE_PROJECT_NAME}_default
    ipam:
      config:
        - subnet: ${NETWORK_SUBNET}
          gateway: ${NETWORK_GATEWAY}
          ip_range: ${NETWORK_IPRANGE}

💡 The docker compose command will automatically load all the environment variables contained in the .env file.

💡 The docker compose command will operate on the docker-compose.yml file located in the same directory where it is run. The include directive in the file docker-compose.yml will allow us to include the YAML files of the Docker services that we will deploy later.

💡 The docker compose command will create a project network with the following values:

ℹ️ Docker relies on networks for internal container communication. Containers that reside on the same network will be able to reach each other using either the internal IP address or the name of the service. Containers that need external visibility (from the host) will need to publish a port via the docker-compose.yml file (Docker will automatically handle NAT, firewall, and port forwarding).

ℹ️ Each container will automatically receive an address from the configured dynamic DHCP address range (172.16.21.128-254). In addition, we keep a static address range (172.16.21.2-127). Static addressing (generally not necessary, since services can be invoked by name) will be used exclusively for the bitcoin service itself and for the containers that the bitcoin service needs to reach (tor, i2p). In fact, if you wanted to implement the (optional) configuration in Bitcoin Core to reject non-private networks, name resolution would be disabled and you could only reach other containers via the IP address (which will therefore have to be static).