Configuración dinámica en servicios Swift nativos de cloud con Kubernetes

Introducción

Los servicios en Swift que corren en entornos cloud-native enfrentan un problema común: la gestión de configuración fragmentada y poco robusta. Muchos equipos recurren a leer variables de entorno con ProcessInfo.environment o parsear manualmente archivos YAML/JSON, lo que genera ineficiencias operativas y riesgos de inconsistencia. Este enfoque no escala en entornos Kubernetes, donde las actualizaciones de ConfigMaps deben propagarse sin reinicios y con garantía de atomicidad.

• Composición explícita de fuentes de configuración con reglas de precedencia claras.
• Hot-reloading de archivos montados desde ConfigMaps sin reiniciar el servicio.
• Snapshots atómicos para evitar lecturas inconsistentes («torn reads») durante actualizaciones.
• Integración con sistemas de observabilidad como Prometheus y OpenTelemetry.

En esta guía, implementarás un servicio Swift en Kubernetes con configuración dinámica, usando ConfigMaps para propagar cambios y la librería Swift Configuration para gestionarlos de forma segura.

Qué es y para qué sirve

let providers: [any ConfigProvider] = [
    CommandLineProvider(),      // Mayor precedencia (CLI args)
    EnvironmentProvider(),      // Sobreescribe a .env
    DotEnvProvider(),           // Archivo .env
    StaticProvider()           // Valores por defecto
]
let config = ConfigReader(providers: providers)

1. Precedencia explícita: El orden de los providers define qué valor se usa. No hay magic: cambiar el orden es un cambio de una línea.
2. Hot-reloading: Proveedores como ReloadingFileProvider monitorizan archivos y actualizan la configuración sin reiniciar el servicio.
3. Snapshots atómicos: Cada lectura usa una snapshot inmutable del estado de configuración. Esto evita torn reads (lecturas inconsistentes durante actualizaciones).
4. Integración con Kubernetes: Los ConfigMaps se montan como volumes y se monitorizan vía ReloadingFileProvider, sincronizando cambios del cluster con el servicio.

• Necesitas actualizar configuración (flags, límites de rate, pool sizes) sin reiniciar el pod.
• Tu servicio corre en Kubernetes y usa ConfigMaps para gestión de configuración.
• Quieres evitar inconsistencias en lecturas durante actualizaciones (ej: middleware que lee un valor y el handler lee otro distinto).

Prerequisitos

• Acceso a un cluster Kubernetes con permisos para crear ConfigMaps y Deployments.
• Acceso a un registry de contenedores (Docker Hub, ECR, etc.) para subir la imagen.
• Entorno Linux (recomendado Ubuntu 22.04 LTS) para compilar el servicio.

# Instalar Swift en Linux (Ubuntu 22.04)
sudo apt update
sudo apt install -y swiftlang
swift --version  # Debería mostrar Swift 5.10 o superior

# Instalar kubectl
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
kubectl version --client --output=yaml

# Instalar helm (opcional, para charts de ejemplo)
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

Guía paso a paso

1. Crear un proyecto Swift básico con Swift Configuration

mkdir SwiftConfigDemo && cd SwiftConfigDemo
swift package init --type executable

Agregar dependencias en Package.swift:

// swift-tools-version:5.10
import PackageDescription

let package = Package(
    name: "SwiftConfigDemo",
    platforms: [.macOS(.v12), .linux(.v3)],
    products: [.executable(name: "SwiftConfigDemo", targets: ["SwiftConfigDemo"])],
    dependencies: [
        .package(url: "https://github.com/apple/swift-tools-support-core.git", from: "0.6.0"),
        .package(url: "https://github.com/apple/swift-log.git", from: "1.5.0"),
        .package(url: "https://github.com/hummingbird-project/hummingbird.git", from: "2.0.0")
    ],
    targets: [
        .executableTarget(
            name: "SwiftConfigDemo",
            dependencies: [
                .product(name: "Logging", package: "swift-log"),
                .product(name: "Hummingbird", package: "hummingbird"),
                .product(name: "SwiftConfiguration", package: "swift-tools-support-core")
            ]
        )
    ]
)

Instalar dependencias:

swift package update

2. Implementar la estructura de configuración

Crea Sources/SwiftConfigDemo/Config.swift:

import Foundation
import SwiftConfiguration
import Logging

// Estructura que define la configuración del servicio
struct AppConfig: Codable {
    var server: ServerConfig
    var features: FeatureFlags
    var database: DatabaseConfig

    struct ServerConfig: Codable {
        var host: String
        var port: Int
        var logLevel: Logger.Level
    }

    struct FeatureFlags: Codable {
        var enableMetrics: Bool
        var rateLimit: Int
    }

    struct DatabaseConfig: Codable {
        var poolSize: Int
        var timeoutSeconds: Int
    }
}

