Мы используем Helm для развертывания нашего приложения на K8s. В 4 разных файлах развертывания (по одному для каждой службы) и файле задания для миграции у нас должен быть идентичный набор переменных env
. Каждый раз, когда нам нужно добавить новый, нам нужно добавить его ко всем 5 файлам. Есть ли способ поделиться этими переменными, чтобы новые переменные окружения нужно было добавить только один раз, и все 5 файлов заберут их (а также не могут быть рассинхронизированы)?
Вот пример файла развертывания (с потенциально конфиденциальным значения отредактированы).
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ include "helm-chart.fullname" . }}-celery
labels:
app.kubernetes.io/name: {{ include "helm-chart.name" . }}-celery
helm.sh/chart: {{ include "helm-chart.chart" . }}
app.kubernetes.io/instance: {{ .Release.Name }}-celery
app.kubernetes.io/managed-by: {{ .Release.Service }}
app.kubernetes.io/component: worker-celery
spec:
replicas: {{ .Values.replicaCountCelery }}
selector:
matchLabels:
app.kubernetes.io/name: {{ include "helm-chart.fullname" . }}-celery
app.kubernetes.io/instance: {{ .Release.Name }}-celery
template:
metadata:
labels:
app.kubernetes.io/name: {{ include "helm-chart.fullname" . }}-celery
app.kubernetes.io/instance: {{ .Release.Name }}-celery
spec:
imagePullSecrets:
- name: {{ .Values.imagePullSecretsName }}
containers:
- name: {{ .Chart.Name }}-celery
image: "{{ .Values.appImage.repository }}:{{ .Values.imageTag }}"
imagePullPolicy: {{ .Values.appImage.pullPolicy }}
command: ["celery"]
args: [REDACTED]
env:
- name: DJANGO_DEBUG
value: "{{ .Values.djangoDebug }}"
- name: DATABASE_NAME
value: "{{ .Values.databaseName }}"
- name: DATABASE_USER
valueFrom:
secretKeyRef:
name: [REDACTED]
key: [REDACTED]
- name: DATABASE_PASSWORD
valueFrom:
secretKeyRef:
name: [REDACTED]
key: [REDACTED]
- name: DATABASE_HOST
value: "myapp-haproxy.{{ .Release.Namespace }}.svc.cluster.local"
- name: MEMCACHED_HOST
value: "myapp-memcached.{{ .Release.Namespace }}.svc.cluster.local"
- name: SENDGRID_USER
valueFrom:
secretKeyRef:
name: [REDACTED]
key: [REDACTED]
- name: SENDGRID_PASSWORD
valueFrom:
secretKeyRef:
name: [REDACTED]
key: [REDACTED]
- name: STRIPE_LIVE_PUBLIC_KEY
valueFrom:
secretKeyRef:
name: [REDACTED]
key: [REDACTED]
- name: STRIPE_LIVE_SECRET_KEY
valueFrom:
secretKeyRef:
name: [REDACTED]
key: [REDACTED]
- name: OBJECT_STORE_ENDPOINT_URL
value: [REDACTED]
- name: OBJECT_STORE_REGION_NAME
value: [REDACTED]
- name: OBJECT_STORE_KEY_ID
valueFrom:
secretKeyRef:
name: [REDACTED]
key: [REDACTED]
- name: OBJECT_STORE_ACCESS_KEY
valueFrom:
secretKeyRef:
name: [REDACTED]
key: [REDACTED]
- name: OBJECT_STORE_CDN_URL
value: [REDACTED]
- name: QUICKBOOKS_CLIENT_ID
valueFrom:
secretKeyRef:
name: [REDACTED]
key: [REDACTED]
- name: QUICKBOOKS_CLIENT_SECRET
valueFrom:
secretKeyRef:
name: [REDACTED]
key: [REDACTED]
- name: QUICKBOOKS_ENVIRONMENT
value: production
- name: XERO_CONSUMER_KEY
valueFrom:
secretKeyRef:
name: [REDACTED]
key: [REDACTED]
- name: XERO_CONSUMER_SECRET
valueFrom:
secretKeyRef:
name: [REDACTED]
key: [REDACTED]
- name: SAGE_CLIENT_ID
valueFrom:
secretKeyRef:
name: [REDACTED]
key: [REDACTED]
- name: SAGE_CLIENT_SECRET
valueFrom:
secretKeyRef:
name: [REDACTED]
key: [REDACTED]
- name: ACCOUNTANCY_REDIRECT_URI_PREFIX
value: [REDACTED]
resources:
{{- toYaml .Values.celeryResources | nindent 12 }}
{{- with .Values.nodeSelector }}
nodeSelector:
{{- toYaml . | nindent 8 }}
{{- end }}
{{- with .Values.affinity }}
affinity:
{{- toYaml . | nindent 8 }}
{{- end }}
{{- with .Values.tolerations }}
tolerations:
{{- toYaml . | nindent 8 }}
{{- end }}
Я не уверен, добавляет ли это каких-либо сложностей, но вы можете видеть, что некоторые используют переменные из values.yaml
(например, {{.Values.djangoDebug} }
), некоторые ссылаются на секреты Kubernetes, а некоторые используют переменную {{.Release.Namespace}}
.
Кроме того, требуемый отступ такой же для развертывания 4
файлы, но разные для файла job
.
Я пытаюсь поделиться кучей значений env
, но также могу при желании добавить некоторые дополнения к некоторым файлам.
Надеюсь, в этом есть смысл? Заранее благодарим за помощь.
Если я правильно вас понял, вам понадобится ConfigMap
.
Многие приложения требуют настройки с помощью некоторой комбинации config. файлы, аргументы командной строки и переменные среды. Эти артефакты конфигурации должны быть отделены от содержимого изображения в чтобы сохранить переносимость контейнерных приложений. API ConfigMap ресурс предоставляет механизмы для внедрения контейнеров с конфигурацией данные, сохраняя при этом независимость контейнеров от Kubernetes. ConfigMap может быть используется для хранения подробной информации, такой как отдельные свойства или общая информация, такая как целые файлы конфигурации или большие двоичные объекты JSON.
В основном вы создаете ConfigMap и устанавливаете правильный ключ: значение
. После этого вы используете созданную ConfigMap
, чтобы объявить ее значения как среду в ваших развертываниях
.
Здесь вы можете найти официальный пример :
Создайте ConfigMap, содержащую несколько пар ключ-значение.
apiVersion: v1
kind: ConfigMap
metadata:
name: special-config
namespace: default
data:
SPECIAL_LEVEL: very
SPECIAL_TYPE: charm
Используйте envFrom
, чтобы определить все ConfigMap
данные как переменные среды контейнера. Ключ из ConfigMap
становится именем переменной среды в модуле.
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: k8s.gcr.io/busybox
command: [ "/bin/sh", "-c", "env" ]
envFrom:
- configMapRef:
name: special-config
restartPolicy: Never
Теперь выходные данные модуля включают переменные среды SPECIAL_LEVEL = very
и SPECIAL_TYPE = charm
Приспособьтесь к своим потребностям и дайте мне знать, помогло ли это.