Должны ли зависимости между диаграммами Хелма отражать зависимости между микросервисами? - PullRequest
Новая
       21

Должны ли зависимости между диаграммами Хелма отражать зависимости между микросервисами?

2 голосов
/ 09 марта 2019

Учитывая следующую схему служб и их зависимостей, я хотел бы разработать набор диаграмм Хелма.

  • API Gateway, звонки Service A и Service C
  • Service A звонки Service B
  • Service B звонки Database
  • Service C звонки Service B и Service D

На данный момент вижудве альтернативы:

  1. Каждый из 6 компонентов на диаграмме ниже представляет собой одну диаграмму, а каждая стрелка на диаграмме представляет собой одну зависимость.image

  2. There's an Umbrella chart that has a dependency on all other charts. The Database chart is a dependency of Service B chart.
    image

Документация Helm предлагает перейти к варианту 2. Однако я более заинтересован в варианте 1 из-за простоты локальной разработки и конвейера CI / CD.

Пример сценария: разработчик рефакторинг Service Cи он хочет запустить код, который он изменил, и протестировать его.

  • Вариант 1. Разработчик устанавливает только диаграмму Service C.
  • Вариант 2: Разработчик должен либо:
    • установка диаграммы Umbrella, которая приводит к потере ресурсов ЦП и памяти из-за запуска ненужных сервисов, таких как Service A или API Gateway, что плохо масштабируется со сложностью системы;
    • установить Service C, затем Service B, а затем Service D, что также плохо масштабируется со сложностью системы, поскольку требует выполнения множества ручных действий, а также требует от разработчика быть знакомым сархитектура системы, чтобы знать, какие диаграммы необходимо установить.

Я хотел бы принять обоснованное решение о том, какие альтернативывзять.Я более заинтересован в варианте 1, но документы Helm, а также несколько примеров, которые мне удалось найти в Интернете ( link ), также идут с вариантом 2, поэтому я думаю, что я что-то упустил.

1 Ответ

2 голосов
/ 10 марта 2019

Я бы порекомендовал одну диаграмму для каждой услуги, с дополнительным упрощением, чтобы диаграмма "служба B" зависела от ее базы данных. Я хотел бы сделать эти графики независимыми: ни одна из служб не зависит от других.

Место, где хорошо работают зависимости Helm, - это служба, которая встраивает / скрывает отдельные отдельные части. Например, база данных, лежащая в основе B, является деталью реализации, и ничего вне B не нужно знать об этом. Таким образом, B может зависеть от stable/postgres или чего-то подобного, и это хорошо работает в Helm.

Есть одна специфическая механическая проблема, которая вызывает проблемы для подхода зонтичной диаграммы. Скажем, служба D также зависела от базы данных, и это была та же самая «разновидность» базы данных (скажем, обе используют PostgreSQL). Оперативно вы хотите, чтобы эти две базы данных были отдельными. Хелм увидит два пути umbrella > B > database и umbrella > D > database и установит только одну копию диаграммы базы данных, так что вы получите две службы, совместно использующие базу данных. Вы, вероятно, не хотите этого.

Другая механическая проблема, с которой вы столкнетесь при использовании зависимостей Helm, заключается в том, что большинству ресурсов присваивается какой-либо вариант {{ .Release.Name }}-{{ .Chart.Name }}. В вашем варианте 1, скажем, вы просто устанавливаете сервис C; вы бы в конечном итоге с развертываниями, как service-C-C, service-C-B, service-C-database. Если вы затем захотите развернуть службу А рядом с ней, это приведет к появлению собственных service-A-B и service-A-database, что опять-таки не то, что вам нужно.

Мне не известно о великолепном решении этой проблемы с открытым исходным кодом. Решение на основе Make-кода является хакерским, но может работать: 

# -*- gnu-make -*-
all: api-proxy.deployed

%.deployed:
        helm upgrade --install --name $* -f values.yaml ./charts/$*
        touch $@

api-proxy.deployed: a.deployed c.deployed
a.deployed: b.deployed
c.deployed: b.deployed d.deployed
...