KubernetesManifest@0 - Implementar na tarefa kubernetes v0

Utilize uma tarefa de manifesto do Kubernetes num pipeline de compilação ou versão para criar e implementar manifestos em clusters do Kubernetes com gráficos Helm.

Syntax

# Deploy to Kubernetes v0
# Use Kubernetes manifest files to deploy to clusters or even bake the manifest files to be used for deployments using Helm charts.
- task: KubernetesManifest@0
  inputs:
    #action: 'deploy' # 'bake' | 'createSecret' | 'delete' | 'deploy' | 'patch' | 'promote' | 'scale' | 'reject'. Action. Default: deploy.
    #kubernetesServiceConnection: # string. Required when action != bake. Kubernetes service connection. 
    #namespace: # string. Namespace. 
    #strategy: 'none' # 'canary' | 'none'. Optional. Use when action = deploy || action = promote || action = reject. Strategy. Default: none.
    #trafficSplitMethod: 'pod' # 'pod' | 'smi'. Optional. Use when strategy = canary. Traffic split method. Default: pod.
    #percentage: '0' # string. Required when strategy = Canary && action = deploy. Percentage. Default: 0.
    #baselineAndCanaryReplicas: '1' # string. Required when strategy = Canary && action = deploy && trafficSplitMethod = SMI. Baseline and canary replicas. Default: 1.
    #manifests: # string. Required when action = deploy || action = promote || action = reject. Manifests. 
    #containers: # string. Optional. Use when action = deploy || action = promote || action = bake. Containers. 
    #imagePullSecrets: # string. Optional. Use when action = deploy || action = promote. ImagePullSecrets. 
    #renderType: 'helm' # 'helm' | 'kompose' | 'kustomize'. Optional. Use when action = bake. Render Engine. Default: helm.
    #dockerComposeFile: # string. Required when action = bake && renderType = kompose. Path to docker compose file. 
    #helmChart: # string. Required when action = bake && renderType = helm. Helm Chart. 
    #releaseName: # string. Optional. Use when action = bake && renderType = helm. Helm Release Name. 
    #overrideFiles: # string. Optional. Use when action = bake && renderType = helm. Override Files. 
    #overrides: # string. Optional. Use when action = bake && renderType = helm. Overrides. 
    #kustomizationPath: # string. Optional. Use when action = bake && renderType = kustomize. Kustomization Path. 
    #resourceToPatch: 'file' # 'file' | 'name'. Required when action = patch. Resource to patch. Default: file.
    #resourceFileToPatch: # string. Required when action = patch && resourceToPatch = file. File path. 
    #kind: # 'deployment' | 'replicaset' | 'statefulset'. Required when action = scale || resourceToPatch = name. Kind. 
    #name: # string. Required when action = scale || resourceToPatch = name. Name. 
    #replicas: # string. Required when action = scale. Replica count. 
    #mergeStrategy: 'strategic' # 'json' | 'merge' | 'strategic'. Required when action = patch. Merge Strategy. Default: strategic.
    #arguments: # string. Optional. Use when action = delete. Arguments. 
    #patch: # string. Required when action = patch. Patch. 
    #secretType: 'dockerRegistry' # 'dockerRegistry' | 'generic'. Required when action = createSecret. Type of secret. Default: dockerRegistry.
    #secretName: # string. Optional. Use when action = createSecret. Secret name. 
    #secretArguments: # string. Optional. Use when action = createSecret && secretType = generic. Arguments. 
    #dockerRegistryEndpoint: # string. Optional. Use when action = createSecret && secretType = dockerRegistry. Docker registry service connection. 
    #rolloutStatusTimeout: '0' # string. Optional. Use when action = deploy || action = patch || action = scale || action = promote. Timeout for rollout status. Default: 0.

Entradas

action - Ação
string. Valores permitidos: bake, (criar segredo), delete, , deploy, patchpromote, , . rejectscalecreateSecret Valor predefinido: deploy.

Especifica a ação a ser executada.

kubernetesServiceConnection - Ligação do serviço Kubernetes
string. Necessário quando action != bake.

Especifica uma ligação de serviço do Kubernetes.

namespace - Espaço de nomes
string.

