J'essaie d'insérer une chaîne json multiligne dans le modèle de barre pour l'encodage base64 requis pour le secret Kubernetes.
Objectifs:
b64enc
myfile1.json
ne fonctionne pas mais myfile2.json
fonctionne.
Je préfère ne pas mettre tout le fichier json dans values.yaml
.
apiVersion: v1 kind: Secret metadata: name: {{ template "mychart.fullname" . }} labels: app: {{ template "mychart.name" . }} chart: {{ template "mychart.chart" . }} release: {{ .Release.Name }} heritage: {{ .Release.Service }} type: Opaque data: myfile.json: {{ |- { "item1": { "name": "{{ .Values.item1.name }}" }, "item2": { } } | b64enc }} myfile2.json: {{ .Values.myfile2 | b64enc }}
3 Réponses :
Mon impression (et d'autres semblent l'avoir frappée aussi ) est que vous devez faire un compromis soit sur le fait qu'il soit multiligne ou sur le fait de ne pas le mettre dans un fichier. Je pense que le problème est que vous devez utiliser une instruction yaml (le | -
) pour obtenir plusieurs lignes et cela fait partie du modèle lui-même, vous ne pouvez donc pas en obtenir une d'une manière que vous pouvez ensuite alimenter dans b64enc
.
S'il s'agissait d'un ConfigMap, vous n'auriez pas besoin de nourrir b64enc
donc ce serait aussi simple que:
myfile: item1: name: "bob" item2: name: "fred"
Ou si vous devaient faire un compromis sur une approche sur une seule ligne, alors cela pourrait être:
monfichier.json: {{tpl ("{'item1': {'name': '{{.Values.item1. name}} '},' item2 ': {}} "). | toJson | b64enc}}
S'il provenait d'un fichier, vous pouvez utiliser {{tpl (.Files.Get "files / myfile.json"). | b64enc | quote}}
Une autre option serait de mettez tout le json dans le fichier de valeurs
Ou vous pouvez avoir une entrée myfile
dans votre fichier de valeurs comme:
myfile.json: | { "item1": { "name": "{{ .Values.item1.name }}" }, "item2": { } }
Et puis utilisez-le avec myfile.json: {{.Values.myfile | toJson | b64enc}}
J'ai trouvé une solution. Vous pouvez utiliser la fonction tpl sur le fichier json pour rendre le modèle.
{ "item1": { "name": "{{ .Values.item1.name }}" }, "item2": { } }
myfile.json
apiVersion: v1 kind: Secret metadata: name: {{ template "mychart.fullname" . }} labels: app: {{ template "mychart.name" . }} chart: {{ template "mychart.chart" . }} release: {{ .Release.Name }} heritage: {{ .Release.Service }} type: Opaque data: myfile.json: {{ tpl(.Files.Get "myfile.json") . | b64enc }}
En fait, vous n'avez pas besoin d'encoder en base64 le secret dans le graphique de barre. Si vous utilisez le champ stringData
au lieu du champ data
, Kubernetes sait qu'il doit encoder en base64 les données lors du déploiement du secret.
À partir de la documentation ( Source ):
Le Secret contient deux cartes:
data
etstringData
. Le champdata
est utilisé pour stocker des données arbitraires, encodées en base64. Le champstringData
est fourni pour plus de commodité et vous permet de fournir des données secrètes sous forme de chaînes non codées.
Nous pouvons donc réécrire votre secret en utilisant stringData
au lieu de data
et conserver les chaînes json multilignes dans des modèles comme ceci:
apiVersion: "v1" kind: "Secret" metadata: name: {{ template "mychart.fullname" . }} labels: app: {{ template "mychart.name" . }} chart: {{ template "mychart.chart" . }} release: {{ .Release.Name }} heritage: {{ .Release.Service }} type: "Opaque" stringData: myfile.json: |- { "item1": { "name": "{{ .Values.item1.name }}" }, "item2": { } } myfile2.json: {{ .Values.myfile2 }}
Notez que cela ne signifie pas que vous devez soudainement vous inquiéter d'avoir des secrets non codés. stringData
sera finalement encodé en base64 et converti en données
lors de son installation, il se comportera donc exactement de la même manière une fois chargé dans Kubernetes.
Encore une fois, à partir de la documentation (c'est moi qui souligne) ( Source ):
stringData
permet de spécifier des données secrètes non binaires sous forme de chaîne. Il est fourni comme une méthode pratique en écriture seule. Toutes les clés et valeurs sont fusionnées dans le champdata
lors de l'écriture, en écrasant toutes les valeurs existantes. Il n'est jamais généré lors de la lecture à partir de l'API.