KubernetesManifest@0: tarea Implementar en Kubernetes v0

Use una tarea de manifiesto de Kubernetes en una canalización de compilación o versión para crear e implementar manifiestos en clústeres de Kubernetes mediante gráficos de Helm.

Sintaxis

# 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 - Acción
string. Valores permitidos: bake, createSecret (crear secreto), delete, deploy, promotepatch, , scale, reject. Valor predeterminado: deploy.

Especifica la acción que se va a realizar.

kubernetesServiceConnection - Conexión de servicio de Kubernetes
string. Necesario cuando action != bake.

Especifica una conexión de servicio de Kubernetes.

namespace - Nombres
string.

Especifica el espacio de nombres de los comandos mediante la –namespace marca . Si no se proporciona el espacio de nombres, los comandos se ejecutarán en el espacio de nombres predeterminado.

strategy - Estrategia
string. Opcional. Use cuando action = deploy || action = promote || action = reject. Valores permitidos: canary, none. Valor predeterminado: none.

Especifica la estrategia de implementación usada en la deploy acción antes de una promote acción o reject acción. Actualmente, canary es la única estrategia de implementación aceptable.

trafficSplitMethod - Método de división de tráfico
string. Opcional. Use cuando strategy = canary. Valores permitidos: pod, smi. Valor predeterminado: pod.

Para el valor smi, la división de tráfico porcentual se realiza en el nivel de solicitud mediante una malla de servicio. Un administrador del clúster debe configurar una malla de servicio. Esta tarea controla la orquestación de objetos TrafficSplit de SMI.

Para el valor pod, la división de porcentaje no es posible en el nivel de solicitud en ausencia de una malla de servicio. En su lugar, la entrada de porcentaje se usa para calcular las réplicas de línea base y de valor controlado. El cálculo es un porcentaje de réplicas que se especifican en los manifiestos de entrada para la variante estable.

percentage - Porcentaje
string. Necesario cuando strategy = Canary && action = deploy. Valor predeterminado: 0.

Porcentaje que se usa para calcular el número de réplicas de variante de línea base y de variante controlada de las cargas de trabajo contenidas en los archivos de manifiesto.

Para la entrada de porcentaje especificada, calcule:

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

Si el resultado no es un entero, se usa el piso matemático del resultado cuando se crean las variantes de línea base y canary.

Por ejemplo, supongamos que la implementación hello-world está en el archivo de manifiesto de entrada y que las líneas siguientes están en la entrada de la tarea:

replicas: 4
strategy: canary
percentage: 25

En este caso, las implementaciones hello-world-baseline y hello-world-canary se crean con una réplica cada una. La variante de línea base se crea con la misma imagen y etiqueta que la versión estable, que es la variante de cuatro réplicas antes de la implementación. La variante de valor controlado se crea con la imagen y la etiqueta correspondientes a los cambios recién implementados.

baselineAndCanaryReplicas - Réplicas de línea base y controladas
string. Necesario cuando strategy = Canary && action = deploy && trafficSplitMethod = SMI. Valor predeterminado: 1.

Cuando se establece trafficSplitMethodsmien , el porcentaje de división del tráfico se controla en el plano de malla de servicio. Puede controlar el número real de réplicas para variantes controladas y de línea base independientemente de la división del tráfico.

Por ejemplo, supongamos que el manifiesto de implementación de entrada especifica 30 réplicas para la variante estable. Suponga también que especifica la siguiente entrada para la tarea:

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

En este caso, la variante estable recibe el 80 % del tráfico, mientras que las variantes de línea base y de valor controlado reciben cada mitad del 20 %. Las variantes de línea base y de valor controlado no reciben tres réplicas cada una. En su lugar, reciben el número especificado de réplicas, lo que significa que cada una recibe una réplica.

manifests - Manifiesta
string. Necesario cuando action = deploy || action = promote || action = reject.

Especifica la ruta de acceso a los archivos de manifiesto que se van a usar para la implementación. Cada línea representa una única ruta de acceso. Un patrón de coincidencia de archivos es un valor aceptable para cada línea.

containers - Contenedores
string. Opcional. Use cuando action = deploy || action = promote || action = bake.

Especifica la dirección URL de recurso completa de la imagen que se va a usar para las sustituciones en los archivos de manifiesto. La dirección URL contosodemo.azurecr.io/helloworld:test es un ejemplo.

imagePullSecrets - ImagePullSecrets
string. Opcional. Use cuando action = deploy || action = promote.

Especifica una entrada de varias líneas en la que cada línea contiene el nombre de un secreto del registro de Docker que ya se ha configurado en el clúster. Cada nombre de secreto se agrega en imagePullSecrets para las cargas de trabajo que se encuentran en los archivos de manifiesto de entrada.

renderType - Motor de representación
string. Opcional. Use cuando action = bake. Valores permitidos: helm, kompose y kustomize. Valor predeterminado: helm.

