Стратегии обнаружения версий: различия между версиями

Материал из Документация Ключ-АСТРОМ
 
(не показана 1 промежуточная версия этого же участника)
Строка 1: Строка 1:
Dynatrace использует встроенные стратегии определения версий для поддержки различных технологических стандартов для управления версиями. На последнюю обнаруженную версию могут влиять переменные среды, метки Kubernetes и прием событий.
'''''[[Применение Ключ-АСТРОМ]] / [[Применение Ключ-АСТРОМ#.D0.9E.D0.B1.D0.BB.D0.B0.D1.87.D0.BD.D0.B0.D1.8F%20.D0.B0.D0.B2.D1.82.D0.BE.D0.BC.D0.B0.D1.82.D0.B8.D0.B7.D0.B0.D1.86.D0.B8.D1.8F|Облачная автоматизация]] / Мониторинг релизов / Стратегии обнаружения версий'''''
 
Ключ-АСТРОМ использует встроенные стратегии определения версий для поддержки различных технологических стандартов для управления версиями. На последнюю обнаруженную версию могут влиять переменные среды, метки Kubernetes и прием событий.


== Переменные среды ==
== Переменные среды ==
Строка 20: Строка 22:
<code>export DT_RELEASE_VERSION=0.4.</code>
<code>export DT_RELEASE_VERSION=0.4.</code>


# Запустите процесс.
2. Запустите процесс.


Через несколько секунд версия этого процесса появится в Dynatrace.
Через несколько секунд версия этого процесса появится в Ключ-АСТРОМ.


* В Windows для любого запущенного процесса
* В Windows для любого запущенного процесса
*# Выполните следующие команды, заменив <code><version></code>, <code><build-version></code>, <code><release-product-name></code>и <code><release-stage></code>своими фактическими значениями.
*# Выполните следующие команды, заменив <code><version></code>, <code><build-version></code>, <code><release-product-name></code>и <code><release-stage></code>своими фактическими значениями.
<code>set DT_RELEASE_VERSION=<version></code>
<code>set DT_RELEASE_BUILD_VERSION=<build-version></code>
<code>set DT_RELEASE_PRODUCT=<release-product-name></code>
<code>set DT_RELEASE_STAGE=<release-stage></code>
Пример команды:
<code>set DT_RELEASE_VERSION=0.4.1
set DT_RELEASE_BUILD_VERSION=2021-03-24
set DT_RELEASE_PRODUCT=WoGo Main
set DT_RELEASE_STAGE=production</code>
2. Запустите процесс.
Через несколько секунд версия этого процесса появится в Ключ-АСТРОМ.
== Ярлыки Kubernetes ==
Лучшая практика
Мы рекомендуем распространить метки Kubernetes на переменные среды в конфигурации развертывания.
Пример:
Вы можете использовать
* Метки модулей Kubernetes для предоставления метаданных для:
** Стадия релиза (метка: <code>Ключ-АСТРОМ-release-stage</code>)
* Рекомендуемые Kubernetes метки для развернутых модулей для предоставления метаданных для:
** Связанные версии (метка: <code>app.kubernetes.io/version</code>)
** Сопутствующий товар (ярлык: <code>app.kubernetes.io/part-of</code>)по желанию
Примечание. Обязательно используйте только метки pod, а не метки рабочей нагрузки Kubernetes.
Рекомендуемые Kubernetes метки, сопоставленные с метаданными выпуска:
Ключ-АСТРОМ ЕдиныйАгент с правами просмотра пространства имен может автоматически обнаруживать метки, прикрепленные к модулям Kubernetes.
* Версия и продукт отображаются в инвентаре выпуска.
* Пространства имен Kubernetes или настроенные имена групп хостов Ключ-АСТРОМ отображаются как этапы в инвентаре выпуска.
Если вы не хотите менять конфигурацию развертывания, вы можете обновить метки Kubernetes. Ключ-АСТРОМ обновит захваченные версии через несколько секунд.
<code>kubectl label --overwrite pod yourPodId -n yourNamespace app.kubernetes.io/version=42</code>
== Прием событий ==
Если неудобно добавлять переменные среды для процессов в вашей среде или если вы хотите обновить информацию о версии без изменения переменных среды для вашего развернутого программного обеспечения, вы можете отправлять настраиваемые события развертывания в API-интерфейсы Ключ-АСТРОМ, которые явно предоставляют информацию о версии.
Пример JSON ниже показывает, как отправлять настраиваемые события развертывания в API. Для приема событий используйте Events API v2 . Обратите внимание, что процессы сопоставляются через теги.
Чтобы релиз был обнаружен, должны быть выполнены следующие требования:
* <code>eventType</code>установлен на<code>CUSTOM_DEPLOYMENT</code>
* <code>entitySelector</code>является обязательным и должен указывать на экземпляр группы процессов или список экземпляров группы процессов.
* <code>dt.event.deployment.version</code>является обязательным
Пример:
<code>{
  "eventType": "CUSTOM_DEPLOYMENT",
  "title": "Easytravel 1.1",
  "entitySelector": "type(PROCESS_GROUP_INSTANCE),tag(easytravel)",
  "properties": {
    "dt.event.deployment.name":"Easytravel 1.1",
    "dt.event.deployment.version": "1.1",
    "dt.event.deployment.release_stage": "production" ,
    "dt.event.deployment.release_product": "frontend",
    "dt.event.deployment.release_build_version": "123",
    "approver": "Jason Miller",
    "dt.event.deployment.ci_back_link": "<nowiki>https://pipelines/easytravel/123</nowiki>",
    "gitcommit": "e5a6baac7eb",
    "change-request": "CR-42",
    "dt.event.deployment.remediation_action_link": "<nowiki>https://url.com</nowiki>",
    "dt.event.is_rootcause_relevant": true
  }
}</code>

