DEV Community: Yvan NGOUDJOU

Construire une seule image Docker pour une application Angular et l’exécuter sur tous les environnements

Yvan NGOUDJOU — Sun, 24 Aug 2025 06:45:53 +0000

Contexte

Dans le développement d’applications modernes, il est fréquent de disposer de plusieurs environnements :

Dev pour les développeurs,
Staging pour la validation métier,
Production pour les utilisateurs finaux.

Dans chacun de ces environnements, on déploie généralement une instance du backend et du frontend.
Côté Angular, cela se traduit par plusieurs fichiers de configuration :

environment.ts  
environment.staging.ts  
environment.prod.ts

Lors du build, Angular permet de choisir l’environnement à utiliser grâce au flag :

ng build --configuration=staging

Le problème

Avec cette approche, la configuration est injectée au moment du build de l’image Docker.
Cela pose une contrainte forte en contexte CI/CD :

Si vous construisez votre image Docker avec l’option --configuration=staging, alors même en l’exécutant en Dev, elle utilisera toujours la configuration staging.
Vous êtes donc obligés de reconstruire une image par environnement, ce qui va à l’encontre du principe Build Once, Run Everywhere.

L’approche proposée

Puisqu’Angular ne permet pas encore d’injecter des configurations dynamiquement au runtime, une approche pragmatique consiste à :

1. Centraliser la configuration dans un fichier JSON

Placer la configuration dans un fichier env.json stocké dans /assets/conf.
Lors du démarrage du conteneur, un script entrypoint.sh copie le bon fichier selon l’environnement :

cp env.${ENVIRONMENT}.json  env.json

Exemple de contenu :

{
  "apiUrl": "http://localhost:8080/api",
  "featureFlag": true
}

2. Charger le fichier dynamiquement au lancement de l’application

@Injectable({ providedIn: 'root' })
export class ConfigService {
  private config!: any;

  load(): Promise<void> {
    return fetch('/assets/env.json')
      .then(response => response.json())
      .then(config => this.config = config);
  }

  get apiUrl(): string {
    return this.config.apiUrl;
  }
}

3. Initialiser la configuration avant le bootstrap

Grâce à provideAppInitializer :

bootstrapApplication(AppComponent, {
  providers: [
    provideAppInitializer(async () => {
      const configService = inject(ConfigService);
      await configService.load();
    })
  ]
});

4. Exécution de l'image Docker

Exécute l'image docker en spécifiant la valeur de la variable ENVIRONMENT:

docker run -e ENVIRONMENT=staging  IMAGE_ID

Bénéfices

Une seule image Docker à maintenir et à déployer.
Déploiements simplifiés dans un pipeline CI/CD.
Séparation claire entre le code applicatif (figé dans l’image) et la configuration (injectée au runtime).

Conclusion

Cette approche permet de réellement appliquer le principe Build Once, Run Everywhere avec Angular dans un contexte Docker et CI/CD.

Il serait intéressant qu’Angular propose à terme un mécanisme natif d’injection de configuration au runtime.
En attendant, cette méthode est utilisée dans de nombreux projets en production et reste une solution robuste et pragmatique.

Et vous, comment gérez-vous la configuration multi-environnements pour vos applications Angular déployées sous Docker ?

Sur quels critères décider d’utiliser (ou non) un store comme NgRx dans une application Angular ? C’est une question fréquente — et la réponse n’est pas toujours évidente. Dans cet article, je t’explique quand et pourquoi un store peut être pertinent.

Yvan NGOUDJOU — Fri, 27 Jun 2025 11:15:03 +0000

Quand faut-il utiliser un store comme NgRx dans une application Angular ?

Yvan NGOUDJOU ・ Jun 27

#ngrx #angular #french #frontend

Quand faut-il utiliser un store comme NgRx dans une application Angular ?

Yvan NGOUDJOU — Fri, 27 Jun 2025 11:13:12 +0000

Cet article est rédigé en français. Si vous souhaitez une version anglaise, faites-le-moi savoir en commentaire !

C’est une question que je reçois souvent :

"Est-ce que tu utilises souvent un store dans tes applications Angular ?"

Et lors des échanges, deux visions reviennent régulièrement :

D’un côté, ceux qui pensent que c’est overkill dans la majorité des cas.
De l’autre, ceux qui ont tendance à en mettre partout, parfois par habitude.

Alors, qui a raison ? Et à quoi sert réellement un store ?

Le rôle d’un store

La documentation officielle de NgRx dit :

“NgRx Store provides reactive state management for Angular apps inspired by Redux. Unify the events in your application and derive state using RxJS.”

Ce petit paragraphe met en lumière un aspect souvent négligé :

l’unification des événements dans l’application.

Un store ne se limite pas à stocker des données. Il peut aussi agir comme un orchestrateur d’événements métier.

Pourquoi utiliser un store pour orchestrer des intentions métier ?

Cela permet par exemple de découpler les composants des services applicatifs :

les composants n’émettent que des intentions (via des actions),

et ce sont les effects ou handlers qui les traitent.

Résultat : une architecture claire, modulaire, et surtout testable.

🛒 Exemple concret : Ajouter un produit au panier

🔻 Sans store :

this.isLoading = true;
this.cartService.addProduct(product).subscribe({
  next: () => {
    this.cart.push(product);
    this.isLoading = false;
  },
  error: () => {
    this.error = 'Échec';
    this.isLoading = false;
  }
});

Avec NgRx (approche orientée événements) :

Le composant ne sait rien de l'objet qui exécute le comportement associé à l'action.

//component.ts 

this.store.dispatch(addToCart({ product }));


// effect.ts

// effect
createEffect(() =>
  this.actions$.pipe(
    ofType(addToCart),
    exhaustMap(product =>
      this.cartService.addProduct(product).pipe(
        map(() => addToCartSuccess({ product })),
        catchError(() => of(addToCartFailure()))
      )
    )
  )
);

Et la gestion d’état ?

Bien sûr, un store permet aussi de centraliser et structurer l’état global de ton application.

Mais si tu veux l’utiliser uniquement pour partager du state, je te recommande de le faire seulement si plusieurs composants doivent lire et écrire sur ces mêmes données.

En résumé : quand utiliser un store ?

Un store devient pertinent si :

Tu dois orchestrer une logique métier via des événements
Tu veux modéliser des intentions utilisateur de manière claire
Tu partages un même état entre plusieurs composants

Quelques cas typiques :

✅ Une app de prise de rendez-vous (avec loading, erreurs, confirmations…)
✅ Une app de chat ou de jeu en WebRTC
✅ Un tunnel de paiement à étapes multiples
✅ Des entités partagées dans plusieurs contextes

Dans tous ces cas, le store ne sert pas à stocker des données. Il sert à modéliser le comportement métier.

❌ Et quand ne pas utiliser de store ?

Pour des données statiques en lecture seule (ex : liste de pays)
Pour un état local et isolé dans un seul composant
Quand la logique métier est triviale et linéaire

En conclusion

Ne mets pas un store pour chaque jeu de données.
Mais ne le rejette pas sous prétexte que ton app est “petite”.

Mets un store quand tu veux modéliser clairement une interaction utilisateur, même locale.

Ce qui compte, ce n’est pas la taille de ton app,
mais la clarté de l’intention et la prévisibilité du comportement.

💬 Et toi, dans quels cas choisis-tu d’utiliser un store ?
Partage ton expérience ou pose tes questions en commentaire !