feat(cluster): burrow cluster bootstrap turns a bare VPS into a Burrow cluster#203
Merged
Conversation
…w cluster Add `burrow cluster bootstrap`, run once on a VPS, which resolves the public IP, installs k3s with the SANs and external IP the laptop needs, deploys burrowd (reusing the install path, which also mints the scoped agent credential per ADR-0038), and prints a `burrow join <token>` line for the user to run on their laptop. The token is the local k3s admin kubeconfig with its server rewritten from the loopback address k3s writes to the public IP, encoded via the ADR-0044 codec. k3s is installed with --tls-san and --node-external-ip so the API-server certificate is valid for the public IP the laptop connects through, --write-kubeconfig-mode 0644 so the bootstrap can read the admin kubeconfig, and --disable traefik so Burrow's ingress-nginx owns ingress; servicelb is left enabled as the free single-node LoadBalancer. The public-IP detector and the k3s installer are behind seams, so the pieces are unit-tested: public-IP resolution (flag, auto-detect, and the public-address validation), the install-command construction, the install-or-skip idempotency, and the join-token assembly round-tripping through jointoken with the server rewritten to the public IP. The full flow needs a real k3s and is not unit-tested end to end. Signed-off-by: Nicholas Phillips <nsphilli@gmail.com>
…p-clean On the VPS, `burrow cluster bootstrap` deploys burrowd by reusing the install path, which printed the laptop-oriented "connect your agent" guidance and recorded a local ~/.burrow environment handle — both of which contradict bootstrap's own "copy this token to your laptop" message. Add a clusterOnly field to installArgs. When set, the install performs only its cluster-side effects (deploy burrowd, and mint the scoped burrow-agent credential via the manifests) and skips the laptop-oriented local bookkeeping: it records no ~/.burrow handle and prints no post-install guidance, and an already-installed cluster returns without the local join. bootstrap sets the flag, so on the VPS the only output is the k3s/burrowd progress and the join-token block. Normal `burrow install` leaves it false and is unchanged. The now-dead bootstrap --environment flag (it named the local handle, which is no longer recorded on the VPS) is removed. Signed-off-by: Nicholas Phillips <nsphilli@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds
burrow cluster bootstrap, run once on a VPS, which resolves the public IP, installs k3s with the SANs and external IP the laptop needs, deploys burrowd (reusing theburrow installpath, which also mints the scoped agent credential per ADR-0038), and prints aburrow join <token>line for the user to run on their laptop. This is Phase 2 of ADR-0044 (single-VPS k3s), producing the token that Phase 1'sburrow joinconsumes.What it does
--public-ipflag if given, otherwise auto-detected behind a seam (an echo service, ipify by default). Either way it validates the result is a globally routable address and stops clearly (pointing at--public-ip) otherwise.--tls-san <ip>,--node-external-ip <ip>,--write-kubeconfig-mode 0644, and--disable traefik. servicelb is left enabled as the free single-node LoadBalancer (ADR-0043).runInstallagainst the local k3s admin kubeconfig, so there is no duplicate install logic and the scopedburrow-agentcredential (ADR-0038) the laptop'sburrow joinlater reads is minted by the same manifests.https://127.0.0.1:6443tohttps://<public-ip>:6443, encoded via the ADR-0044jointokencodec, printed as aburrow join <token>line with an admin-grade warning, the laptop next steps, and the:6443/:80/:443firewall reminder.Traefik
Disabled: k3s ships traefik by default, but Burrow provisions ingress-nginx via
burrow cluster ingress install, and two controllers contending for:80/:443is the misconfiguration to avoid. servicelb is kept.Testing
The full flow needs a real k3s and is not unit-tested end to end, but the pieces are, behind the seams: public-IP resolution (explicit flag, auto-detect, and the public-address validation/error paths), the k3s install-command construction (asserting the required flags and that servicelb is not disabled), the install-or-skip idempotency, and the join-token assembly round-tripping through
jointoken.Decodewith the server rewritten to the public IP. The light gate (build, vet, gofmt, tests, SPDX) passes.