Especifica el tipo de representación usado para generar los archivos de manifiesto.

dockerComposeFile - Ruta de acceso al archivo docker compose
string. Necesario cuando action = bake && renderType = kompose.

Especifica una ruta de acceso de archivo docker-compose.

helmChart - Gráfico de Helm
string. Necesario cuando action = bake && renderType = helm.

Especifica la ruta de acceso del gráfico de Helm que se va a hornear.

releaseName - Nombre de la versión de Helm
string. Opcional. Use cuando action = bake && renderType = helm.

Especifica el nombre de la versión de Helm que se va a usar.

overrideFiles - Invalidar archivos
string. Opcional. Use cuando action = bake && renderType = helm.

Especifica una entrada de varias líneas que acepta la ruta de acceso a los archivos de invalidación. Los archivos se usan cuando se hornean los archivos de manifiesto de los gráficos de Helm.

overrides - Reemplaza
string. Opcional. Use cuando action = bake && renderType = helm.

Especifica los valores de invalidación que se van a establecer.

kustomizationPath - Ruta de acceso de kustomización
string. Opcional. Use cuando action = bake && renderType = kustomize.

Especifica el argumento que debe ser la ruta de acceso al directorio que contiene el archivo o una dirección URL del repositorio de Git con un sufijo de ruta de acceso que especifica same con respecto a la raíz del repositorio.

resourceToPatch - Recurso para aplicar revisiones
string. Necesario cuando action = patch. Valores permitidos: file, name. Valor predeterminado: file.

Indica uno de los métodos de revisión siguientes:

• Un archivo de manifiesto identifica los objetos que se van a aplicar revisiones.
• Un objeto individual se identifica por tipo y nombre como destino de revisión.

Los valores aceptables son archivo y nombre.

resourceFileToPatch - Ruta de acceso del archivo
string. Necesario cuando action = patch && resourceToPatch = file.

Especifica la ruta de acceso al archivo usado para una revisión.

kind - Tipo
string. Necesario cuando action = scale || resourceToPatch = name. Valores permitidos: deployment, replicaset y statefulset.

Especifica el tipo de objeto K8s, como deployment, replicaSet y mucho más.

name - Nombre
string. Necesario cuando action = scale || resourceToPatch = name.

Especifica el nombre del objeto K8s.

replicas - Recuento de réplicas
string. Necesario cuando action = scale.

Especifica el número de réplicas a las que se va a escalar.

mergeStrategy - Estrategia de combinación
string. Necesario cuando action = patch. Valores permitidos: json, merge y strategic. Valor predeterminado: strategic.

Especifica el tipo de revisión que se proporciona.

arguments - Argumentos
string. Opcional. Use cuando action = delete.

Especifica los argumentos del kubectl delete comando. Un ejemplo es: arguments: deployment hello-world foo-bar

patch - Parche
string. Necesario cuando action = patch.

Especifica el contenido de la revisión.

secretType - Tipo de secreto
string. Necesario cuando action = createSecret. Valores permitidos: dockerRegistry, generic. Valor predeterminado: dockerRegistry.

Crea o actualiza un docker genérico o .imagepullsecret Especifique dockerRegistry para crear o actualizar el imagepullsecret del Registro seleccionado. Una imagePullSecret es una manera de pasar un secreto que contiene una contraseña del registro de contenedor a Kubelet, por lo que puede extraer una imagen privada en nombre del pod.

secretName - Nombre del secreto
string. Opcional. Use cuando action = createSecret.

Especifica el nombre del secreto. Puede usar este nombre de secreto en el archivo de configuración de YAML de Kubernetes.

secretArguments - Argumentos
string. Opcional. Use cuando action = createSecret && secretType = generic.

Especifica las claves y los valores literales que se van a insertar en secreto. Por ejemplo, --from-literal=key1=value1--from-literal=key2="top secret".

dockerRegistryEndpoint - Conexión del servicio del registro de Docker
string. Opcional. Use cuando action = createSecret && secretType = dockerRegistry.

Especifica las credenciales de la conexión de servicio especificada que se usan para crear un secreto del registro de Docker en el clúster. Los archivos de manifiesto del imagePullSecrets campo pueden hacer referencia al nombre de este secreto.

rolloutStatusTimeout - Tiempo de espera para el estado de lanzamiento
string. Opcional. Use cuando action = deploy || action = patch || action = scale || action = promote. Valor predeterminado: 0.

Especifica el período de tiempo (en segundos) que se esperará antes de finalizar watch on rollout el estado.

Opciones de control de tareas

Todas las tareas tienen opciones de control además de sus entradas de tareas. Para obtener más información, vea Opciones de control y propiedades de tareas comunes.

Variables de salida

Esta tarea define las siguientes variables de salida, que puede consumir en pasos, trabajos y fases de bajada.

