web-dev-qa-db-fra.com

Comment pouvez-vous appeler un modèle «helper» de barre à partir d'un sous-diagramme avec le contexte correct?

Helm les graphiques définissent les modèles d'assistance dans _helpers.tpl qui sont utilisés pour créer des noms normalisés pour les services. La forme standard du modèle pour un nom de service (DNS) est:

{{- define "postgresql.fullname" -}}
{{- $name := default .Chart.Name .Values.nameOverride -}}
{{- printf "%s-%s" .Release.Name $name | trunc 63 | trimSuffix "-" -}}
{{- end -}}

Si vous utilisez postgresql comme sous-graphique, comment êtes-vous censé utiliser la découverte de services basée sur DNS pour vous y référer? Un modèle courant semble être de copier les assistants de sous-diagramme dans le diagramme parent.

{{- define "keycloak.postgresql.fullname" -}}
{{- $name := default "postgresql" .Values.postgresql.nameOverride -}}
{{- printf "%s-%s" .Release.Name $name | trunc 63 | trimSuffix "-" -}}
{{- end -}}

C'est de la folie totale pour des raisons évidentes !!!

Il y a sûrement une meilleure façon d'utiliser l'assistant de sous-diagramme? Si vous pouviez créer un objet contextuel, il serait possible de l'invoquer, quelque chose comme:

value: {{ template "postgresql.fullname" ({Chart: {Name: 'not-used'}, Release: {Name: .Release.Name}, Values: { nameOverride: .Values.postgresql.nameOverride}}) }}

Malheureusement, je ne sais pas comment créer un tel contexte de manière dynamique. Cela se briserait toujours si la fonction d'aide changeait pour référencer de nouvelles propriétés, mais de manière évidente.

Alternativement, une manière différente de rendre disponible le nom du service à partir d'un sous-graphique?

go-templateskubernetes-helm
13
moreginger

J'ai écrit un problème helm/helm#4535 qui résume le statu quo et propose une amélioration de Helm qui résoudra ce cas.

Pour tous ceux qui recherchent une solution provisoire, j'ai écrit (voir mon commentaire de suivi pour plus de détails) un méta-modèle qui appelle un modèle donné dans la portée d'un sous-graphique "ersatz". Il fonctionne en synthétisant un objet point. Ce n'est pas parfait (tous les champs ne sont pas synthétisés), mais ça fera:

{{- define "call-nested" }}
{{- $dot := index . 0 }}
{{- $subchart := index . 1 }}
{{- $template := index . 2 }}
{{- include $template (dict "Chart" (dict "Name" $subchart) "Values" (index $dot.Values $subchart) "Release" $dot.Release "Capabilities" $dot.Capabilities) }}
{{- end }}

Utilisation (pour appeler un redis.fullname modèle d'un sous-diagramme redis):

{{ include "call-nested" (list . "redis" "redis.fullname") }}
5
intelfx

Eh bien, c'est quelque chose qui n'est pas très simple d'une manière ou d'une autre.

Je pense que ce qui se passe ici sont les pratiques suivies par Helm et ce qui est possible avec les modèles.

Une pratique est "les graphiques fonctionnent prêts à l'emploi" - donc que ce soit un sous-graphique ou autonome, cela devrait simplement fonctionner. Cela a des conséquences sur ce que vous devez configurer pour correctement nommer les ressources que vous déployez et qui sont référencées.

J'ai eu un problème très similaire, voir Comment référencer une valeur définie dans un modèle dans un sous-graphique en barre pour kubernetes?

Ma "solution" à cela est de redéfinir le postgres.fullname dans mon propre _helpers.tpl:

{{- define "postgresql.fullname" -}}
{{- $name := printf "%s-%s" .Values.global.appId .Values.global.fkNameId -}}
{{- printf "%s-%s" $name "postgresql" | trunc 63 | trimSuffix "-" -}}
{{- end -}}

Étant donné que les noms de version doivent être uniques par installation de tiller - et nous avons un tiller dans le cluster - j'ai en quelque sorte pris une certaine distance en utilisant le nom de version dans le cadre des références et de la propre convention de dénomination.

Les définitions dans les modèles sont globales. Vous pouvez donc simplement les utiliser si vous êtes bon avec le préfixe du nom de version qui définit par défaut le graphique postgres:

{{- define "postgresql.fullname" -}}
{{- $name := printf "%s-%s" .Values.global.appId .Values.global.fkNameId -}}
{{- printf "%s-%s" $name "postgresql" | trunc 63 | trimSuffix "-" -}}
{{- end -}}

Je ne pouvais pas trouver de noms de version qui ne dupliqueraient pas les noms de service ("webshop-service-webshop-service"), donc j'ai tendance à ne pas les utiliser car j'en ai besoin par espace de noms, pas par instance de tiller.

Une fois que j'ai défini le nom à partir du sous-graphique, je le référence dans mes services. Je suis d'accord avec cela car je sais à quel graphique je fais référence et ce qu'il utilise pour les noms. Mais c'est vrai: dois-je mettre à niveau le sous-graphique, je dois vérifier si les noms sont toujours les mêmes. Mais comme ce "nom complet" est assez courant, je pense que je suis bon. Et certains tests échoueraient de toute façon.

Mais pas une belle "solution".

Pas une réponse - juste assez bon pour moi :)

1
wemu

Je suis très vert avec Helm, donc je pourrais lancer de mauvaises pratiques (bien que je ne le pense pas). D'après ce que je comprends, un modèle nommé est disponible à l'échelle mondiale pour tous les parents et sous-graphiques. Ce n'est cependant pas vrai pour les valeurs. Les valeurs parent ne sont pas accessibles à un sous-graphique mais les valeurs de sous-graphique sont accessibles par un parent.

Cité de https://docs.helm.sh/chart_template_guide/#declaring-and-using-templates-with-define-and-template ...

"Il y a un détail très important à garder à l'esprit lors de la dénomination des modèles: les noms de modèle sont globaux. Si vous déclarez deux modèles avec le même nom, celui qui sera chargé en dernier sera celui utilisé. Parce que les modèles des sous-graphiques sont compilés avec top -modèles de niveau, vous devez faire attention à nommer vos modèles avec des noms spécifiques au graphique. "

Référence:
https://docs.helm.sh/chart_template_guide/#named-templateshttps://docs.helm.sh/chart_template_guide/#subcharts-and-global -valeurs

0
Henry Dobson