Стратегии обнаружения версий: различия между версиями
ENetrebin (обсуждение | вклад) |
ENetrebin (обсуждение | вклад) |
||
(не показана 1 промежуточная версия этого же участника) | |||
Строка 20: | Строка 20: | ||
<code>export DT_RELEASE_VERSION=0.4.</code> | <code>export DT_RELEASE_VERSION=0.4.</code> | ||
2. Запустите процесс. | |||
Через несколько секунд версия этого процесса появится в Dynatrace. | Через несколько секунд версия этого процесса появится в Dynatrace. | ||
Строка 26: | Строка 26: | ||
* В 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. Запустите процесс. | |||
Через несколько секунд версия этого процесса появится в Dynatrace. | |||
== Ярлыки Kubernetes == | |||
Лучшая практика | |||
Мы рекомендуем распространить метки Kubernetes на переменные среды в конфигурации развертывания. | |||
Пример: | |||
Вы можете использовать | |||
* Метки модулей Kubernetes для предоставления метаданных для: | |||
** Стадия релиза (метка: <code>Dynatrace-release-stage</code>) | |||
* Рекомендуемые Kubernetes метки для развернутых модулей для предоставления метаданных для: | |||
** Связанные версии (метка: <code>app.kubernetes.io/version</code>) | |||
** Сопутствующий товар (ярлык: <code>app.kubernetes.io/part-of</code>)по желанию | |||
Примечание. Обязательно используйте только метки pod, а не метки рабочей нагрузки Kubernetes. | |||
Рекомендуемые Kubernetes метки, сопоставленные с метаданными выпуска: | |||
Dynatrace ЕдиныйАгент с правами просмотра пространства имен может автоматически обнаруживать метки, прикрепленные к модулям Kubernetes. | |||
* Версия и продукт отображаются в инвентаре выпуска. | |||
* Пространства имен Kubernetes или настроенные имена групп хостов Dynatrace отображаются как этапы в инвентаре выпуска. | |||
Если вы не хотите менять конфигурацию развертывания, вы можете обновить метки Kubernetes. Dynatrace обновит захваченные версии через несколько секунд. | |||
<code>kubectl label --overwrite pod yourPodId -n yourNamespace app.kubernetes.io/version=42</code> | |||
== Прием событий == | |||
Если неудобно добавлять переменные среды для процессов в вашей среде или если вы хотите обновить информацию о версии без изменения переменных среды для вашего развернутого программного обеспечения, вы можете отправлять настраиваемые события развертывания в API-интерфейсы Dynatrace, которые явно предоставляют информацию о версии. | |||
Пример 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> |
Текущая версия на 17:17, 23 января 2023
Dynatrace использует встроенные стратегии определения версий для поддержки различных технологических стандартов для управления версиями. На последнюю обнаруженную версию могут влиять переменные среды, метки Kubernetes и прием событий.
Переменные среды
Лучший и самый простой способ получить информацию о версии, доступную для каждой распределенной трассировки, — предоставить метаданные через переменные среды.
DT_RELEASE_VERSION
для версииDT_RELEASE_STAGE
для сценыDT_RELEASE_PRODUCT
для продуктаDT_RELEASE_BUILD_VERSION
для версии сборки
Примеры
- В Linux для любого запущенного процесса
- Выполните следующую команду, заменив ее
<version>
фактическим значением выпуска.
- Выполните следующую команду, заменив ее
export DT_RELEASE_VERSION=<version>
Пример команды:
export DT_RELEASE_VERSION=0.4.
2. Запустите процесс.
Через несколько секунд версия этого процесса появится в Dynatrace.
- В Windows для любого запущенного процесса
- Выполните следующие команды, заменив
<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. Запустите процесс.
Через несколько секунд версия этого процесса появится в Dynatrace.
Ярлыки Kubernetes
Лучшая практика
Мы рекомендуем распространить метки Kubernetes на переменные среды в конфигурации развертывания.
Пример:
Вы можете использовать
- Метки модулей Kubernetes для предоставления метаданных для:
- Стадия релиза (метка:
Dynatrace-release-stage
)
- Стадия релиза (метка:
- Рекомендуемые Kubernetes метки для развернутых модулей для предоставления метаданных для:
- Связанные версии (метка:
app.kubernetes.io/version
) - Сопутствующий товар (ярлык:
app.kubernetes.io/part-of
)по желанию
- Связанные версии (метка:
Примечание. Обязательно используйте только метки pod, а не метки рабочей нагрузки Kubernetes.
Рекомендуемые Kubernetes метки, сопоставленные с метаданными выпуска:
Dynatrace ЕдиныйАгент с правами просмотра пространства имен может автоматически обнаруживать метки, прикрепленные к модулям Kubernetes.
- Версия и продукт отображаются в инвентаре выпуска.
- Пространства имен Kubernetes или настроенные имена групп хостов Dynatrace отображаются как этапы в инвентаре выпуска.
Если вы не хотите менять конфигурацию развертывания, вы можете обновить метки Kubernetes. Dynatrace обновит захваченные версии через несколько секунд.
kubectl label --overwrite pod yourPodId -n yourNamespace app.kubernetes.io/version=42
Прием событий
Если неудобно добавлять переменные среды для процессов в вашей среде или если вы хотите обновить информацию о версии без изменения переменных среды для вашего развернутого программного обеспечения, вы можете отправлять настраиваемые события развертывания в API-интерфейсы Dynatrace, которые явно предоставляют информацию о версии.
Пример 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
}
}