Service — composant exécutable

📍 Où trouver ça dans l'UI

• ServiceDefinitions : Infra → onglet Architecture → Services
• ServiceInstances : Infra → Environments → {env} → Services

C'est quoi ? Un service est un bout de code qui tourne en permanence (backend, frontend, worker, API…).

Dans Wakastart, un service se définit en 2 niveaux.

ServiceDefinition (niveau Architecture)

C'est la définition générique du service. Tu décris :

→ La ServiceDefinition est le schéma, pas la chose qui tourne réellement.

Configurer le build : rootDirectory, dockerfilePath, buildContext

Trois paramètres ServiceDefinition pilotent l'étape docker build :

Le docker build exécuté est équivalent à :

bashCopier
cd <repo>/<rootDirectory>
docker build -f <dockerfilePath> <buildContext>

Cas 1 — Repo simple, Dockerfile à la racine

textCopier
ws-back-wakastart/
├── Dockerfile
├── package.json
└── src/

Équivaut à : docker build -f Dockerfile . exécuté à la racine du repo.

Cas 2 — Monorepo, projet dans un sous-dossier

textCopier
ws-back-wakastart/
├── apps/
│   ├── backend/
│   │   ├── Dockerfile
│   │   ├── package.json
│   │   └── src/
│   └── worker/
└── packages/

Tu veux builder uniquement apps/backend et limiter l'accès Docker aux fichiers de ce dossier :

Équivaut à : cd apps/backend && docker build -f Dockerfile ..

Le build ne voit que apps/backend/ — ni apps/worker/, ni packages/.

Cas 3 — Monorepo avec lockfile partagé (pnpm/yarn workspaces, turbo…)

Ton service est dans apps/backend/ mais a besoin du pnpm-lock.yaml racine et des packages partagés packages/* pour s'installer :

textCopier
ws-back-wakastart/
├── pnpm-lock.yaml         ← lockfile racine
├── pnpm-workspace.yaml
├── apps/
│   └── backend/
│       └── Dockerfile     ← Dockerfile dédié, mais a besoin du contexte racine
└── packages/
    └── shared/

Équivaut à : docker build -f apps/backend/Dockerfile . à la racine du repo.

Le Dockerfile peut maintenant faire COPY pnpm-lock.yaml ./ et COPY packages/shared ./packages/shared car il a accès à tout le repo.

Règles pratiques

• Plus le buildContext est petit, plus le build est rapide (Docker envoie moins de fichiers au daemon). Si ton service est autonome dans un sous-dossier, choisis le Cas 2.
• Si ton Dockerfile a besoin de fichiers situés au-dessus de son dossier (lockfile racine, packages frères), choisis le Cas 3 — un buildContext plus large mais un dockerfilePath ciblé.
• Un .dockerignore à la racine du buildContext exclut les fichiers indésirables (node_modules, .git, .next/cache…) du contexte envoyé au daemon.

ServiceInstance (niveau Environnement)

C'est l'instance réelle d'un service dans un environnement précis (ex: backend en dev, backend en prod). Elle hérite des valeurs par défaut de la Definition mais peut les overrider :

textCopier
ServiceDefinition "backend"          ServiceInstance backend (env prod)
├── role: BACK                       ├── definitionId → lien
├── defaultReplicas: 1               ├── replicas: 5             ← override prod
├── defaultPort: 3000                ├── port: null               ← utilise 3000
└── defaultMemoryLimit: 512Mi        └── memoryLimit: 2Gi          ← override prod

C'est dans la ServiceInstance que :

• on choisit quelle image Docker est déployée (donc quel build est utilisé)
• on bind les variables à leurs valeurs réelles
• on voit les deployments, les logs, les metrics