manifestsBundle
Especifica la ubicación de los conjuntos de manifiestos creados por la acción bake.

Comentarios

Nota:

Hay una versión más reciente de esta tarea disponible que proporciona compatibilidad adicional para establecer como destino un clúster de Kubernetes de diferentes maneras, mediante la connectionType propiedad . Para más información, consulte KubernetesManifest@1 y comentarios de conexión de servicio KubernetesManifest@1

Use una tarea de manifiesto de Kubernetes en una canalización de compilación o versión para hornear e implementar manifiestos en clústeres de Kubernetes.

Esta tarea admite lo siguiente:

• Sustitución de artefactos: la acción de implementación toma como entrada una lista de imágenes de contenedor que puede especificar junto con sus etiquetas e resúmenes. La misma entrada se sustituye por los archivos de manifiesto nontemplatized antes de la aplicación al clúster. Esta sustitución garantiza que los nodos del clúster extraen la versión correcta de la imagen.

• Estabilidad del manifiesto: se comprueba el estado de lanzamiento de los objetos de Kubernetes implementados. Las comprobaciones de estabilidad se incorporan para determinar si el estado de la tarea es correcto o no.

• Anotaciones de rastreabilidad: las anotaciones se agregan a los objetos de Kubernetes implementados para superponer la información de rastreabilidad. Se admiten las anotaciones siguientes:

  • azure-pipelines/org
  • azure-pipelines/project
  • azure-pipelines/pipeline
  • azure-pipelines/pipelineId
  • azure-pipelines/execution
  • azure-pipelines/executionuri
  • azure-pipelines/jobName

• Control de secretos: la createSecret acción permite crear secretos del registro de Docker mediante conexiones del servicio del registro de Docker. También permite crear secretos genéricos mediante variables de texto sin formato o variables secretas. Antes de la implementación en el clúster, puede usar la secrets entrada junto con la deploy acción para aumentar los archivos de manifiesto de entrada con el valor adecuado imagePullSecrets .

• Manifiesto de bake: la bake acción de la tarea permite hornear plantillas en archivos de manifiesto de Kubernetes. La acción usa herramientas como Helm, Compose y Kustomize. Con la baking, estos archivos de manifiesto de Kubernetes se pueden usar para las implementaciones en el clúster.

• Estrategia de implementación: elegir la canary estrategia con la deploy acción conduce a la creación de nombres de carga de trabajo con -baseline y -canary. La tarea admite dos métodos de división de tráfico:

  • Interfaz de Service Mesh: la abstracción de service Mesh Interface (SMI) permite la configuración con proveedores de malla de servicio como Linkerd y Istio. La tarea Manifiesto de Kubernetes asigna objetos SMI TrafficSplit a los servicios estables, de línea de base y controlados durante el ciclo de vida de la estrategia de implementación.

    Las implementaciones controladas basadas en una malla de servicio y que usan esta tarea son más precisas. Esta precisión se debe a cómo los proveedores de malla de servicio habilitan la división por porcentaje pormenorizadas del tráfico. La malla de servicio usa el registro de servicio y los contenedores sidecar que se insertan en pods. Esta inyección se produce junto con los contenedores de aplicaciones para lograr la división de tráfico pormenorizadas.

  • Kubernetes sin malla de servicio: en ausencia de una malla de servicio, es posible que no obtenga la división de porcentaje exacta que desee en el nivel de solicitud. Sin embargo, puede realizar implementaciones controladas mediante variantes de línea base y de valor controlado junto a la variante estable.

    El servicio envía solicitudes a pods de las tres variantes de carga de trabajo a medida que se cumplen las restricciones selector-label. El manifiesto de Kubernetes respeta estas solicitudes al crear variantes de línea base y de valor controlado. Este comportamiento de enrutamiento logra el efecto previsto de enrutar solo una parte de las solicitudes totales a los valores controlados.

  Compare las cargas de trabajo de línea base y de valor controlado mediante una tarea de intervención manual en canalizaciones de versión o una tarea retraso en canalizaciones de YAML. Realice la comparación antes de usar la acción promover o rechazar de la tarea.

Acción de implementación

El código YAML siguiente es un ejemplo de implementación en un espacio de nombres de Kubernetes mediante archivos de manifiesto:

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

En el ejemplo anterior, la tarea intenta buscar coincidencias para las imágenes foo/demo y bar/demo en los campos de imagen de los archivos de manifiesto. Para cada coincidencia encontrada, el valor de o tagVariable1tagVariable2 se anexa como una etiqueta al nombre de la imagen. También puede especificar resúmenes en la entrada de contenedores para la sustitución de artefactos.

Nota:

Aunque puede crear deployacciones , promotey reject con la entrada YAML relacionada con la estrategia de implementación, la compatibilidad con una tarea de intervención manual no está disponible actualmente para las canalizaciones de compilación.