Especifica o espaço de nomes dos comandos com o –namespace sinalizador. Se o espaço de nomes não for fornecido, os comandos serão executados no espaço de nomes predefinido.

strategy - Estratégia
string. Opcional. Utilize quando action = deploy || action = promote || action = reject. Valores permitidos: canary, none. Valor predefinido: none.

Especifica a estratégia de implementação utilizada na ação deploy antes de uma promote ação ou reject ação. Atualmente, canary é a única estratégia de implementação aceitável.

trafficSplitMethod - Método de divisão de tráfego
string. Opcional. Utilize quando strategy = canary. Valores permitidos: pod, smi. Valor predefinido: pod.

Para o valor smi, a percentagem de divisão de tráfego é efetuada ao nível do pedido através de uma malha de serviço. Uma malha de serviço tem de ser configurada por um administrador de cluster. Esta tarefa processa a orquestração de objetos SMI TrafficSplit .

Para o valor pod, a divisão percentual não é possível ao nível do pedido na ausência de uma malha de serviço. Em vez disso, a percentagem de entrada é utilizada para calcular as réplicas da linha de base e do canário. O cálculo é uma percentagem de réplicas especificadas nos manifestos de entrada para a variante estável.

percentage - Percentagem
string. Necessário quando strategy = Canary && action = deploy. Valor predefinido: 0.

A percentagem utilizada para calcular o número de réplicas de variantes de linha de base e de variantes canárias das cargas de trabalho contidas em ficheiros de manifesto.

Para a percentagem de entrada especificada, calcule:

(percentagem × número de réplicas) / 100

Se o resultado não for um número inteiro, o piso matemático do resultado é utilizado quando são criadas variantes de linha de base e canários.

Por exemplo, suponha que a implementação hello-world está no ficheiro de manifesto de entrada e que as seguintes linhas estão na entrada da tarefa:

replicas: 4
strategy: canary
percentage: 25

Neste caso, as implementações e hello-world-canary são criadas hello-world-baseline com uma réplica cada. A variante de linha de base é criada com a mesma imagem e etiqueta que a versão estável, que é a variante de quatro réplicas antes da implementação. A variante canary é criada com a imagem e a etiqueta correspondentes às alterações recentemente implementadas.

baselineAndCanaryReplicas - Réplicas de linha de base e canários
string. Necessário quando strategy = Canary && action = deploy && trafficSplitMethod = SMI. Valor predefinido: 1.

Quando definir trafficSplitMethod como smi, a divisão de tráfego de percentagem é controlada no plano de malha de serviço. Pode controlar o número real de réplicas para variantes canárias e de linha de base independentemente da divisão de tráfego.

Por exemplo, suponha que o manifesto de implementação de entrada especifica 30 réplicas para a variante estável. Assuma também que especifica a seguinte entrada para a tarefa:

strategy: canary
trafficSplitMethod: smi
percentage: 20
baselineAndCanaryReplicas: 1

Neste caso, a variante estável recebe 80% do tráfego, enquanto as variantes de linha de base e canário recebem metade dos 20% especificados. As variantes de linha de base e canários não recebem três réplicas cada. Em vez disso, recebem o número especificado de réplicas, o que significa que cada uma recebe uma réplica.

manifests - Manifestos
string. Necessário quando action = deploy || action = promote || action = reject.

Especifica o caminho para os ficheiros de manifesto a utilizar para a implementação. Cada linha representa um único caminho. Um padrão de correspondência de ficheiros é um valor aceitável para cada linha.

containers - Contentores
string. Opcional. Utilize quando action = deploy || action = promote || action = bake.

Especifica o URL de recurso completamente qualificado da imagem a utilizar para substituições nos ficheiros de manifesto. O URL contosodemo.azurecr.io/helloworld:test é um exemplo.

imagePullSecrets - ImagePullSecrets
string. Opcional. Utilize quando action = deploy || action = promote.

Especifica uma entrada multiline em que cada linha contém o nome de um segredo do registo do Docker que já foi configurado no cluster. Cada nome de segredo é adicionado imagePullSecrets em para as cargas de trabalho que se encontram nos ficheiros de manifesto de entrada.

