З часом, коли проект росте, то рано чи пізно постане питання про апгрейд версій пакетів, модулів, чартів.

Робити це вручну, звісно, можна – але тільки до якоїсь межі, бо врешті-решт ви просто фізично не зможете моніторити та оновлювати все.

Для автоматизації таких процесів існує багато рішень, але найчастіше зустрічаються два – Renovate та Dependabot.

За результатами опитування в UkrOps Slack, Renovate набрав набагато більше голосів, і в принципі він вміє більше, ніж Dependabot.

З іншої сторони – Dependabot вже є в GitHub репозиторіях, доступний у всіх тарифних планах, тож якщо ви використовуєте GitHub – то для налаштування Dependabot вам просто потрібно ~~додати води~~ додати файл конфігурації. Хоча, трохи забігаючи наперед – Renovate налаштовується ще простіше, але про це в наступному пості – Renovate: GitHub та Helm Charts versions management.

Взагалі, Dependabot можна мати майже на всіх платформах – GitHub, Github Enterprise, Azure DevOps, GitLab, BitBucket та AWS CodeCommit, див. How to run Dependabot.

Але – це для мене був прям surprize-surprize – Dependabot не вміє в Helm-чарти. Хоча з Terraform працює, і вже є в деяких наших репозиторіях з Python-кодом, тож для початку давайте глянемо на нього.

Знов-таки, забігаючи наперед – Renovate мені зайшов набагато більше, і ми будемо використовувати його.

Зміст

Налаштування Dependabot

Отже, як це працює:

в репозиторії створюється файл конфігурації Dependabot
в ньому описується що саме він має перевіряти – бібліотеки pip, модулі Terraform тощо
описується що саме цікавить – secrity updates, або versions updates
при знаходженні апдейтів – Dependabot створює Pull Request, в якому додає деталі по апдейту
…
Profit!

Тож що будемо робити:

маємо GitHub репозиторій для моніторингу
в ньому маємо Terraform
налаштуємо перевірку і створення PR

Документація – Dependabot quickstart guide, Configuration options for the dependabot.yml file.

Див. також Supported repositories and ecosystems – які саме системи підтримує Dependabot.

Dependabot та Terraform

Що можемо моніторити з Dependabot в контексті Terraform – це версії провайдерів та модулів.

Наприклад, маємо два файли – versions.tf, де задаються версії провайдерів, і файл lambda.tf, де використовуємо кілька модулів – terraform-aws-modules/security-group/aws, terraform-aws-modules/lambda/aws і інші:

Тепер, щоб Dependabot почав моніторити версії в них – створюємо каталог .github, і в ньому файл dependabot.yml:

У файлі задаємо параметри:

version: 2
updates:
  - package-ecosystem: "terraform"
    directory: "/terraform"
    schedule:
      interval: "daily"
      time: "09:00"
      timezone: "Europe/Kyiv"
    assignees:
    - arseny-zinchenko
    reviewers:
    - arseny-zinchenko
    open-pull-requests-limit: 10

В принципі, тут все зрозуміло з назв параметрів:

package-ecosystem: так як цей конфіг для Terraform, то вказуємо його
directory: файли Terraform у директорії terraform в корні репозиторію
schedule: розклад перевірок – при цьому при першому додаванні файлу dependabot.yml він запустить перевірку відразу, і є можливість запускати вручну
assignees та reviewers: відразу створюємо PR на мене
open-pull-requests-limit: по дефолту Dependabot відкриває максимум 5 PR, можна збільшити за допомогою цього параметру

Пушимо в репозиторій, і перевіряємо статус:

В репозиторії переходимо в Insights > Dependency graph > Dependabot, і бачимо, що перевірка запустилась:

За хвилину маємо відкриті пул-реквести:

При цьому, в коментах він додає трохи деталей по апдейту – Release notes, Changelog, etc:

Правда, чомусь не всюди.

Наприклад, апдейт для модулю Lambda створився без деталей:

А от Renovate робить це набагато краще.

Dependabot та GitHub Secrets

Ще один нюанс – це сікрети, які доступні Dependabot.

У нас при PR зі змінами в директорії terraform запускається GitHub Actions Workflow, який виконує перевірки з Terraform (див. GitHub Actions: деплой Terraform з review запланованих змін).

Цей workflow знаходиться в окремому репозиторії, і для доступу до нього у викликаючий worfklow передається GitHub Deploy Key через GitHub Actions Secrets.

В GitHub Actions джобі, яка запустилась від Dependabot, цей степ сфейлився:

Хоча сам workflow передає всі сікрети через secrets: inherit:

...
jobs:

  terraform-test:
    # call the Reusable Workflow file
    uses: ORG_NAME/atlas-github-actions/.github/workflows/call-terraform-check-and-plan.yml@master
    with:
      aws-iam-role: ${{ vars.AWS_IAM_ROLE }}
      aws-env: ${{ vars.AWS_ENV }}
      pr-num: ${{ github.event.pull_request.number }}
      environment: ops
      slack-channel: '#cicd-devops'      
    secrets:
      inherit

Але для Dependabot ці сікрети необхідно задавати окремо – не в Actions secrets and variables > Actions, а в Actions secrets and variables > Dependabot:

Додаємо йому новий сікрет – і тепер перевірка працює:

Dependabot та приватні registries/repositories

Серед іншого, у нас є власні модулі Terraform, які зберігаються в приватному репозиторії.

При доступі до них – Dependabot сфейлить перевірку з помилкою “Dependabot can’t access ORG_NAME/atlas-tf-modules“:

Варіант перший – додати цей репозиторій або інший registry явно в файлі dependabot.yml – див. Configuring private registries.

Варіант другий – це просто клікнути Grant access, що відкриє доступ до репозиторію для всіх репозиторіїв в організації.

Або зробити вручну – переходимо в Settings організації > Code security > Global settings, і в Grant Dependabot access to private repositories додаємо доступ до потрібного репозиторію: