Использование Umbrella Chart в трубопроводе CI / CD с несколькими подрядчиками - PullRequest
Новая
       63

Использование Umbrella Chart в трубопроводе CI / CD с несколькими подрядчиками

1 голос
/ 11 июля 2020

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

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

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

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

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

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

VR,

1 Ответ

0 голосов
/ 11 июля 2020

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

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

Базовый -microservice chart содержит всевозможные шаблоны кубернетов (например, HPA, ConfigMap, Secrets, Deployment, Service, Ingress и т. д. c), каждый из которых может быть включен или отключен.

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

например. Эта базовая диаграмма зависит от 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. Если существует, загрузите существующий index и объединить текущий сгенерированный индекс с существующим -> helm repo index --merge oldindex / index.yaml.
  3. Если он не существует, мы создаем новый индекс Helm -> ( helm repo index. ) Затем загрузите заархивированные диаграммы и индексируйте yaml в наш репозиторий диаграмм.

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

  1. Chart.yaml
  2. values.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 имеет те значения, которые необходимо переопределить для значения base-microservice .

, например, 

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. Получить зависимости от руля ( обновление зависимости от руля ./charts/my-service-A)
  2. Развернуть мой выпуск в kubernetes ( обновление руля --install my-service- a ./charts/my-service-A)
...