// Provider dinámico para hot-reloading
final class ConfigService {
    private let configReader: ConfigReader
    private let logger: Logger

    init() {
        // Proveedores estáticos (bootstrap)
        let staticProviders: [any ConfigProvider] = [
            StaticProvider([
                "server.host": "0.0.0.0",
                "server.port": "8080",
                "server.logLevel": "info",
                "features.enableMetrics": "true",
                "features.rateLimit": "100",
                "database.poolSize": "10",
                "database.timeoutSeconds": "30"
            ])
        ]

        // Bootstrap config reader para obtener filePath y pollInterval
        let bootstrapConfig = ConfigReader(providers: staticProviders)
        guard let filePath = bootstrapConfig.get("config.filePath"),
              let pollInterval = bootstrapConfig.get("config.pollIntervalSeconds").flatMap(Int.init) else {
            fatalError("Configuración bootstrap inválida")
        }

        // Proveedor dinámico (monitoriza archivo)
        let dynamicProviders: [any ConfigProvider] = [
            ReloadingFileProvider(
                filePath: filePath,
                pollInterval: .seconds(pollInterval),
                logger: Logger(label: "com.example.config")
            )
        ]

        // Combina todos los providers
        let allProviders = staticProviders + dynamicProviders
        self.configReader = ConfigReader(providers: allProviders)
        self.logger = Logger(label: "com.example.app")
    }

    var config: AppConfig {
        // Captura una snapshot atómica para lectura consistente
        let snapshot = configReader.snapshot()
        return AppConfig(
            server: .init(
                host: snapshot.get("server.host") ?? "0.0.0.0",
                port: snapshot.get("server.port").flatMap(Int.init) ?? 8080,
                logLevel: snapshot.get("server.logLevel").flatMap(Logger.Level.init(rawValue:)) ?? .info
            ),
            features: .init(
                enableMetrics: snapshot.get("features.enableMetrics").flatMap(Bool.init) ?? false,
                rateLimit: snapshot.get("features.rateLimit").flatMap(Int.init) ?? 100
            ),
            database: .init(
                poolSize: snapshot.get("database.poolSize").flatMap(Int.init) ?? 10,
                timeoutSeconds: snapshot.get("database.timeoutSeconds").flatMap(Int.init) ?? 30
            )
        )
    }

    // Escucha cambios en configuración (opcional)
    func watchConfig() async throws {
        for try await snapshot in configReader.watch() {
            logger.info("Configuración actualizada: \(snapshot.raw)")
        }
    }
}

3. Crear el servicio HTTP con Hummingbird

Modifica Sources/SwiftConfigDemo/main.swift:

import Hummingbird
import Logging

@main
struct App {
    static func main() async throws {
        // Inicializa configuración
        let configService = ConfigService()
        let config = configService.config

        // Configura logger
        LoggingSystem.bootstrap { _ in
            StreamLogHandler.standardOutput(label: $0)
        }
        var logger = Logger(label: "com.example.app")
        logger.logLevel = config.server.logLevel

        // Crea aplicación Hummingbird
        let app = Application(
            router: Router(),
            server: .http(
                hostname: config.server.host,
                port: config.server.port
            ),
            logger: logger
        )

        // Ruta para exponer configuración actual
        app.router.get("/config") { _, _ -> AppConfig in
            configService.config
        }

        // Ruta para probar hot-reloading
        app.router.get("/health") { _, _ in
            "OK"
        }

        // Inicia servicio
        try app.start()
        logger.info("Servicio iniciado en \(config.server.host):\(config.server.port)")
    }
}

4. Configurar el Dockerfile para Kubernetes

Crea Dockerfile:

# Usa imagen oficial de Swift 5.10
FROM swift:5.10-jammy

WORKDIR /app
COPY . .

# Compila el servicio
RUN swift build -c release

# Ejecuta el servicio
ENTRYPOINT ["./.build/release/SwiftConfigDemo"]

Construye la imagen:

docker build -t swift-config-demo:latest .
docker tag swift-config-demo:latest <tu-registry>/swift-config-demo:latest
docker push <tu-registry>/swift-config-demo:latest

5. Crear el ConfigMap de Kubernetes

Crea k8s/configmap.yaml:

apiVersion: v1
kind: ConfigMap
metadata:
  name: swift-config-demo
  namespace: default
data:
  app.yaml: |
    server:
      host: "0.0.0.0"
      port: 8080
      logLevel: "info"
    features:
      enableMetrics: true
      rateLimit: 100
    database:
      poolSize: 10
      timeoutSeconds: 30
    config:
      filePath: "/etc/config/app.yaml"
      pollIntervalSeconds: 15

Aplica el ConfigMap:

kubectl apply -f k8s/configmap.yaml

6. Crear el Deployment con volume de ConfigMap

