There was an error while loading. Please reload this page.
Offer an address that works without a DNS name "Your Mac needs a real DNS name" isn't advice a home user can act on, so the troubleshooting entry now gives two alternatives instead of one, both checked on a live lab: the Mac's LAN address on the published port, which a container on any network can reach, and putting both services in one stack. The same run confirmed what the entry claims — a container on another network resolves fleetlab-fleet.test and gets no route to it, and a .local name doesn't resolve at all. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Follow through on the cross-network fix The lab I built put Gitea on Fleet's network, so I never hit what these instructions actually produce: two stacks, two networks, and a runner that resolves fleetlab-fleet.test and then can't route to it. Thanks to the clean-Mac run for finding it. The secrets section now says to use the Mac's own name; this carries that through the rest, which still assumed the container name was reachable: - Part 1 no longer claims local DNS is what gets the runner to Fleet. It buys a browser address and names within a stack, and explicitly not a route between stacks. - Fleet's own server URL is set to the same host name from the start. The workshop's default.yml sets server_url from FLEET_URL on the first run, so the old advice would have had it change underneath you. - The certificate uses the host name, with a note that self-signed means it needn't match anyway. - The untested machine-enrolment note carries the same warning. - Troubleshooting gains the failure itself, plus the two things that decide whether the fix works: the Mac needs a real resolvable DNS name, since containers don't answer mDNS, and failing that, putting both in one stack puts them on one network. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Updated Fleet GitOps Lab (markdown)
Add the Fleet GitOps lab walkthrough A Fleet server, a Gitea server with CI, and a runner that applies config to Fleet on every push — all in Apple containers, no Docker. Written from actually building it rather than from the upstream docs, so the failures are in it: fleetctl refusing a plain-http address, Fleet excepting enroll secrets from GitOps by default, the runner base image lacking node and perl, and the one that matters most — Fleet running happily for an hour on the default memory and then going silent when its vulnerability cron fires, with no error anywhere to explain it. Each is written next to the step that prevents it. Also records the two decisions a reader would otherwise get wrong: the compose file's certificate mounts have to exist even with TLS off, and mysql's x86 pin should go while fleet's should stay. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>