Erich Blume
b197bd5f58
## Summary Migrates the docs build pipeline to Dagger (Phase 2 of the Dagger CI adoption plan). - **Backfill `date-modified` frontmatter** on all 80 docs — Dagger's `--src=.` excludes `.git`, so Quartz can't use git history for page dates. Frontmatter dates work with or without git. - **New `docs-check-frontmatter` mise task + pre-commit hook** — validates all docs have `title`, `tags`, and `date-modified` - **New Dagger functions** — `build_changelog` (towncrier in Python container) and `build_docs` (chains changelog → Quartz build in Node container, returns tarball) - **Simplified CI workflow** — the ~44-line inline Quartz build (clone, npm ci, build, tar, cleanup) is replaced by `dagger call build-docs`. Changelog step remains local on the runner since towncrier needs to modify the host working tree for the git commit. ### Design decisions - **Towncrier runs twice in CI**: once inside Dagger (for the docs tarball) and once on the runner (for the git commit). This is intentional — Dagger's directory export is additive and can't delete the consumed changelog fragments from the host. - **Artifact hosting stays on Forgejo Releases** (not migrated to Forgejo Packages as the plan doc originally suggested). That migration can happen independently. - **`date-modified` frontmatter** preserved even though `build_changelog` installs git — the git there is only for towncrier's `git add` call, not for history. The local iteration story (`dagger call build-docs --src=. --version=dev` with uncommitted changes) depends on frontmatter dates. ### Local iteration ```bash dagger call build-docs --src=. --version=dev export --path=./docs-dev.tar.gz tar tf docs-dev.tar.gz | head -20 ``` ## Deployment and Testing - [x] `dagger call build-docs --src=. --version=dev` produces valid 1.1MB tarball (149 HTML pages) - [x] Pre-commit hooks pass (including new `docs-check-frontmatter`) - [ ] Full `workflow_dispatch` run after merge 🤖 Generated with [Claude Code](https://claude.com/claude-code) Reviewed-on: https://forge.ops.eblu.me/eblume/blumeops/pulls/157
46 lines
1.5 KiB
Markdown
46 lines
1.5 KiB
Markdown
---
|
|
title: Tailscale Operator
|
|
date-modified: 2026-02-08
|
|
tags:
|
|
- kubernetes
|
|
- tailscale
|
|
---
|
|
|
|
# Tailscale Kubernetes Operator
|
|
|
|
The Tailscale operator enables Kubernetes services to be exposed directly on the Tailscale network via Ingress resources.
|
|
|
|
## Quick Reference
|
|
|
|
| Property | Value |
|
|
|----------|-------|
|
|
| **Namespace** | `tailscale` |
|
|
| **Helm Chart** | `tailscale/tailscale-operator` |
|
|
| **ArgoCD App** | `tailscale-operator` |
|
|
|
|
## How It Works
|
|
|
|
Ingresses use a shared ProxyGroup (`ingress`) rather than per-service Tailscale nodes. When you create an Ingress with `ingressClassName: tailscale`:
|
|
|
|
1. Operator configures the shared ProxyGroup pods to serve the new Ingress
|
|
2. Service gets a VIP (Virtual IP) address on the tailnet
|
|
3. Service becomes accessible at `<hostname>.tail8d86e.ts.net`
|
|
4. TLS is handled automatically via Tailscale
|
|
|
|
Tailnet clients must have `--accept-routes` enabled to route to VIP addresses.
|
|
|
|
Services can be individually tagged (e.g., `tag:flyio-target`) via Ingress annotations to control which ACL grants apply. See [[expose-service-publicly]] for the tagging workflow.
|
|
|
|
## Limitations
|
|
|
|
Services exposed via Tailscale Ingress are **not accessible** from:
|
|
- Other Kubernetes pods (they're not Tailscale clients)
|
|
- Docker containers on indri
|
|
|
|
For pod-to-service communication, use [[routing|Caddy]] (`*.ops.eblu.me`) instead.
|
|
|
|
## Related
|
|
|
|
- [[tailscale]] - Network configuration
|
|
- [[routing]] - Service routing options
|
|
- [[apps]] - Application registry
|