Дженкинс: Управление несколькими конфигурациями среды и развертывания - PullRequest
1 голос
/ 27 июня 2019

Я работаю над продуктом, в котором у нас есть 3 команды разработчиков.
1 для пользовательского интерфейса и
2 для бэкэнда.

Каждая команда требует полного env для своего собственного тестирования. Там более 10 бэкэнд-сервисов и еще много других компонентов и 4 компонента пользовательского интерфейса. У нас есть следующие env:
3 dev env по одному для каждой команды
1 Dev Integration
2 для QA (автоматизация и ручное тестирование)

Все env используют Kubernetes, все службы развернуты как контейнеры. Каждый env имеет свой собственный сервер БД. Среда
3 dev env и 1 dev int развернута в одном кластере K8s, а
2 Env QA развернута в другом кластере.

У каждого env есть свой набор заданий jenkins для всех модулей (CI и CD). Таким образом, у нас есть 6 копий всех заданий в разных папках jenkins (по 1 на каждую среду). Все они используют общие файлы svc и dpl (хранятся в качестве шаблона) из нашего репозитория devops для развертывания сервисов в соответствующих окружениях kubernetes. и CD Jobs имеют все необходимые переменные и значения, используемые с файлами шаблонов для соответствующего env).

Теперь, когда у любого модуля есть изменения, связанные с развертыванием, мы должны внести общие изменения в файлы dpl и svc, но любые новые переменные конфигурации или изменения в существующих параметрах конфигурации должны быть сделаны в каждом задании env. Благодаря поддержке нескольких версий продукта, я предусматриваю поддержку большего количества копий полного набора заданий jenkins для каждой версии.

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

Спасибо! Ratish

1 Ответ

0 голосов
/ 27 июня 2019

Это слишком долго.TL; DR: используйте руль и флюс .

Длинная версия:

Я думаю, что это приводит к тому, что слишком много вашего конвейера CI / CD попадает в Jenkins.Это может нормально работать, но намного чище, когда вы назначаете ответственность за CI Jenkins и используете выделенный сервис CD.Я рекомендую использовать Helm для развертываний и использовать Weave Flux для управления ими.

Helm - менеджер пакетов для Kuberentes.По сути, это просто способ параметризации ваших шаблонов Kubernetes и установки их с некоторыми значениями по умолчанию и некоторыми переопределениями.Использование одного руля, вероятно, вам очень поможет.

Flux - это способ развертывания ваших диаграмм руля и изображений докера.По сути это CD в CI / CD.На этой диаграмме с веб-сайта Flux показано, как Flux отслеживает ваше хранилище изображений для новых артефактов, созданных Jenkins, и конфигурационное хранилище (диаграммы вашего руля) для обновленной конфигурации развертывания.

CI/CD Pipeline

Итак, теперь у вас есть Jenkins, создающий ваше приложение, Helm может развернуть вашу конфигурацию Kubernetes и Flux может отслеживать изменения, как вы работаете в нескольких средах с некоторыми общими и некоторыми пользовательскими значениями конфигурации?Вы можете поместить значения в 3 (или более мест).1) Ваш values.yaml, который определяет все значения, которые использует ваша диаграмма Хелма, 2) env-shared-values.yaml, это будет иметь значения, общие для нескольких сред, 3) service-env-values.yaml, который является конкретными значениями, необходимыми дляэкземпляр службы.

Структура папок может выглядеть следующим образом

  • HelmChartRepo
    • Диаграмма
      • values.yaml
      • templates
        • все ваши шаблоны k8s здесь
    • EnvValues ​​
      • dev-values.yaml
      • qa-values.yaml
    • Выпуски
      • dev1-svc1.yaml
      • dev1.svc2.yaml
      • dev2-svc1.yaml
      • dev2-svc2.yaml
      • qa1-svc1.yaml
      • и т. д.

Клей находится в папке Release там.Каждый файл является HelmRelease, который используется Flux для управления выпуском.Вот пример, который я использовал.Обратите внимание на несколько вещей.1) Он смотрит на репозиторий github для изменений графика.2) Он просматривает репозиторий Docker для изображений с тегом, содержащим определенный префикс.Вот как вы можете управлять различными средами.Просто попросите Дженкинса пометить сборку соответствующим образом, и Flux развернет новую версию.

---
apiVersion: flux.weave.works/v1beta1
kind: HelmRelease
metadata:
  name: dev1-svc1
  namespace: dev1
  annotations:
    flux.weave.works/automated: "true"
    flux.weave.works/tag.chart-image: glob:dev1-*
spec:
  releaseName: dev1-svc1
  chart:
    git: git@github.com:[your-user]/[your-chart-repo]
    path: [path in git to your chart]
    ref: master
  values: (release specific values here)

    image:
      repository: [mydockerhubrepo/myimagename]
      tag: dev1-versiontags
  valuesFrom:
  - chartFileRef:
      path: EnvValues/dev-values.yaml
      optional: false
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...