En el caso de las canalizaciones de versión, le recomendamos que use acciones y entradas relacionadas con la estrategia de implementación en la secuencia siguiente:

1. Una acción de implementación especificada con strategy: canary y percentage: $(someValue).
2. Una tarea De intervención manual para que pueda pausar la canalización y comparar la variante de línea base con la variante de valor controlado.
3. Acción de promoción que se ejecuta si se reanuda una tarea de intervención manual y una acción de rechazo que se ejecuta si se rechaza una tarea de intervención manual.

Creación de una acción secreta

El siguiente código YAML muestra una creación de ejemplo de secretos del registro de Docker mediante la conexión del servicio registro de 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 muestra una creación de ejemplo de secretos 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

Acción bake

El siguiente código YAML es un ejemplo de archivos de manifiesto de baking de gráficos de Helm. Tenga en cuenta el uso de una entrada de nombre en la primera tarea. Este nombre se hace referencia más adelante desde el paso de implementación para especificar la ruta de acceso a los manifiestos generados por el paso de elaboración.

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 usar Helm directamente para administrar versiones y reversiones, consulte la tarea Empaquetar e implementar gráficos de Helm.

Ejemplo de Kustomize

El siguiente código YAML es un ejemplo de archivos de manifiesto de baking generados con Kustomize que contienen un kustomization.yaml archivo.

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)

Ejemplo de Kompose

El siguiente código YAML es un ejemplo de archivos de manifiesto de baking generados con Kompose, una herramienta de conversión 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)

Acción de escalado

El siguiente código YAML muestra un ejemplo de objetos de escalado:

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

Acción de revisión

El código YAML siguiente muestra un ejemplo de aplicación de revisiones 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 acción

Este código YAML muestra una eliminación de objeto de ejemplo:

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

Solución de problemas

Mi clúster de Kubernetes está detrás de un firewall y estoy usando agentes hospedados. ¿Cómo se puede implementar en este clúster?

Puede conceder acceso a los agentes hospedados a través del firewall, permitiendo las direcciones IP de los agentes hospedados. Para más información, consulte el artículo sobre los intervalos IP del agente.

¿Cómo funcionan las solicitudes en rutas de servicio estables y variantes con implementaciones de valor controlado?

La relación del selector de etiquetas entre pods y servicios en Kubernetes permite configurar implementaciones para que un único servicio enrute las solicitudes a las variantes estables y de valor controlado. La tarea de manifiesto de Kubernetes la usa para las implementaciones de valor controlado.

Si la tarea incluye las entradas de y strategy: canary, para cada carga de action: deploy trabajo (Implementación, ReplicaSet, Pod, ...) definida en los archivos de manifiesto de entrada, se crea una -baseline variante y -canary de la implementación. En este ejemplo, hay una implementación sampleapp en el archivo de manifiesto de entrada y que después de finalizar la ejecución número 22 de la canalización, la variante estable de esta implementación denominada sampleapp se implementa en el clúster. En la ejecución posterior (en este caso, número de ejecución 23), la tarea de manifiesto de Kubernetes con action: deploy y strategy: canary daría lugar a la creación de implementaciones sampleapp-baseline y sampleapp-canary cuyo número de réplicas viene determinado por el producto de la entrada de percentage tarea con el valor del número deseado de réplicas para la variante estable final de sampleapp según los archivos de manifiesto de entrada.

Sin incluir el número de réplicas, la versión de línea base tiene la misma configuración que la variante estable, mientras que la versión de valor controlado tiene los nuevos cambios introducidos por la ejecución actual (en este caso, el número de ejecución 23). Si se configura una intervención manual en la canalización después del paso mencionado anteriormente, permitiría pausar la canalización para que el administrador de la canalización pueda evaluar las métricas clave de las versiones de línea base y de valor controlado y tomar la decisión sobre si los cambios controlados son seguros y lo suficientemente buenos para una implementación completa.

Lasaction: promote entradas y strategy: canary y strategy: canaryaction: reject de las tareas de manifiesto de Kubernetes se pueden usar para promover o rechazar los cambios controlados, respectivamente. Tenga en cuenta que, al final de este paso, solo se implementará la variante estable de las cargas de trabajo declaradas en los archivos de manifiesto de entrada en el clúster, mientras que la línea base efímera y las versiones controladas se limpian.

Requisitos

Requisito	Descripción
Tipos de canalización	YAML, compilación clásica, versión clásica
Se ejecuta en	Agente, DeploymentGroup
Peticiones	None
Capabilities	Esta tarea no satisface ninguna demanda de tareas posteriores en el trabajo.
Restricciones de comandos	Any
Variables que se pueden establecer	Any
Versión del agente	Todas las versiones de agente admitidas.
Categoría de la tarea:	Implementación