Docker Deployment
Multiple Modes
As mentioned in the flow of operations section, deployments of the Data API will be in an online environment and deployments of the Construction API will be in an offline environment. “Offline environment” in this case means that the deployment will not be able to make any outbound connections over the internet. The only traffic allowed in this environment will be inbound requests to the exposed Construction API endpoints (with the exception of /construction/metadata and /construction/submit, which require an internet connection to work properly).
To support deployment in these distinct environments, it must be possible to specify an “offline” or “online” mode at startup (it is ok to default to “online”). When the “offline” mode is specified, the implementation must not attempt to open any outbound connections over the internet (i.e. attempt to peer with other nodes).
We do not recommend using multiple Dockerfiles to support these 2 modes as the overhead of maintaining two deployment artifacts across upgrades can end up being unnecessarily burdensome for both Mesh implementers and integrators.
Online Mode Endpoints
The following endpoints must work properly in “online” mode:
/network/*/block/*/account/*/mempool/*/call/construction/metadata/construction/submit
Some integrators do not require transaction construction to occur offline and may only run your implementation in “online” mode. For this reason, you should not disable any endpoints when in “online” mode.
Offline Mode Endpoints
The following endpoints must work properly in “offline” mode:
/network/list/network/options/construction/derive/construction/preprocess/construction/payloads/construction/combine/construction/parse/construction/hash
Dockerfile Expectations
There are many ways to write functional Dockerfiles, however, some approaches are less secure and make deployment and/or maintenance more difficult. In this section, we outline a few guidelines we expect any implementation to meet.
Ubuntu Image Compatibility
It must be possible to compile and run your implementation using exclusively Ubuntu-based images. This does not mean that the Dockerfile you share on your repository must use Ubuntu-based images (although it is highly recommended), however, it should still be possible to compile and run your implementation on Ubuntu-based images. In other words, if compilation of your implementation relies on musl-libc from Alpine, it would not be considered Ubuntu-compatible.
You may be wondering why Ubuntu is required instead of Debian or Alpine, or why there is any base image requirement at all (outside of maybe requiring any linux-based image). Many companies (especially ones extremely concerned with security) very purposely limit the number of operating systems they support on their infrastructure to simplify the tracking and patching of critical vulnerabilities in the OS. Ubuntu is one of the most popular Linux distributions and nearly all developers that will be running your implementation can support Ubuntu (even though they may not support other Linux distributions).
Build Anywhere
It must be possible to build your Dockerfile from any location (i.e. run docker build). For this reason, your Dockerfile must not copy any files from the directory where it is built. Instead, any required files must be downloaded from the internet with explicit versioning. If it is not possible to fetch a specific version, the hash of downloaded files must be compared with a constant defined in the Dockerfile.
Good Example
Bad Example: Copy Files from Build Environment
Compile from Source
Your Dockerfile must build both the node you are working on and Mesh implementation exclusively from source. In other words, your Dockerfile must not rely on any images that contain previously compiled code relevant to the blockchain you are working on.