eblume/blumeops
1
1
Fork 0
Code Issues Pull requests Projects Releases 83 Packages Wiki Activity Actions
blumeops/docs/how-to/immich/immich-pg-on-ringtail.md
Erich Blume b21d13fe20 C2(migrate-immich-to-ringtail): finalize chain — strip mikado frontmatter, add changelog 
Immich is fully migrated off minikube-indri onto k3s-ringtail. All
six prerequisite cards plus the goal card converted to historical
documentation by removing status/branch/requires Mikado frontmatter.

Changelog fragment added at docs/changelog.d/migrate-immich-to-ringtail.infra.md.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-13 13:46:27 -07:00

2.8 KiB
Raw Blame History

title modified last-reviewed tags
Immich Postgres Cluster on Ringtail 2026-05-13 2026-05-13
how-to
operations
postgres
immich

Immich Postgres Cluster on Ringtail

Stand up a fresh immich-pg CNPG Cluster on ringtail, ready to receive data. No data import yet — that's immich-pg-data-migration.

What to do

  • Create argocd/manifests/databases-ringtail/ (or pick another namespace name — verify what other ringtail pg clusters will use; if none yet, databases is fine).
  • Port these from the minikube side:
    • immich-pg.yaml — CNPG Cluster CR. Same image (ghcr.io/tensorchord/cloudnative-vectorchord:17-0.5.0), same extensions, same managed borgmatic role. Bump storage.size if the minikube 10 GiB looks tight (check actual usage first). storageClass: local-path on ringtail (default).
    • external-secret-immich-borgmatic.yaml — same 1Password item, same field, but referencing the ringtail ClusterSecretStore (onepassword-blumeops already exists per the external-secrets-ringtail app).
    • Service for in-cluster access (the operator creates immich-pg-rw etc. automatically; verify the app deployment uses those names).
    • A Tailscale Service if we want backups to keep working via the same hostname during the transition — see "Borgmatic" below.
  • New ArgoCD app argocd/apps/databases-ringtail.yaml pointing at the new path, destination ringtail.

Verification

  • Cluster reaches Ready.
  • borgmatic role exists, rolcanlogin=t, and is a member of pg_read_all_data (via managed.roles[].inRoles).
  • ExternalSecret immich-pg-borgmatic syncs from 1Password (Ready: True) and the rendered Secret has username=borgmatic.
  • The vchord, vector, cube, earthdistance extensions show installed in the postgres database (\dx from psql -U postgres). They are NOT installed in the immich database at this point — postInitSQL in CNPG's initdb block runs against the postgres superuser database. The Immich app itself creates the extensions in its own immich database at startup; do not be alarmed by their absence pre-immich-deploy. The vchord.so library is preloaded via shared_preload_libraries regardless, so CREATE EXTENSION at app startup just registers it in the right database.

Borgmatic implications

borgmatic.cfg on indri targets immich-pg-tailscale over the tailnet. During migration both clusters will exist briefly. Decide upfront: backup the source pg until cutover, then flip borgmatic to the ringtail Tailscale service. Document the flip in immich-cutover-and-decommission.

Out of scope

  • Importing data. That is immich-pg-data-migration, which may drive a reset on this card if the migration approach (e.g. CNPG externalCluster bootstrap) requires changes to this Cluster CR.