Использование зонтичной диаграммы в конвейере CI/CD с несколькими подрядчиками

Я новичок в этой группе. Рад, что связался.
Мне интересно, есть ли у кого-нибудь опыт использования зонтичной диаграммы управления в процессе CI/CD?

В нашем проекте у нас есть 2 отдельных подрядчика-разработчика. Каждый подрядчик отвечает за определенные микросервисы.

Мы используем Harbour в качестве репозитория для диаграмм и сопутствующих изображений контейнеров, а также GitLab для нашего репозитория кода и оркестратора CI/CD... через GitLab runners.

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

Мне интересно услышать от любых групп, которые использовали аналогичный подход, и как они обрабатывали / обрабатывали зонтичную диаграмму в своем процессе CI / CD.

Спасибо за любой вклад / руководство.

VR,


continuous-integration kubernetes-helm charts cd umbrella
person David S    schedule 10.07.2020    source источник
comment
пожалуйста, проверьте мой ответ. Надеюсь, это поможет вам.   -  person Abhinaba Chakraborty    schedule 11.07.2020

Ответы (1)


arrow_upward
1
arrow_downward

Мы используем аналогичный шаблон, где у нас более 30 микросервисов.

У нас есть репозиторий Github для базовых диаграмм.

На диаграмме базовых микросервисов есть всевозможные шаблоны kubernetes (например, HPA, ConfigMap, Secrets, Deployment, Service, Ingress и т. д.), каждый из которых можно включить или отключить.

Примечание. Базовая диаграмма может содержать и другие диаграммы.

например. Эта базовая диаграмма зависит от диаграммы nginx-ingress:

apiVersion: v2
name: base-microservice
description: A base helm chart for deploying a microservice in Kubernetes
type: application
version: 0.1.6
appVersion: 1
dependencies:
- name: nginx-ingress
  version: "~1.39.1"
  repository: "alias:stable"
  condition: nginx-ingress.enabled

Ниже приведен пример шаблона для шаблона secrets.yaml:

{{- if .Values.secrets.enabled -}}
apiVersion: v1
kind: Secret
metadata:
  name: {{ include "base-microservice.fullname" . }}
type: Opaque
data:
  {{- toYaml .Values.secrets.data | nindent 2}}
{{- end}}

Теперь, когда происходит фиксация в этом репозитории базовых диаграмм, как часть процесса CI (наряду с другими вещами) мы делаем

  1. Проверьте, существует ли индекс Helm в репозитории диаграмм.
  2. Если он существует, загрузите существующий индекс и объедините текущий сгенерированный индекс с существующим -› helm repo index --merge oldindex/index.yaml .
  3. Если он не существует, то мы создаем новый индекс Helm -›( индекс репозитория helm . ). Затем загружаем архивные диаграммы и индекс yaml в наш репозиторий диаграмм.

Теперь в каждом нашем микросервисе у нас есть каталог диаграмм , внутри которого у нас всего 2 файла:

  1. Диаграмма.yaml
  2. значения.yaml

Структура каталогов примера микросервиса:

структура каталогов

Chart.yaml для этого микросервиса A выглядит так:

apiVersion: v2
name: my-service-A
description: A Helm chart for Kubernetes
type: application
version: 0.1.0
appVersion: 1

dependencies:
- name: base-microservice
  version: "0.1.6"
  repository: "alias:azure"

И файл values.yaml для этого микросервиса A содержит те значения, которые необходимо переопределить для значений базового микросервиса.

eg.

base-microservice:
  nameOverride: my-service-A
  image:
    repository: myDockerRepo/my-service-A
  resources:
    limits:
      cpu: 1000m
      memory: 1024Mi
    requests:
      cpu: 300m
      memory: 500Mi
  probe:
    initialDelaySeconds: 120
  nginx-ingress:
    enabled: true
  ingress:
    enabled: true

Теперь, выполняя непрерывное развертывание этого микросервиса, у нас есть следующие шаги (среди прочего):

  1. Получение зависимостей helm (обновление зависимостей helm ./charts/my-service-A)
  2. Разверните мою версию в kubernetes (helm upgrade --install my-service-a ./charts/my-service-A)
person Abhinaba Chakraborty    schedule 11.07.2020