renderType - Motor de Composição
string. Opcional. Utilize quando action = bake. Valores permitidos: helm, , komposekustomize. Valor predefinido: helm.

Especifica o tipo de composição utilizado para produzir os ficheiros de manifesto.

dockerComposeFile - Caminho para o ficheiro de composição do Docker
string. Necessário quando action = bake && renderType = kompose.

Especifica um caminho de ficheiro docker-compose.

helmChart - Gráfico Helm
string. Necessário quando action = bake && renderType = helm.

Especifica o caminho do gráfico Helm para cozer.

releaseName - Nome da Versão do Helm
string. Opcional. Utilize quando action = bake && renderType = helm.

Especifica o nome de versão do Helm a utilizar.

overrideFiles - Substituir Ficheiros
string. Opcional. Utilize quando action = bake && renderType = helm.

Especifica uma entrada de várias linhas que aceita o caminho para os ficheiros de substituição. Os ficheiros são utilizados quando os ficheiros de manifesto dos gráficos Helm são cozidos.

overrides - Substituições
string. Opcional. Utilize quando action = bake && renderType = helm.

Especifica os valores de substituição a definir.

kustomizationPath - Caminho de Kustomization
string. Opcional. Utilize quando action = bake && renderType = kustomize.

Especifica o argumento que tem de ser o caminho para o diretório que contém o ficheiro ou um URL do repositório git com um sufixo de caminho que especifica same em relação à raiz do repositório.

resourceToPatch - Recurso a corrigir
string. Necessário quando action = patch. Valores permitidos: file, name. Valor predefinido: file.

Indica um dos seguintes métodos de patch:

• Um ficheiro de manifesto identifica os objetos a serem corrigidos.
• Um objeto individual é identificado por tipo e nome como o destino do patch.

Os valores aceitáveis são ficheiro e nome.

resourceFileToPatch - Caminho do ficheiro
string. Necessário quando action = patch && resourceToPatch = file.

Especifica o caminho para o ficheiro utilizado para um patch.

kind - Tipo
string. Necessário quando action = scale || resourceToPatch = name. Valores permitidos: deployment, , replicasetstatefulset.

Especifica o tipo de objeto K8s, como deployment, replicaSet e muito mais.

name - Nome
string. Necessário quando action = scale || resourceToPatch = name.

Especifica o nome do objeto K8s.

replicas - Contagem de réplicas
string. Necessário quando action = scale.

Especifica o número de réplicas a dimensionar.

mergeStrategy - Estratégia de Intercalação
string. Necessário quando action = patch. Valores permitidos: json, , mergestrategic. Valor predefinido: strategic.

Especifica o tipo de patch que está a ser fornecido.

arguments - Argumentos
string. Opcional. Utilize quando action = delete.

Especifica os argumentos para o kubectl delete comando . Um exemplo é: arguments: deployment hello-world foo-bar

patch - Patch
string. Necessário quando action = patch.

Especifica o conteúdo do patch.

secretType - Tipo de segredo
string. Necessário quando action = createSecret. Valores permitidos: dockerRegistry, generic. Valor predefinido: dockerRegistry.

Cria ou atualiza um genérico ou docker imagepullsecret. Especifique dockerRegistry para criar ou atualizar o imagepullsecret do registo selecionado. Uma imagePullSecret é uma forma de transmitir um segredo que contém uma palavra-passe de registo de contentor para o Kubelet, para que possa extrair uma imagem privada em nome do seu Pod.

secretName - Nome do segredo
string. Opcional. Utilize quando action = createSecret.

Especifica o nome do segredo. Pode utilizar este nome de segredo no ficheiro de configuração YAML do Kubernetes.

secretArguments - Argumentos
string. Opcional. Utilize quando action = createSecret && secretType = generic.

Especifica chaves e valores literais a inserir em segredo. Por exemplo, --from-literal=key1=value1--from-literal=key2="top secret".

dockerRegistryEndpoint - Ligação do serviço de registo do Docker
string. Opcional. Utilize quando action = createSecret && secretType = dockerRegistry.

Especifica as credenciais da ligação de serviço especificada que são utilizadas para criar um segredo do registo do Docker no cluster. Os ficheiros de manifesto no imagePullSecrets campo podem, em seguida, referir-se ao nome deste segredo.

