26 lines
2.6 KiB
Markdown
26 lines
2.6 KiB
Markdown
# Infra & DevOps : Docker, Podman, PostgreSQL, Gitea
|
|
|
|
## Docker / Podman
|
|
|
|
- Image de base : vérifier une version explicite et pinnée (pas de `latest` en prod/CI) → `latest` non pinné = 🟠.
|
|
- Utilisateur non-root dans le conteneur pour tout ce qui tourne en prod/CI — root par défaut sans justification = 🟠 (surface d'attaque).
|
|
- Multi-stage build pour limiter la taille de l'image finale (surtout pour du Java/Node buildé) — absence sur un build lourd = 🟡.
|
|
- `.dockerignore` présent et cohérent pour éviter d'embarquer des secrets/fichiers inutiles = vérifier systématiquement.
|
|
- Podman vs Docker : si rootless Podman est utilisé (cohérent avec le choix du studio d'éviter le daemon root), vérifier que les volumes/permissions UID/GID sont gérés correctement (mapping utilisateur) plutôt que de forcer du root.
|
|
- Secrets : jamais de secret en clair dans un `Dockerfile`/`docker-compose.yml`/`ENV` versionné = 🔴 systématique.
|
|
|
|
## PostgreSQL
|
|
|
|
- Migrations : toute modification de schéma doit passer par un outil de migration versionné (pas d'ALTER manuel non tracé) = 🟠 minimum, 🔴 si ça touche une table en prod sans rollback prévu.
|
|
- Index : vérifier la présence d'index sur les colonnes utilisées en `WHERE`/`JOIN` fréquents avant de valider une requête qui semble lente.
|
|
- Transactions : opérations multi-tables qui doivent être atomiques mais ne sont pas dans une transaction explicite = 🔴 potentiel (incohérence de données).
|
|
- Connexions : pooling de connexions plutôt que d'ouvrir une connexion par requête dans du code applicatif à fort volume.
|
|
- Types : privilégier les types PostgreSQL adaptés (`timestamptz` plutôt que `timestamp` sans fuseau, `numeric` pour les montants plutôt que `float`).
|
|
|
|
## Gitea (workflow & CI)
|
|
|
|
- Branch protection sur `main` : vérifier que le workflow proposé respecte la protection de branche déjà en place (cf. préférences de Benjamin sur la hygiène de clés/rotation et les accès agents IA).
|
|
- PR/Issue : cohérence avec la structure EPIC=Milestone / FEATURE=Issue / STORY=checklist item définie dans la skill `agile-master` — ne pas réinventer une autre convention de nommage dans une review.
|
|
- CI (Gitea Actions ou runner équivalent) : tout script de CI doit être idempotent et échouer explicitement (exit code non nul) en cas de problème plutôt que de continuer silencieusement.
|
|
- Clés/déploiement : pour tout ce qui touche l'accès Git d'un agent (SSH, PAT), rappeler la préférence du studio pour des deploy keys ou PAT fine-grained scopés (`Contents: write` + `Pull requests: write`) plutôt qu'un accès large — accès trop large proposé = 🟠.
|