Текущая версия на 12:43, 12 сентября 2024

Применение Ключ-АСТРОМ / Облачная автоматизация / Мониторинг релизов / Стратегии обнаружения версий

Ключ-АСТРОМ использует встроенные стратегии определения версий для поддержки различных технологических стандартов для управления версиями. На последнюю обнаруженную версию могут влиять переменные среды, метки Kubernetes и прием событий.

Переменные среды

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

  • DT_RELEASE_VERSIONдля версии
  • DT_RELEASE_STAGEдля сцены
  • DT_RELEASE_PRODUCTдля продукта
  • DT_RELEASE_BUILD_VERSIONдля версии сборки

Примеры

  • В Linux для любого запущенного процесса
    1. Выполните следующую команду, заменив ее <version>фактическим значением выпуска.

export DT_RELEASE_VERSION=<version>

Пример команды:

export DT_RELEASE_VERSION=0.4.

2. Запустите процесс.

Через несколько секунд версия этого процесса появится в Ключ-АСТРОМ.

  • В Windows для любого запущенного процесса
    1. Выполните следующие команды, заменив <version>, <build-version>, <release-product-name>и <release-stage>своими фактическими значениями.

set DT_RELEASE_VERSION=<version>

set DT_RELEASE_BUILD_VERSION=<build-version>

set DT_RELEASE_PRODUCT=<release-product-name>

set DT_RELEASE_STAGE=<release-stage>

Пример команды:

set DT_RELEASE_VERSION=0.4.1
set DT_RELEASE_BUILD_VERSION=2021-03-24
set DT_RELEASE_PRODUCT=WoGo Main
set DT_RELEASE_STAGE=production


2. Запустите процесс.

Через несколько секунд версия этого процесса появится в Ключ-АСТРОМ.

Ярлыки Kubernetes

Лучшая практика

Мы рекомендуем распространить метки Kubernetes на переменные среды в конфигурации развертывания.

Пример:

Вы можете использовать

  • Метки модулей Kubernetes для предоставления метаданных для:
    • Стадия релиза (метка: Ключ-АСТРОМ-release-stage)
  • Рекомендуемые Kubernetes метки для развернутых модулей для предоставления метаданных для:
    • Связанные версии (метка: app.kubernetes.io/version)
    • Сопутствующий товар (ярлык: app.kubernetes.io/part-of)по желанию

Примечание. Обязательно используйте только метки pod, а не метки рабочей нагрузки Kubernetes.

Рекомендуемые Kubernetes метки, сопоставленные с метаданными выпуска:

Ключ-АСТРОМ ЕдиныйАгент с правами просмотра пространства имен может автоматически обнаруживать метки, прикрепленные к модулям Kubernetes.

  • Версия и продукт отображаются в инвентаре выпуска.
  • Пространства имен Kubernetes или настроенные имена групп хостов Ключ-АСТРОМ отображаются как этапы в инвентаре выпуска.

Если вы не хотите менять конфигурацию развертывания, вы можете обновить метки Kubernetes. Ключ-АСТРОМ обновит захваченные версии через несколько секунд.

kubectl label --overwrite pod yourPodId -n yourNamespace app.kubernetes.io/version=42

Прием событий

Если неудобно добавлять переменные среды для процессов в вашей среде или если вы хотите обновить информацию о версии без изменения переменных среды для вашего развернутого программного обеспечения, вы можете отправлять настраиваемые события развертывания в API-интерфейсы Ключ-АСТРОМ, которые явно предоставляют информацию о версии.

Пример JSON ниже показывает, как отправлять настраиваемые события развертывания в API. Для приема событий используйте Events API v2 . Обратите внимание, что процессы сопоставляются через теги.

Чтобы релиз был обнаружен, должны быть выполнены следующие требования:

  • eventTypeустановлен наCUSTOM_DEPLOYMENT
  • entitySelectorявляется обязательным и должен указывать на экземпляр группы процессов или список экземпляров группы процессов.
  • dt.event.deployment.versionявляется обязательным

Пример:

{
  "eventType": "CUSTOM_DEPLOYMENT",
  "title": "Easytravel 1.1",
  "entitySelector": "type(PROCESS_GROUP_INSTANCE),tag(easytravel)",
  "properties": {
    "dt.event.deployment.name":"Easytravel 1.1",
    "dt.event.deployment.version": "1.1",
    "dt.event.deployment.release_stage": "production" ,
    "dt.event.deployment.release_product": "frontend",
    "dt.event.deployment.release_build_version": "123",
    "approver": "Jason Miller",
    "dt.event.deployment.ci_back_link": "https://pipelines/easytravel/123",
    "gitcommit": "e5a6baac7eb",
    "change-request": "CR-42",
    "dt.event.deployment.remediation_action_link": "https://url.com",
    "dt.event.is_rootcause_relevant": true
  }
}