rolloutStatusTimeout - Tempo limite para o estado da implementação
string. Opcional. Utilize quando action = deploy || action = patch || action = scale || action = promote. Valor predefinido: 0.

Especifica o período de tempo (em segundos) a aguardar antes de terminar watch on rollout o estado.

Opções de controlo de tarefas

Todas as tarefas têm opções de controlo para além das respetivas entradas de tarefas. Para obter mais informações, veja Opções de controlo e propriedades de tarefas comuns.

Variáveis de saída

Esta tarefa define as seguintes variáveis de saída, que pode consumir em passos, tarefas e fases a jusante.

manifestsBundle
Especifica a localização dos pacotes de manifesto criados pela ação de cozedura.

Observações

Nota

Existe uma versão mais recente desta tarefa disponível que fornece suporte adicional para direcionar um cluster do Kubernetes de formas diferentes, utilizando a connectionType propriedade . Para obter mais informações, veja KubernetesManifest@1 e KubernetesManifest@1 observações de ligação do serviço

Utilize uma tarefa de manifesto do Kubernetes num pipeline de compilação ou versão para criar e implementar manifestos em clusters do Kubernetes.

Esta tarefa suporta o seguinte:

• Substituição de artefactos: a ação de implementação é tomada como entrada de uma lista de imagens de contentor que pode especificar juntamente com as respetivas etiquetas e resumos. A mesma entrada é substituída nos ficheiros de manifesto não modelados antes da aplicação para o cluster. Esta substituição garante que os nós de cluster solicitam a versão correta da imagem.

• Estabilidade do manifesto: o estado de implementação dos objetos do Kubernetes implementados está verificado. As verificações de estabilidade são incorporadas para determinar se o estado da tarefa é um êxito ou uma falha.

• Anotações de rastreabilidade: as anotações são adicionadas aos objetos do Kubernetes implementados para sobrepor informações de rastreabilidade. São suportadas as seguintes anotações:

  • azure-pipelines/org
  • azure-pipelines/project
  • azure-pipelines/pipeline
  • azure-pipelines/pipelineId
  • azure-pipelines/execução
  • azure-pipelines/executionuri
  • azure-pipelines/jobName

• Processamento de segredos: createSecret a ação permite criar segredos do registo do Docker com ligações do serviço de registo do Docker. Também permite a criação de segredos genéricos com variáveis de texto simples ou variáveis secretas. Antes da implementação no cluster, pode utilizar a secrets entrada juntamente com a ação deploy para aumentar os ficheiros de manifesto de entrada com o valor adequado imagePullSecrets .

• Manifesto do Bake: bake a ação da tarefa permite cozer modelos em ficheiros de manifesto do Kubernetes. A ação utiliza ferramentas como Helm, Compose e Kustomize. Com o baking, estes ficheiros de manifesto do Kubernetes são utilizáveis para implementações no cluster.

• Estratégia de implementação: escolher a canary estratégia com a ação deploy leva à criação de nomes de cargas de trabalho sufixos com -baseline e -canary. A tarefa suporta dois métodos de divisão de tráfego:

  • Interface do Service Mesh: a abstração do Service Mesh Interface (SMI) permite a configuração com fornecedores de malha de serviços como Linkerd e Istio. A tarefa Manifesto do Kubernetes mapeia objetos SMI TrafficSplit para os serviços estáveis, de linha de base e canários durante o ciclo de vida da estratégia de implementação.

    As implementações canary baseadas numa malha de serviço e que utilizam esta tarefa são mais precisas. Esta precisão deve-se à forma como os fornecedores de malha de serviços permitem a divisão granular baseada em percentagem do tráfego. A malha de serviço utiliza o registo de serviços e os contentores de sidecar que são injetados em pods. Esta injeção ocorre juntamente com os contentores de aplicações para obter a divisão de tráfego granular.

  • Kubernetes sem malha de serviço: na ausência de uma malha de serviço, poderá não obter a percentagem exata que pretende ao nível do pedido. No entanto, pode efetuar implementações canárias com variantes de linha de base e canário junto à variante estável.

    O serviço envia pedidos para pods das três variantes de carga de trabalho à medida que as restrições selector-label são cumpridas. O Manifesto do Kubernetes respeita estes pedidos ao criar variantes de linha de base e canários. Este comportamento de encaminhamento obtém o efeito pretendido de encaminhar apenas uma parte do total de pedidos para o canary.

  Compare as cargas de trabalho de linha de base e de canário com uma tarefa de Intervenção Manual em pipelines de versão ou uma tarefa Atraso em pipelines YAML. Faça a comparação antes de utilizar a ação promover ou rejeitar a tarefa.

