devopsandClaude Sonnet 5
29021bff70
Build and Push Medusa / Escaneo de Secretos (Gitleaks) (push) Successful in 22s
Build and Push Frontend / Escaneo de Secretos (Gitleaks) (push) Successful in 26s
Build and Push Docs Portal / Escaneo de Secretos (Gitleaks) (push) Successful in 28s
Build and Push Medusa / Construir y publicar Medusa (push) Successful in 17m19s
Build and Push Frontend / Construir y Subir Imagen (push) Successful in 8m23s
Build and Push Docs Portal / Construir y publicar Docs Portal (push) Successful in 6m18s
Con el runner corriendo 1 job a la vez (capacity: 1), cuando 2+ pipelines comparten el mismo commit disparador, el primero en terminar deja su propio commit de GitOps en main -- los siguientes veian 'main ya no es igual a mi commit' y se saltaban su propia promocion, aunque era seguro promocionar. Visto en vivo: Frontend construyo, escaneo y firmo v1.0.119 pero el manifiesto seguia en v1.0.104 (Promocion GitOps: false). Fix en los 3 workflows: git merge-base --is-ancestor en vez de comparacion exacta de SHA. Bump manual de frontend a v1.0.119 (la version que ya estaba lista, sin desplegar). Documentado el limite conocido de este fix en el playbook de la migracion. Co-Authored-By: Claude Sonnet 5 <[email protected]> Claude-Session: https://claude.ai/code/session_011FqYP3Wf1W63Qmh7qgXAAT
82 lines
2.8 KiB
YAML
82 lines
2.8 KiB
YAML
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:
|
|
# runAsUser explícito -- ver comentario largo más abajo, junto al
|
|
# container, sobre por qué runAsNonRoot solo no alcanza acá.
|
|
securityContext:
|
|
runAsUser: 1001
|
|
containers:
|
|
- name: app
|
|
image: gitea.cruzcloud.net/devops/ecommerce-frontend:v1.0.119
|
|
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) -- pero runAsNonRoot: true del
|
|
# base SOLO no alcanza: probado en vivo, falló con "container
|
|
# has runAsNonRoot and image has non-numeric user (nextjs),
|
|
# cannot verify user is non-root". El Dockerfile define el
|
|
# usuario por NOMBRE (useradd ... nextjs), y sin un runAsUser
|
|
# numérico Kubernetes no puede confirmar que no sea root sin
|
|
# arrancar el contenedor -- y por eso rechaza arrancarlo. El
|
|
# UID real es 1001 (useradd --uid 1001 ... nextjs en el
|
|
# Dockerfile).
|
|
#
|
|
# 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
|