Skip to main content

Stand up your first cloud

By the end of this tutorial one machine runs a complete Triton Cloud control plane: a FoundationDB store, the tritond API, the operator console, and the tritonagent host agent. That machine registers itself as the first compute node (CN), and your tritonadm command line is signed in and answering.

Every command in this tutorial runs on that one machine, in the SmartOS global zone, as root.

What you build​

tritonadm setup apply brings the control plane up in dependency order, then proves the cluster can rearrange itself before it hands the system over:

  • a host-private etherstub named triton0 carrying the control network, with the global zone at 192.168.250.1/24
  • triton-fdb0, the founder FoundationDB zone, at 192.168.250.2
  • triton-tritond, the founder control-plane zone at 192.168.250.10, running the tritond API on port 8080 and the operator console on port 8081
  • the tritonagent and proteusadm bundles in the global zone
  • the founder pivot: a replacement triton-fdb1 at 192.168.250.3 and a replacement triton-tritond1 at 192.168.250.4, after which both founder zones are deleted

The founder pivot is not cleanup. It is the gate that proves this deployment can add and remove control-plane members while the store is still empty. If the pivot fails, the bring-up fails.

The control network is a host-private etherstub, so 192.168.250.0/24 is reachable only from this machine's global zone. The tritond zone also takes a DHCP lease on the admin network for access from off the box.

Before you start​

You need:

  • A machine already running SmartOS, with the zones pool created and the admin nic_tag configured. tritonadm setup apply creates neither and assumes both are in place.
  • A root shell in that machine's global zone.
  • HTTPS access from that machine to https://tritoncloud.nyc3.digitaloceanspaces.com, which hosts the release channel.

On the head node, as root, confirm the pool exists:

zpool list -H -o name zones

If the command fails, create the pool before going on.

1. Install the operator CLI​

On the head node, as root:

curl -fsSL https://tritoncloud.nyc3.digitaloceanspaces.com/install.sh | sh

The script maps uname -s/uname -m to the x86_64-unknown-illumos target, fetches the stable channel manifest over TLS, downloads the tritonadm tarball the manifest names, compares its SHA-256 against the manifest entry, and extracts it to /opt/triton/bin.

It reports where it put the binary:

==> tritonadm installed to /opt/triton/bin/tritonadm

Add that directory to your PATH:

export PATH=/opt/triton/bin:$PATH

Confirm the binary runs:

tritonadm --version

It prints the tritonadm version.

The script's closing line names tritonadm setup. That command takes a required subcommand; the one you want is tritonadm setup apply, in step 4.

2. Confirm the release channel​

On the head node, as root:

tritonadm install --list

tritonadm fetches the stable channel manifest and its detached minisign signature, verifies the signature against the publisher key compiled into the binary, and prints the channel name, its updated_at timestamp, and three sections: === images ===, === agents ===, and === tritonadm ===.

Two entries have to be present before you continue:

  • triton-platform, under images. Every control-plane zone is built from this one artifact, and setup apply refuses to start without it.
  • tritonagent, under agents. It actuates every step of the founder pivot, and setup apply refuses to start without it as well.

3. Preview the bring-up​

On the head node, as root:

tritonadm setup apply --no-clickhouse --dry-run

--dry-run resolves the plan, fetches and verifies the channel, prints every zone payload and planned change, and mutates nothing.

--no-clickhouse leaves out the optional metrics zone. That zone is on by default in this profile and is built from a separate triton-clickhouse image; the bring-up fails outright if the image is not in the channel.

The run opens with:

== tritonadm setup: single-node headnode bring-up ==

The lines after it name the resolved profile and one line per zone with its memory, disk quota, and control IP. Check that the profile line reads profile=poc and that the control IPs match the addresses in What you build. The run ends without changing anything on the host.

4. Bring up the control plane​

warning

This step takes the machine from empty to a full control plane and runs unattended to completion. Do not interrupt it. If the founder pivot fails, genesis is not complete; the recovery is to fix the cause and run setup again. tritonadm setup destroy tears down everything this host's apply created.

On the head node, as root:

tritonadm setup apply --no-clickhouse

Every planned change on a first run is a create, so setup applies without asking for confirmation. It installs the triton-platform image, creates triton-fdb0, runs FoundationDB genesis inside it, creates triton-tritond and blocks until http://192.168.250.10:8080/v1/health answers, then installs the tritonagent and proteusadm bundles and enables the site/tritonagent service.

Setup then preserves the one-time root password to /root/triton-root-password and signs the CLI in with it.

The founder pivot runs last. It waits for the agent to register this machine as a compute node and approves it, grows triton-fdb1, provisions triton-tritond1 through the control plane, waits for the replacement to serve a store-backed read, re-points the agent and the CLI at it, deletes the founder tritond zone, and decommissions triton-fdb0. On success it prints:

== founder pivot complete: fdb and tritond both proved grow & shrink ==

A closing summary follows. Its tritond API line names the founder address the pivot retired. The surviving address is on the line the pivot printed earlier, beginning re-pointed tritonadm config:, and step 7 confirms it.

warning

Do not run tritonadm setup apply on this machine again after it succeeds. The resource graph still names triton-fdb0 and triton-tritond, which the pivot deleted, so a second run re-creates them as stray zones. Day-2 changes go through the control plane instead.

5. Save the root credential​

On the head node, as root:

cat /root/triton-root-password

The file is mode 0600 and holds endpoint=, username=root, and password= lines. That password is the cluster's only initial root credential, and it is what signs you in to the operator console.

warning

The global zone's /root is ephemeral. Copy the password into your secret store now. The endpoint= line records the founder address the pivot retired; use the address from step 7 instead.

6. Confirm the control plane answers​

Setup signed the CLI in as root and re-pointed it at the surviving control plane, so there is no tritonadm configure step.

On the head node, as root:

tritonadm cn list

The output is a header row of SERVER_UUID, HOSTNAME, STATE, ROLE, ADMIN_IP, and REGISTERED_AT, followed by one row: this machine, in state approved. The founder pivot approved it, because the pivot needs an approved compute node to place the replacement zones on.

7. Confirm the control-plane zones​

On the head node, as root:

tritonadm infra zone list

The columns are ZONE_UUID, ALIAS, KIND, STATE, PROVENANCE, and CONTROL_IP. On a fresh bring-up triton-fdb1 is active at 192.168.250.3 and triton-tritond1 is active at 192.168.250.4. That makes http://192.168.250.4:8080 the control-plane API from this global zone, and the operator console is on port 8081 of the same address.

Now read the store through the API:

tritonadm fdb status

The first line reports cluster availability:

FoundationDB cluster: available

The lines after it report the redundancy mode, how many coordinators are reachable and whether they form a quorum, fault tolerance, data state, and topology. This read goes through tritond to FoundationDB, so an answer proves the whole path at once: CLI, credential, API, and store.

Your control plane is up.

Where to go next​