Implementar ação

O seguinte código YAML é um exemplo de implementação num espaço de nomes do Kubernetes com ficheiros de manifesto:

steps:
- task: KubernetesManifest@0
  displayName: Deploy
  inputs:
    kubernetesServiceConnection: someK8sSC1
    namespace: default
    manifests: |
      manifests/deployment.yml
      manifests/service.yml
    containers: |
      foo/demo:$(tagVariable1)
      bar/demo:$(tagVariable2)
    imagePullSecrets: |
      some-secret
      some-other-secret

No exemplo acima, a tarefa tenta localizar correspondências para as imagens foo/demo e bar/demo nos campos de imagem dos ficheiros de manifesto. Para cada correspondência encontrada, o valor de ou tagVariable1tagVariable2 é acrescentado como uma etiqueta ao nome da imagem. Também pode especificar resumos na entrada de contentores para substituição de artefactos.

Nota

Embora possa criar deploy, promotee reject ações com entrada YAML relacionadas com a estratégia de implementação, o suporte para uma tarefa de Intervenção Manual está atualmente indisponível para pipelines de compilação.

Para pipelines de versão, recomendamos que utilize ações e entradas relacionadas com a estratégia de implementação na seguinte sequência:

1. Uma ação de implementação especificada com strategy: canary e percentage: $(someValue).
2. Uma tarefa de Intervenção Manual para que possa colocar o pipeline em pausa e comparar a variante de linha de base com a variante canary.
3. Uma ação de promoção que é executada se uma tarefa de Intervenção Manual for retomada e uma ação de rejeição que é executada se uma tarefa de Intervenção Manual for rejeitada.

Criar ação secreta

O seguinte código YAML mostra um exemplo de criação de segredos do registo do Docker com a ligação do serviço de Registo do Docker:

steps:
- task: KubernetesManifest@0
  displayName: Create secret
  inputs: 
    action: createSecret
    secretType: dockerRegistry
    secretName: foobar
    dockerRegistryEndpoint: demoACR
    kubernetesServiceConnection: someK8sSC
    namespace: default

Este código YAML mostra um exemplo de criação de segredos genéricos:

steps:
- task: KubernetesManifest@0
  displayName: Create secret
  inputs: 
    action: createSecret
    secretType: generic
    secretName: some-secret
    secretArguments: --from-literal=key1=value1
    kubernetesServiceConnection: someK8sSC
    namespace: default

Ação de cozer

O seguinte código YAML é um exemplo de ficheiros de manifesto de assar a partir de gráficos Helm. Repare na utilização de uma entrada de nome na primeira tarefa. Este nome é posteriormente referenciado a partir do passo de implementação para especificar o caminho para os manifestos que foram produzidos pelo passo de cozedura.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    helmChart: charts/sample
    overrides: 'image.repository:nginx'

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: someK8sSC
    namespace: default
    manifests: $(bake.manifestsBundle)
    containers: |
      nginx: 1.7.9

Nota

Para utilizar o Helm diretamente para gerir lançamentos e reversões, veja a tarefa Compactar e implementar gráficos Helm.

Exemplo do Kustomize

O seguinte código YAML é um exemplo de ficheiros de manifesto gerados com o Kustomize que contêm um kustomization.yaml ficheiro.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from kustomization path
  inputs:
    action: bake
    renderType: kustomize
    kustomizationPath: folderContainingKustomizationFile

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

Exemplo de Kompose

O seguinte código YAML é um exemplo de ficheiros de manifesto gerados com o Kompose, uma ferramenta de conversão para Docker Compose.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Docker Compose
  inputs:
    action: bake
    renderType: kompose
    dockerComposeFile: docker-compose.yaml

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

