Skip to main content

Stand up your first cloud

By the end of this tutorial one machine runs a 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.

This is a lab you throw away afterwards. It uses the flag-driven genesis path with no answers document, so it commits no cluster intent, and it skips the convergence phase that a kept cluster runs next. Plan on about an hour, most of it image downloads and the founder pivot.

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

What you build​

tritonadm setup bootstrap 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 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 | TRITON_CHANNEL=edge sh

TRITON_CHANNEL=edge selects the rolling channel. The script's default, stable, is published only for tagged releases. The script maps uname -s/uname -m to the x86_64-unknown-illumos target, fetches the 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 bootstrap, in step 4.

2. Confirm the release channel​

On the head node, as root:

tritonadm install --list --channel edge

There is no control plane yet, so name the channel. tritonadm fetches the edge 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 bootstrap refuses to start without it.
  • tritonagent, under agents. It actuates every step of the founder pivot, and setup bootstrap refuses to start without it as well.

3. Preview the bring-up​

On the head node, as root:

tritonadm setup bootstrap --channel edge --insecure-issuer --no-clickhouse --dry-run

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

--insecure-issuer accepts a plaintext single sign-on issuer. This lab declares no DNS, so the issuer can only name the founder's address, which the pivot deletes. Single sign-on does not survive the pivot here. Password sign-in, which this tutorial uses, is unaffected. Without the flag the run stops before it changes anything.

--no-clickhouse keeps the metrics zone out of the plan. ClickHouse is a convergence step, and this tutorial does not converge.

The run opens with:

== tritonadm setup: genesis bootstrap ==

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 with:

== dry run complete — nothing was changed ==

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; fix the cause and run the same command again. tritonadm setup destroy tears down everything this host's setup created.

On the head node, as root:

tritonadm setup bootstrap --channel edge --insecure-issuer --no-clickhouse --timeout 0

--timeout 0 removes the per-request time limit, because image downloads and health gates are slow.

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 approves this machine as a compute node once the agent registers 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, retires the founder tritond zone, and decommissions triton-fdb0. On success it prints:

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

The run ends with lines like these, followed by the single sign-on lines and the closing banner:

  bootstrap root credential preserved at /root/triton-root-password
  surviving control plane: http://192.168.250.4:8080
...
== bootstrap complete — run `tritonadm setup converge` to continue ==

The banner points at setup converge, the next phase of a kept cluster. This lab committed no cluster intent, so there is nothing to converge, and you stop here. Running setup bootstrap on this machine again is refused, because the pivot's replacement zones exist.

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, and both handoff files hold a password in clear text. Copy /root/triton-root-password and /root/triton-sso-root-password into your secret store now, then delete both files. Genesis writes the SSO file only when it could read the SSO password. The endpoint= line records the founder address the pivot retired; use the surviving control plane address from step 4 instead.

After you copy them, on the head node, as root:

rm -f /root/triton-root-password /root/triton-sso-root-password

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 SHORTID, HOSTNAME, STATE, ROLE, ADMIN_IP, SEEN, AGE, and TRAITS, 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 SHORTID, ALIAS, KIND, STATE, PROVENANCE, CONTROL_IP, CN, and AGE. 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. On the head node, as root:

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, the coordinator placement: line, 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​