devopsandClaude Sonnet 5
42e6250adc
Build and Push Medusa / Escaneo de Secretos (Gitleaks) (push) Successful in 22s
Build and Push Frontend / Escaneo de Secretos (Gitleaks) (push) Successful in 22s
Build and Push Docs Portal / Escaneo de Secretos (Gitleaks) (push) Successful in 20s
Build and Push Medusa / Construir y publicar Medusa (push) Successful in 19m12s
Build and Push Frontend / Construir y Subir Imagen (push) Successful in 10m5s
Build and Push Docs Portal / Construir y publicar Docs Portal (push) Successful in 4m55s
Los 3 pipelines (build.yaml, build-medusa.yaml, deploy-docs.yaml) todavia apuntaban a las rutas viejas de deployment.yaml (borradas al migrar cada app a un overlay de platform-templates) para el paso de auto-actualizacion GitOps. Se rompio en vivo en el primer build real post-migracion (docs-portal v1.0.117): la imagen se construyo, escaneo y firmo bien, pero el ultimo paso (sed sobre el manifest) fallo con 'No such file or directory'. Se corrigen las 3 rutas a patches/deployment.yaml, y se bumpea a mano el tag de docs-portal a v1.0.117 (la imagen ya existe en el registry, firmada y verificada, no hace falta reconstruirla). Co-Authored-By: Claude Sonnet 5 <[email protected]> Claude-Session: https://claude.ai/code/session_011FqYP3Wf1W63Qmh7qgXAAT
57 lines
2.3 KiB
YAML
57 lines
2.3 KiB
YAML
apiVersion: apps/v1
|
|
kind: Deployment
|
|
metadata:
|
|
name: app-deployment
|
|
labels:
|
|
app: docs-portal
|
|
spec:
|
|
replicas: 1
|
|
selector:
|
|
matchLabels:
|
|
app: docs-portal
|
|
template:
|
|
metadata:
|
|
labels:
|
|
app: docs-portal
|
|
spec:
|
|
# El base fuerza runAsNonRoot: true a nivel pod. La imagen ACTUAL
|
|
# de docs-portal (nginx:1.27-alpine, sin USER) corre como root --
|
|
# aplicar el default del base tal cual rompe el pod
|
|
# (CreateContainerConfigError). Override explícito acá hasta que
|
|
# docs-portal adopte dockerfiles/static-nginx.Dockerfile
|
|
# (nginx-unprivileged, no-root) como cambio de imagen aparte --
|
|
# no es parte de esta migración de manifiestos.
|
|
securityContext:
|
|
runAsNonRoot: false
|
|
containers:
|
|
- name: app
|
|
image: gitea.cruzcloud.net/devops/docs-portal:v1.0.117
|
|
# El base saca TODAS las capabilities. Probado en vivo y
|
|
# revertido: con drop: ALL (aunque se agregue NET_BIND_SERVICE
|
|
# de vuelta) el propio entrypoint de nginx:1.27-alpine falla al
|
|
# arrancar -- necesita CAP_CHOWN para el chown() que hace sobre
|
|
# /var/cache/nginx/client_temp en cada arranque ("Operation not
|
|
# permitted", confirmado en el log real del pod). No vale la
|
|
# pena ir agregando capabilities una por una a ciegas -- se
|
|
# deja sin restricción de capabilities, igual que como corre
|
|
# hoy en producción (no es peor que el estado actual). Se
|
|
# resuelve del todo cuando docs-portal pase a
|
|
# nginx-unprivileged (no necesita root ni capabilities
|
|
# especiales para nada de esto).
|
|
securityContext:
|
|
allowPrivilegeEscalation: false
|
|
readOnlyRootFilesystem: false
|
|
# Ni omitir "capabilities" ni un objeto vacío {} alcanzan
|
|
# para anular el drop:[ALL] del base (probado en vivo, los
|
|
# dos dejaron el drop:[ALL] heredado intacto). "null" es la
|
|
# forma real de borrar un campo heredado en un patch de
|
|
# merge de Kubernetes/Kustomize.
|
|
capabilities: null
|
|
resources:
|
|
requests:
|
|
cpu: 50m
|
|
memory: 64Mi
|
|
limits:
|
|
cpu: 200m
|
|
memory: 128Mi
|