Ação de dimensionamento

O seguinte código YAML mostra um exemplo de dimensionamento de objetos:

steps:
- task: KubernetesManifest@0
  displayName: Scale
  inputs: 
    action: scale
    kind: deployment
    name: bootcamp-demo
    replicas: 5
    kubernetesServiceConnection: someK8sSC
    namespace: default

Ação de patch

O seguinte código YAML mostra um exemplo de aplicação de patches de objetos:

steps:
- task: KubernetesManifest@0
  displayName: Patch
  inputs: 
    action: patch
    kind: pod
    name: demo-5fbc4d6cd9-pgxn4
    mergeStrategy: strategic
    patch: '{"spec":{"containers":[{"name":"demo","image":"foobar/demo:2239"}]}}'
    kubernetesServiceConnection: someK8sSC
    namespace: default

Eliminar ação

Este código YAML mostra uma eliminação de objeto de exemplo:

steps:
- task: KubernetesManifest@0
  displayName: Delete
  inputs:
    action: delete
    arguments: deployment expressapp
    kubernetesServiceConnection: someK8sSC
    namespace: default

Resolução de problemas

O cluster My Kubernetes está protegido por uma firewall e eu estou a utilizar agentes alojados. Como posso implementar neste cluster?

Pode conceder acesso a agentes alojados através da firewall, ao permitir os endereços IP para os agentes alojados. Para obter mais detalhes, veja Intervalos de IP do agente.

Como é que os pedidos funcionam para rotas de serviço estáveis e de variantes com implementações de proteção?

A relação do seletor de etiquetas entre pods e serviços no Kubernetes permite a configuração de implementações para que um único serviço encaminhe os pedidos para as variantes estáveis e de proteção. A tarefa de manifesto do Kubernetes utiliza-o para implementações de proteção.

Se a tarefa incluir as entradas de action: deploy e strategy: canary, para cada carga de trabalho (Implementação, ReplicaSet, Pod, ...) definidas nos ficheiros de manifesto de entrada, é criada uma -baseline variante e -canary da implementação. Neste exemplo, existe uma implementação sampleapp no ficheiro de manifesto de entrada e que, após a conclusão do número de execução 22 do pipeline, a variante estável desta implementação denominada sampleapp é implementada no cluster. Na execução subsequente (neste caso, execute o número 23), a tarefa de manifesto do Kubernetes com action: deploy e strategy: canary resultaria na criação de implementações sampleapp-baseline e sampleapp-canary cujo número de réplicas é determinado pelo produto da entrada da percentage tarefa com o valor do número pretendido de réplicas para a variante estável final de de acordo com os ficheiros de manifesto de sampleapp entrada.

Excluindo o número de réplicas, a versão de linha de base tem a mesma configuração que a variante estável, enquanto a versão canary tem as novas alterações que estão a ser introduzidas pela execução atual (neste caso, execute o número 23). Se for configurada uma intervenção manual no pipeline após o passo mencionado acima, esta permitirá uma oportunidade de colocar o pipeline em pausa para que o administrador do pipeline possa avaliar as métricas-chave das versões de linha de base e canary e tomar a decisão sobre se as alterações canárias são seguras e boas o suficiente para uma implementação completa.

Asaction: promote tarefas de manifesto e strategy: canary ou action: reject e strategy: canary das tarefas de manifesto do Kubernetes podem ser utilizadas para promover ou rejeitar as alterações canárias, respetivamente. Tenha em atenção que, em ambos os casos, no final deste passo, apenas a variante estável das cargas de trabalho declaradas nos ficheiros de manifesto de entrada permanecerá implementada no cluster, enquanto a linha de base efémera e as versões canary são limpas.

Requisitos

Requisito	Description
Tipos de pipeline	YAML, Compilação clássica, Versão clássica
É executado em	Agent, DeploymentGroup
Exigências	Nenhuma
Capacidades	Esta tarefa não satisfaz quaisquer exigências para tarefas subsequentes na tarefa.
Restrições de comandos	Qualquer
Variáveis de tabelas definidas	Qualquer
Versão do agente	Todas as versões de agente suportadas.
Categoria da tarefa	Implementação