Joakim
3506e55016
Major architectural change from rootless user services to system-level (rootful) containers to enable group-based Unix socket access for containerized applications. Infrastructure Changes: - PostgreSQL: Export postgres-clients group GID as Ansible fact - Valkey: Export valkey-clients group GID as Ansible fact - Valkey: Add socket-fix service to maintain correct socket group ownership - Both: Set socket directories to 770 with client group ownership Authentik Role Refactoring: - Remove rootless container configuration (subuid/subgid, lingering, user systemd) - Deploy Quadlet files to /etc/containers/systemd/ (system-level) - Use dynamic GID facts in container PodmanArgs (--group-add) - Simplify user creation to system user with infrastructure group membership - Update handlers for system scope service management - Remove unnecessary container security options (no user namespace isolation) Container Template Changes: - Pod: Remove --userns args, change WantedBy to multi-user.target - Containers: Replace Annotation with PodmanArgs using dynamic GIDs - Remove /dev/shm mounts and SecurityLabelDisable (not needed for rootful) - Change WantedBy to multi-user.target for system services Documentation Updates: - Add ADR-005: Rootful Containers with Infrastructure Fact Pattern - Update ADR-003: Podman + systemd for system-level deployment - Update authentik-deployment-guide.md for system scope commands - Update service-integration-guide.md with rootful pattern examples - Document discarded rootless approach and rationale Why Rootful Succeeds: - Direct UID/GID mapping preserves supplementary groups - Container process groups match host socket group ownership - No user namespace remapping breaking permissions Why Rootless Failed (Discarded): - User namespace UID/GID remapping broke group-based socket access - Supplementary groups remapped into subgid range didn't match socket ownership - Even with --userns=host and keep_original_groups, permissions failed Pattern Established: - Infrastructure roles create client groups and export GID facts - Application roles validate facts and consume in container templates - Rootful containers run as dedicated users with --group-add for socket access - System-level deployment provides standard systemd service management Deployment Validated: - Services in /system.slice/ ✓ - Process groups: 961 (valkey-clients), 962 (postgres-clients), 966 (authentik) ✓ - Socket permissions: 770 with client groups ✓ - HTTP endpoint responding ✓
93 lines
3.2 KiB
YAML
93 lines
3.2 KiB
YAML
---
|
|
# =================================================================
|
|
# Valkey Infrastructure Role - Simplified Configuration
|
|
# =================================================================
|
|
# Provides Valkey (Redis-compatible) as shared infrastructure for applications
|
|
# Applications manage their own Valkey database selections and usage
|
|
|
|
# =================================================================
|
|
# Essential Configuration
|
|
# =================================================================
|
|
|
|
# Service Management
|
|
valkey_service_enabled: true
|
|
valkey_service_state: "started"
|
|
|
|
# Network Security (Unix socket only - no TCP)
|
|
valkey_bind: "" # Disable TCP, socket-only mode
|
|
valkey_port: 0 # Disable TCP port
|
|
valkey_protected_mode: false # Not needed for socket-only mode
|
|
|
|
# Unix Socket Configuration
|
|
valkey_unix_socket_enabled: true
|
|
valkey_unix_socket_path: "/var/run/valkey/valkey.sock"
|
|
valkey_unix_socket_perm: "770"
|
|
|
|
# Group-Based Access Control
|
|
valkey_client_group: "valkey-clients"
|
|
valkey_client_group_create: true
|
|
|
|
# Authentication
|
|
valkey_password: "{{ vault_valkey_password }}"
|
|
|
|
# =================================================================
|
|
# Performance Settings (Conservative Defaults)
|
|
# =================================================================
|
|
|
|
# Memory Management
|
|
valkey_maxmemory: "256mb"
|
|
valkey_maxmemory_policy: "allkeys-lru"
|
|
|
|
# Persistence (balanced approach)
|
|
valkey_save_enabled: true
|
|
valkey_save_intervals:
|
|
- "900 1" # Save if 1 key changed in 900s
|
|
- "300 10" # Save if 10 keys changed in 300s
|
|
- "60 10000" # Save if 10000 keys changed in 60s
|
|
|
|
# RDB and AOF settings
|
|
valkey_rdbcompression: true
|
|
valkey_rdbchecksum: true
|
|
valkey_appendonly: false # RDB only for simplicity
|
|
|
|
# =================================================================
|
|
# Security Configuration
|
|
# =================================================================
|
|
valkey_timeout: 300
|
|
valkey_tcp_keepalive: 300
|
|
valkey_tcp_backlog: 511
|
|
|
|
# =================================================================
|
|
# Database Configuration
|
|
# =================================================================
|
|
|
|
# Database allocation for applications
|
|
# Applications should use different database numbers:
|
|
# - authentik: database 1
|
|
# - nextcloud: database 2
|
|
# - future services: database 3, 4, etc.
|
|
valkey_databases: 16
|
|
|
|
# =================================================================
|
|
# Logging Configuration
|
|
# =================================================================
|
|
|
|
valkey_loglevel: "notice"
|
|
valkey_syslog_enabled: true
|
|
valkey_syslog_ident: "valkey"
|
|
|
|
# =================================================================
|
|
# Infrastructure Notes
|
|
# =================================================================
|
|
# This role provides minimal Valkey infrastructure
|
|
# Applications should configure their own Valkey usage:
|
|
#
|
|
# Environment variables in application configs:
|
|
# - VALKEY_HOST: "{{ ansible_default_ipv4.address }}" or "127.0.0.1"
|
|
# - VALKEY_PORT: "6379"
|
|
# - VALKEY_PASSWORD: "{{ vault_valkey_password }}"
|
|
# - VALKEY_DB: "1" (or 2, 3, etc. - unique per application)
|
|
#
|
|
# Note: Applications can also use REDIS_* environment variables
|
|
# for compatibility since Valkey is fully Redis-compatible
|