Receber por email
← Voltar para o catálogo

helm-standards

Standards for Helm charts in SDD projects, including settings-driven patterns.

36estrelas
Atualizado há 8 meses

Ver no GitHub ↗

Como adicionar

/plugin marketplace add LiorCohen/sdd

O comando exato pode variar conforme o repositório. Confira o README no GitHub.

Para o autor da skill

Cole no README do seu repo

Mostra que sua skill está catalogada na Skillteca, gera backlink e tráfego rastreável.

[![Skillteca](https://www.skillteca.com.br/api/badge/helm-standards/svg)](https://www.skillteca.com.br/skills/helm-standards)
#ai

Skills relacionadas

Ver todas de Dados e Análise →

Alerta por categoria

Receba novas skills de Dados e Análise toda segunda

1 email curto, só com as skills novas de Dados e Análise. 4 minutos de leitura, sem spam, cancela com 1 clique.

Você confirma o email no primeiro envio. Sem spam. Cancela com 1 clique.

Ler descrição completa

Helm Standards Skill

Standards for Helm charts in SDD projects. Charts are generated based on component settings from sdd/sdd-settings.yaml.

Skills

Use the following skills for reference:

  • techpack-settings — Authoritative source for helm component settings schema, validation rules, and the chart-per-deployment pattern

Chart-per-Deployment Pattern

Each deployment configuration gets its own helm chart. A single server can have multiple helm charts (e.g., one for API mode with ingress, one for worker mode without). Delegate to the techpack-settings skill for the complete helm settings schema — it returns deploys (server reference), deploy_type (server/webapp), deploy_modes (array of mode strings like [api, worker]), ingress (boolean), and assets (static file configuration). These settings determine which templates are included in each chart.

Directory Structure

Helm charts live at components/helm_charts/<name>/:

components/helm_charts/
├── main-server-api/          # API deployment
│   ├── Chart.yaml
│   ├── values.yaml
│   └── templates/
│       ├── _helpers.tpl
│       ├── deployment.yaml
│       ├── service.yaml
│       ├── ingress.yaml
│       ├── configmap.yaml
│       └── servicemonitor.yaml
├── main-server-worker/       # Worker deployment (no ingress)
│   ├── Chart.yaml
│   ├── values.yaml
│   └── templates/
│       ├── _helpers.tpl
│       ├── deployment.yaml
│       ├── configmap.yaml
│       └── servicemonitor.yaml
├── admin-dashboard/          # Webapp deployment
│   ├── Chart.yaml
│   ├── values.yaml
│   └── templates/
│       ├── _helpers.tpl
│       ├── deployment.yaml
│       ├── service.yaml
│       ├── ingress.yaml
│       └── configmap.yaml
└── umbrella/                 # Optional: installs all charts
    ├── Chart.yaml
    └── values.yaml

Values File Conventions

| File | Purpose | |------|---------| | values.yaml | Default values (development-safe) | | values-{env}.yaml | Environment overrides (local, staging, production) |

Required Values

Every Helm chart must define these values:

# Infrastructure settings (NOT application config)
nodeEnv: development          # NODE_ENV for libraries (Express caching, etc.)

# Application config (from config component)
config: {}                    # Merged config from components/config/envs/{env}/

Server Chart Values

Single Mode Server

replicaCount: 1
nodeEnv: development

image:
  repository: main-server
  tag: latest
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 3000

observability:
  metrics:
    enabled: true
    port: 9090
    serviceMonitor:
      enabled: false
      interval: 30s

resources:
  limits:
    cpu: 500m
    memory: 512Mi
  requests:
    cpu: 100m
    memory: 128Mi

config: {}

Hybrid Server (Multiple Modes)

nodeEnv: development

image:
  repository: main-server
  tag: latest
  pullPolicy: IfNotPresent

# Each mode gets independent scaling
api:
  enabled: true
  replicaCount: 2
  resources:
    limits:
      cpu: 500m
      memory: 512Mi
    requests:
      cpu: 100m
      memory: 128Mi

worker:
  enabled: true
  replicaCount: 5
  resources:
    limits:
      cpu: 1000m
      memory: 1Gi
    requests:
      cpu: 200m
      memory: 256Mi

service:
  type: ClusterIP
  port: 3000

observability:
  metrics:
    enabled: true
    port: 9090
    serviceMonitor:
      enabled: false
      interval: 30s

config: {}

Webapp Chart Values

replicaCount: 1
nodeEnv: development

image:
  repository: nginx
  tag: alpine
  pullPolicy: IfNotPresent

assets:
  type: bundled              # bundled | entrypoint
  path: /usr/share/nginx/html

service:
  type: ClusterIP
  port: 80

ingress:
  enabled: true
  className: nginx
  hosts:
    - host: app.example.com
      paths:
        - path: /
          pathType: Prefix

config: {}                   # Injected into HTML at deploy time

Observability Integration

All server charts include observability by default:

ServiceMonitor (Prometheus/Victoria Metrics)

# templates/servicemonitor.yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: {{ include "common.fullname" . }}
spec:
  selector:
    matchLabels:
      {{- include "common.selectorLabels" . | nindent 6 }}
  endpoints:
    - port: metrics
      interval: {{ .Values.observability.metrics.serviceMonitor.interval }}
      path: /metrics

Metrics Endpoint

All servers expose metrics on port 9090:

  • /metrics - Prometheus format metrics
  • /health/live - Liveness probe
  • /health/ready - Readiness probe

Structured Logging

Applications output JSON logs to stdout. The cluster's log collector (Victoria Logs) picks them up automatically.

Note: Cluster-level observability infrastructure is set up separately (see task #47).

Config Injection Pattern

Server Config

Config is mounted via ConfigMap at /app/config/config.yaml:

# templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ include "common.fullname" . }}-config
data:
  config.yaml: |
    {{- toYaml .Values.config | nindent 4 }}

Webapp Config

Config is injected into HTML at deploy time:

  1. Webapp exports: export const startApp = (config: AppConfig) => { ... }
  2. Helm chart's index.html has: startApp(__SDD_CONFIG__)
  3. Init container replaces __SDD_CONFIG__ with JSON from ConfigMap

Populating Config at Deploy Time

# Generate config for production environment
<plugin-root>/fullstack-typescript/system/system-run.sh config generate --env production --component main-server \
  --output helm-values-config.yaml

# Deploy with config
helm install my-release ./components/helm_charts/main-server-api \
  -f values-production.yaml \
  --set-file config=helm-values-config.yaml

Environment Variables

| Var | Source | Purpose | |-----|--------|---------| | NODE_ENV | .Values.nodeEnv | Library behavior (Express caching, etc.) | | SDD_CONFIG_PATH | Static /app/config/config.yaml | Path to mounted config | | SDD_SERVER_MODE | Set per deployment | For hybrid: which mode (api, worker, cron) |

Secret References

Config contains secret names, not values. Applications use K8s secretKeyRef to load the actual values:

# values-production.yaml
config:
  database:
    host: db.production.internal
    passwordSecret: "my-db-credentials"  # K8s Secret name
# templates/deployment.yaml - Using secretKeyRef
env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: {{ .Values.config.database.passwordSecret }}
        key: password

Best Practices

  1. Chart-per-deployment - Separate charts for different deployment configurations
  2. Settings-driven templates - Use component settings to determine what's included
  3. Never hardcode environment values - Use values files for all environment differences
  4. Keep secrets external - Reference K8s Secrets by name only
  5. Config component is source of truth - Helm just mounts it
  6. Validate config before deploy - Use /sdd I want to validate my config in CI/CD
  7. Independent scaling - Use separate deployments for hybrid modes

Input / Output

This skill defines no input parameters or structured output.

Related Skills

  • config-standards — Delegate to this for config naming and structure conventions. Defines the config schema patterns that Helm values.yaml must align with.
Compartilhar X LinkedIn