Развертывание микросервиса в Kubernetes с PostgreSQL через Helm - PullRequest
Новая
       3

Развертывание микросервиса в Kubernetes с PostgreSQL через Helm

0 голосов
/ 21 февраля 2020

У нас есть несколько микросервисов, и у всех этих микросервисов есть своя таблица рулевого управления и репозиторий SCM. У нас также есть два разных кластера для каждой стадии и производственной среды. Для одного из микросервисов необходимо использовать PostgreSQL. В соответствии с политикой компании у нас была отдельная команда, которая создавала Helm Charts для Postgre, и мы должны использовать это и должны независимо развернуть наш кластер k8s. Из-за того, что у нас нет собственного репозитория Helm, я думаю, нам нужно использовать ConfigMap или Secrets или оба для интеграции PostgreSQL в наш микросервис.

Возможно, это общий вопрос, но я не смог найти Speci c примеры, как интегрировать базу данных без использования зависимости. Так что, я думаю, мне нужно добавить информацию базы данных в качестве ENV в deploy.yaml, как показано ниже, но каковы лучшие практики использования Configmap или Secrets и как они должны выглядеть в шаблонах и как следует передавать URL, имя пользователя, пароль в соответствии с среда безопасным способом? 

  env:
    - name: SPRING_DATASOURCE_URL
      valueFrom:
        configMapKeyRef: 
          name: postgres-production
          key: jdbc-url
    - name: SPRING_DATASOURCE_USERNAME
      valueFrom:
        secretKeyRef:
          name: postgres-production
          key: username
    - name: SPRING_DATASOURCE_PASSWORD
      valueFrom:
        secretKeyRef:
          name: postgres-production
          key: password

Дерево Микросервиса 

├── helm
│   └── oneapihub-mp
│       ├── Chart.yaml
│       ├── charts
│       ├── templates
│       │   ├── NOTES.txt
│       │   ├── _helpers.tpl
│       │   ├── deployment.yaml
│       │   ├── ingress.yaml
│       │   ├── networkpolicy.yaml
│       │   ├── service.yaml
│       │   ├── serviceaccount.yaml
│       │   └── tests
│       │       └── test-connection.yaml
│       ├── values.dev.yaml
│       ├── values.prod.yaml
│       ├── values.stage.yaml

Ответы [ 2 ]

0 голосов
/ 21 февраля 2020

Если у вас есть требование устанавливать и управлять базой данных отдельно от вашего контейнера, вам необходимо рассматривать ее как внешнюю базу данных. Помимо указанного c имени хоста, на самом деле не имеет значения, работает ли база данных в одном и том же пространстве имен, в другом пространстве имен или вообще вне кластера.

Если ваша операционная команда PostgreSQL Контейнер генерирует указанную пару c ConfigMap и Secret, которую вы указали в вопросе, и он всегда будет находиться в одном и том же пространстве имен Kubernetes, тогда единственное изменение, которое я хотел бы сделать, это сделать его параметризуемым там, где именно это развертывание. 

# values.yaml

# postgresName has the name of the PostgreSQL installation.
postgresName: postgres-production

env:
  - name: SPRING_DATASOURCE_URL
    valueFrom:
      configMapKeyRef: 
        name: {{ .Values.postgresName }}
        key: jdbc-url

Если они предоставляются Helm в качестве значений конфигурации ... 

# values.yaml
postgres:
  url: ...
  username: ...
  password: ...

... Я бы, вероятно, поместил части имени пользователя и пароля в Secret и включил бы их, как вы сделали здесь. Хотя, вероятно, я бы напрямую ввел часть URL. В этом нет ничего плохого в использовании ConfigMap, и он соответствует тому, как вы бы поступали без Helm, но для дополнительного уровня косвенности нет особой ценности. 

env:
  - name: SPRING_DATASOURCE_URL
    value: {{ .Values.postgres.url | quote }}
  - name: SPRING_DATASOURCE_USERNAME
    valueFrom:
      secretKeyRef:
        name: {{ template "chart.name" . }}
        key: postgresUsername

Когда вы go чтобы развернуть диаграмму, вы можете предоставить переопределенный набор значений Хелма. Поместите некоторый разумный набор значений по умолчанию в файл values.yaml диаграммы, но затем сохраните отдельный файл значений для каждой среды. 

helm upgrade --install myapp . -f values.qa.yaml
# where values.qa.yaml has database settings for your test environment
0 голосов
/ 21 февраля 2020

Я думаю, что это mysql Диаграмма руля ответ на ваш вопрос.

Вам нужно проверить 3 ямля.

Вы можете создать свой собственный пароль в values.yaml. 

 ## Create a database user
 ##  
 # mysqlUser:
 ## Default: random 10 character string
 # mysqlPassword:

Который будет взят в тайне и закодирован с использованием base64 .

mysql - пароль: {{.Values .mysqlPassword | b64en c | цитата}}

Тогда это будет принято при развертывании. 

- name: MYSQL_PASSWORD
          valueFrom:
            secretKeyRef:
              name: {{ template "mysql.secretName" . }}
              key: mysql-password

И еще немного о секретах на основе документации kubernetes .

Секреты Kubernetes позволяют хранить и управлять конфиденциальной информацией, такой как пароли, OAuth токены и s sh ключи. Хранение конфиденциальной информации в секрете является более безопасным и более гибким, чем дословное ее размещение в определении контейнера или в образе контейнера.

Исходя из моих знаний, это именно так и должно быть.

РЕДАКТИРОВАТЬ

Я добавляю mysql в качестве примера, есть postgres диаграмма . Идея все та же.

Я не совсем понимаю, как мне создать конфиг и секретный yaml в моем приложении?

Вы можете создать секрет перед диаграммой, но вы можете сделать secret.yaml в шаблоны и сделайте там секрет, который будет создан с остальными yamls при установке диаграммы и будет принимать учетные данные из values.dev, prod, stage.yamls.

достаточно использовать только эту переменную env?

Да, как вы можете видеть из ответа, если вы создадите какой-то пароль в values.yaml, тогда он будет принят в секрете при развертывании с secretKeyRef. развернуть мое приложение в том же пространстве имен?

Я не понимаю этого вопроса, вы можете указать пространство имен для своего приложения или развернуть все в пространстве имен по умолчанию.

Я надеюсь, что он ответит на ваш вопрос. Дайте мне знать, если у вас есть еще вопросы.

...