apiVersion: apps/v1 kind: Deployment metadata: name: app-deployment labels: app: frontend spec: replicas: 2 strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 0 maxSurge: 1 selector: matchLabels: app: frontend template: metadata: labels: app: frontend spec: containers: - name: app image: gitea.cruzcloud.net/devops/ecommerce-frontend:v1.0.104 env: - name: HEADLESS_PROVIDER value: medusa - name: MEDUSA_BACKEND_URL value: http://medusa-svc:9000 - name: MEDUSA_REGION_ID value: reg_01KZT86WPAH7A7ZZRDSX3350V2 envFrom: - secretRef: name: commerce-storefront # El base usa "/" por default. El Dockerfile de frontend ya # define su propio HEALTHCHECK contra /api/health -- usamos # el mismo endpoint acá en vez del genérico del base, ya # sabemos que existe y responde. readinessProbe: httpGet: path: /api/health port: http livenessProbe: httpGet: path: /api/health port: http # El Dockerfile de frontend ya corre como usuario "nextjs" no-root # (a diferencia de docs-portal) -- runAsNonRoot: true del base # se queda tal cual, sin override. # # Sí hace falta NET_BIND_SERVICE: el puerto real es 80 # (privilegiado, <1024). El Dockerfile ya hace setcap sobre el # binario de node para esto, pero eso solo funciona si el # bounding set del contenedor lo permite -- drop: ALL del base # lo bloquea igual, root o no root. Mismo motivo que docs-portal. securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: false capabilities: drop: - ALL add: - NET_BIND_SERVICE resources: requests: cpu: 100m memory: 256Mi limits: cpu: "1" memory: 768Mi