Vous pouvez utiliser un seul graphique avec les deux déploiements ou un graphique principal avec deux sous-graphiques, un pour app-nginx-phpfpm.yaml et un pour app-mysql.yaml . Si l'ensemble de votre application ne se développe pas autant, vous pouvez utiliser un seul graphique. Cependant, si vous prévoyez de continuer à ajouter des composants à votre application (plus de déploiements, etc.), il est recommandé d'utiliser des sous-graphiques. Plus d'informations ici .

Vous pouvez avoir les deux, selon la manière dont vous souhaitez structurer vos déploiements.

Vous devez garder à l'esprit les points suivants

Considérations

Avantages du graphique unique

• Plus facile à déployer: déployer une seule fois, une seule différence
• Version unique, donc les restaurations / mises à niveau se produisent sur un seul élément
• Vous pouvez désinstaller des pièces en utilisant des indicateurs de fonction
• Installer un nouveau composant sans toucher au reste des éléments peut s'avérer délicat

Mises en garde concernant un seul graphique

• Plus difficile à déployer des services découplés, par exemple un service simulé pour l'accès aux données lors de la mise à niveau de la base de données
• Plus difficile à découpler et à tester chaque instance
• Plus difficile à nommer et à comprendre chaque composant (dans différentes versions, votre {{.Release.Name}} changerait déjà pour chaque "application").
• Plus difficile à fournir / à suivre les différents cycles de publication pour différents composants
• Versions stockées dans une seule ConfigMap, ce qui peut entraîner des problèmes de limite de taille si vous avez des graphiques contenant, par exemple, des données de test intégrées

Remarque sur le contrôle de version

Vous pouvez avoir un diagramme principal que vous utilisez pour tester tous les sous-diagrammes, et empaqueter les sous-diagrammes indépendamment tout en conservant tout sur le même référentiel. p >

Par exemple, je garde généralement des éléments comme:

. / helm / charts / whatever-master / values.yaml
. / helm / charts / whatever-master / requirements.yaml
. / helm / charts / whatever-subchart1 / values.yaml
. / helm / charts / whatever-subchart2 / values.yaml

ou

. / helm / charts / whatever / charts / subchart1
. / helm / charts / whatever / charts / subchart2
. / helm / charts / whatever / values.yaml

Et j'utilise les exigences. yaml sur le diagramme principal pour extraire du file://../whatever-subchartx.

De cette façon, je peux avoir n'importe quel-stress-test et any-subcomponent-unit-test tout en étant flexible pour déployer séparément des composants qui ont des cycles de publication différents si vous le souhaitez.

Cela dépendra également en fin de compte de votre stratégie de mise à niveau . Les mises à niveau de Canary vous obligeront probablement à gérer les microservices avec état d'une manière plus spécifique que ce que vous pouvez avoir avec un seul graphique, alors planifiez en conséquence.

Les graphiques peuvent dépendre d'autres graphiques; référence - https://helm.sh/docs/glossary/#chart-dependency- sous-graphiques .

Si vous avez une application parent, dites: - salutations-app et 2 applications enfants, dites: - Bonjour le monde - hiworld

Vous pouvez créer un graphique pour le parent "greetings-app", puis dans le répertoire "charts /" faire déplacer ou créer les graphiques de "helloworld" et "hiworld" lorsque vous installez le chart "greetings-app" - vous installerez automatiquement les graphiques dépendants avec lui. Vous devrez créer "requirements.yaml" dans le parent (greetings-app) listant les dépendances

dependencies:
  - name: helloworld-app
    repository: https://raw.githubusercontent.com/.../myhelmcharts/master/
    version: 0.1.0
    tags:
      - helloworld
  - name: hiworld-app
    repository: https://raw.githubusercontent.com/.../myhelmcharts/master/
    version: 0.1.0
    tags:
      - hiworld

Dossier des graphiques illustratifs La structure serait: -

• salutations /
  • graphiques /
  • helloworld /
    • graphiques /
    • modèles /
    • ....
  • hiworld /
    • graphiques /
    • modèles
    • ....
  • Chart.yaml
  • requirements.yaml # ceci répertorie les dépendances

Une autre méthode consiste à empaqueter les applications enfants et à les héberger sur un serveur http (GitHub), puis à créer les exigences.yaml listant les dépendances

dependencies:
  - name: helloworld
  - name: hiworld

Le plus tard est probablement la méthode préférée - à mon avis, c'est la dépendance douce, mais l'application est gérée séparément.