Automated Deployment and Testing

Docker Deployment

For Rosetta, blockchain teams are expected to create and maintain a single Dockerfile (referencing any number of build stages) that starts the node runtime and all of its dependent services without human intervention.

Coordinated Start/Stop

Some blockchain nodes rely on a number of dependent services to function correctly. It is often the case that these nodes require an explicit startup and shutdown sequence to function correctly or prevent state corruption. With distributed services (in multiple running containers), this sequencing of operations can require a custom deployer for each blockchain.

With a single Dockerfile, blockchain teams can explicitly specify how services should be started and stopped using scripts. They can also easily test for issues in various scenarios, as all services are confined to a single container instead of being spread across some set of systems.

Middleware vs Embedded

Blockchain teams that do not wish to extend a core node to comply with the Rosetta API specifications can implement a middleware server that transforms native responses to the Rosetta format. However, this additional service's startup and shutdown must be coordinated by the Docker implementation.

Single Volume Mounting

When a deployment is started from a single Dockerfile, it is straightforward to mount a single volume to the new container and manage all of its state. Node deployments can be easily scaled by duplicating this volume to any number of new hosts without sophisticated tooling.

Stateful Data API Implementations are OK

Additional caches (those outside of what is stored by the node) can be used in a Data API implementation. The only expectation is that the state must be stored in the /data directory (as mentioned previously).

Stateful implementations of the Construction API, however, are prohibited. Clients accessing a Construction API implementation will provide all information necessary to construct a valid transaction.