Setup: Self-Hosted Track
Welcome to the self-hosted tutorial track. This is requires a functioning Docker installation. If you are less technical, we recommend following the Cordial-hosted track instead. Let’s get started.
The goal of this lesson is to bring up a demo treasury instance, and create and register a long-term credential.
The demo instance will be a single Docker container, running inside it four processes (api, connector, engine, signer).
Launch Demo
Run the following command in a terminal:
- CLI (run this!)
treasury demo start --all-ips --pull --keep
--pull
pulls the latest release, and --keep
ensures the data is persisted if the demo restarts.
After a while, the command should complete, and you should see output like
:: configuration
treasury = 12Vbrk7PQsBCDwFSHJmLqN
keyring = /home/cordial/.local/share/treasury/12Vbrk7PQsBCDwFSHJmLqN/keyring
container = 5b11ab785209a6f23dc23269e3add0d03da47cc73792ae8bfbd12aeac4c9f170
API = http://0.0.0.0:36093/
:: blueprint
client-key root-invite { algorithm = "ed25519", public_key = "27f4cda174895791f0d2523d6a07320e03eb402a21012171be2f8a4faadfc78c" }
client-key root-key { algorithm = "ecdsa-k256-sha256", public_key = "023b539105c2b6a3087d985c1bc8c12bbc6c0646fc7bdd1ebbc1aaacc6b5570b33" }
k256 credential 1 for root { version = 1, public_key = "023b539105c2b6a3087d985c1bc8c12bbc6c0646fc7bdd1ebbc1aaacc6b5570b33" }
role connector { version = 1, credential = "k256", user = "machine" }
role signer { version = 1, credential = "k256", user = "machine" }
machine user connector { version = 1, roles = ["roles/connector"] }
machine user signer-1 { version = 1, roles = ["roles/signer"] }
allow access-rule create-credential { version = 1, action = "create", resource = "Credential", initiate = "any/user" }
allow access-rule connector-transactions { version = 1, action = "any/action", resource = "Transaction", initiate = "roles/connector" }
allow access-rule service-heartbeats { version = 1, action = "custom/heartbeat", resource = "User", initiate = "any/user" }
allow access-rule signer-responses { version = 1, action = "any/action", resource = ["KeyResponse", "SignatureResponse"], initiate = "roles/signer" }
invite credential connector-invite for connector { version = 1, public_key = "f6b6bdec9cc00ef8e8cc324fa6f0dab2a093321330ebe1e13097c5a28cfce5f7" }
invite credential signer-1-invite for signer-1 { version = 1, public_key = "597d11bdee0e494c468f3232893b647cbd12c825d729f424de8934d9476f344d" }
What just happened? The tool pulled the latest "Treasury Demo" Docker container from Cordial Systems' registry, and started it. This initialises a new treasury instance with the listed (random) ID, exposing the Treasury REST API on the listed port, and starts all the processes (policy engine, signer, connector). You can follow the logs using docker logs -f <container>
, however be warned these logs are currently messy and unstructured.
Afterwards, a basic blueprint script was run. By the end of this tutorial, you should be able to parse and understand the output generated after :: blueprint
, for now simply disregard it.
Verification
To verify, run
- CLI
treasury config treasury
You should see output like
name = "treasuries/12Vbrk7PQsBCDwFSHJmLqN"
api_url = "http://127.0.0.1:36093/"
sign_with = "client-keys/root-key"
demo = "true"
container = "treasury-demo-12Vbrk7PQsBCDwFSHJmLqN"
container_id = "5b11ab785209a6f23dc23269e3add0d03da47cc73792ae8bfbd12aeac4c9f170"
The location of the full configuration file can be shown with treasury config file
.