Crea k8s/deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: swift-config-demo
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: swift-config-demo
  template:
    metadata:
      labels:
        app: swift-config-demo
    spec:
      containers:
      - name: swift-config-demo
        image: <tu-registry>/swift-config-demo:latest
        ports:
        - containerPort: 8080
        volumeMounts:
        - name: config-volume
          mountPath: /etc/config
          readOnly: true
        env:
        - name: SWIFT_LOG_LEVEL
          value: "info"
      volumes:
      - name: config-volume
        configMap:
          name: swift-config-demo
          items:
          - key: app.yaml
            path: app.yaml
---
apiVersion: v1
kind: Service
metadata:
  name: swift-config-demo
  namespace: default
spec:
  selector:
    app: swift-config-demo
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

Aplica el Deployment:

kubectl apply -f k8s/deployment.yaml

Verifica que el servicio esté corriendo:

kubectl get pods
kubectl logs -l app=swift-config-demo --tail=50

7. Probar hot-reloading

1. Actualiza el ConfigMap:

kubectl edit configmap swift-config-demo

Modifica el valor de features.rateLimit a 200 y guarda.

1. Verifica la propagación:

# Espera 1-2 minutos (kubelet sync period)
kubectl exec -it <pod-name> -- curl http://localhost:8080/config

Deberías ver el nuevo valor de rateLimit.

1. Monitorea logs:

kubectl logs -l app=swift-config-demo -f

Verás mensajes como:

[com.example.config] INFO: Configuración actualizada: [features.rateLimit: 200]

Consideraciones y buenas prácticas

1. Atomicidad y torn reads

• Middleware lee rateLimit: 100.
• Handler lee rateLimit: 200 (porque el archivo se actualizó entre medio).

• Swift Configuration garantiza atomicidad mediante snapshots. Cada lectura usa una snapshot inmutable capturada al inicio de la request.
• Para lecturas multi-clave en la misma operación, captura una snapshot explícita:

  let snapshot = configReader.snapshot()
  let rateLimit = snapshot.get("features.rateLimit")
  

2. Propagación de ConfigMaps en Kubernetes

• El tiempo entre que actualizas un ConfigMap y que el pod lo recibe depende de:

– Cache TTL de ConfigMaps en el cluster (por defecto 1 minuto).

• Reduce el pollInterval en ReloadingFileProvider a 15 segundos (valor por defecto), pero no afecta el tiempo de propagación de Kubernetes.
• Para reducir la ventana de inconsistencia, usa kubectl rollout restart deployment swift-config-demo después de actualizar el ConfigMap (fuerza un reinicio controlado).

3. Seguridad y permisos

• Evita montar ConfigMaps con credenciales en /etc/config. Usa secrets:

  volumes:
  - name: db-secret
    secret:
      secretName: db-credentials
  

• Para configuración no sensible, usa ConfigMaps con permisos restringidos:

  kubectl create configmap swift-config-demo --from-file=app.yaml --namespace=production
  

• Si usas StaticProvider con valores por defecto, evita hardcodear credenciales. Usa variables de entorno o sistemas como HashiCorp Vault con el provider correspondiente.

4. Alternativas y extensiones

• Swift Configuration soporta YAML y JSON por defecto. Para TOML:

  import TOMLKit  // Ejemplo de librería comunitaria
  let tomlProvider = try TOMLProvider(filePath: "/etc/config/app.toml")
  

• Implementa tu propio ConfigProvider para formatos personalizados.

• Usa el ConfigReader para leer endpoints de exportación de traces:

  let otelEndpoint = configReader.get("observability.otel.endpoint") ?? "http://otel-collector:4317"
  

• Combina ReloadingFileProvider con un sistema de feature flags distribuido (ej: LaunchDarkly) usando un ConfigProvider personalizado que consulte la API externa.

Conclusión

Implementar configuración dinámica en servicios Swift sobre Kubernetes soluciona problemas operativos críticos: hot-reloading sin reinicios, consistencia en lecturas, y integración nativa con el ecosistema cloud-native. La librería Swift Configuration provee las herramientas necesarias para lograrlo con patrones robustos y predecibles.

1. Diseñaste una estructura de configuración jerárquica y tipada.
2. Implementaste proveedores estáticos y dinámicos con precedencia explícita.
3. Configuraste hot-reloading con ConfigMaps en Kubernetes.
4. Garantizaste atomicidad con snapshots para evitar torn reads.
5. Integraste el sistema con observabilidad y prácticas seguras.

• Extiende el ejemplo para incluir métricas de Prometheus y traces de OpenTelemetry.
• Implementa un sistema de rollback automático para configuraciones inválidas.
• Documenta los esquemas de configuración usando OpenAPI o JSON Schema para validación CI/CD.

Fuentes

• CNCF: Dynamic Configuration for Cloud-Native Swift Services
• Swift Tools Support Core (Swift Configuration)
• Hummingbird Framework
• Kubernetes Documentation: ConfigMaps