KubernetesManifest@0 - Distribuire nell'attività kubernetes v0

Usare un'attività manifesto Kubernetes in una pipeline di compilazione o versione per creare e distribuire manifesti nei cluster Kubernetes usando i grafici Helm.

Sintassi

# 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.

Input

action - Azione
string. Valori consentiti: bake, (create secret), deployscalerejectdeletepromotepatch, . createSecret Valore predefinito: deploy.

Specifica l'azione da eseguire.

kubernetesServiceConnection - Connessione al servizio Kubernetes
string. Obbligatorio quando action != bake.

Specifica una connessione al servizio Kubernetes.

namespace - Namespace
string.

Specifica lo spazio dei nomi per i comandi usando il –namespace flag. Se lo spazio dei nomi non viene specificato, i comandi verranno eseguiti nello spazio dei nomi predefinito.

strategy - Strategia
string. Facoltativa. Usare quando action = deploy || action = promote || action = reject. Valori consentiti: canary, none. Valore predefinito: none.

Specifica la strategia di distribuzione usata nell'azione deploy prima di un'azione promote o reject un'azione. Attualmente, canary è l'unica strategia di distribuzione accettabile.

trafficSplitMethod - Metodo di divisione del traffico
string. Facoltativa. Usare quando strategy = canary. Valori consentiti: pod, smi. Valore predefinito: pod.

Per il valore smi, la divisione percentuale del traffico viene eseguita a livello di richiesta usando una mesh di servizio. Una mesh di servizio deve essere configurata da un amministratore del cluster. Questa attività gestisce l'orchestrazione degli oggetti SMI TrafficSplit .

Per il valore pod, la divisione percentuale non è possibile a livello di richiesta in assenza di una mesh di servizio. Viene invece usato l'input percentuale per calcolare le repliche per baseline e canary. Il calcolo è una percentuale di repliche specificate nei manifesti di input per la variante stabile.

percentage - Percentuale
string. Obbligatorio quando strategy = Canary && action = deploy. Valore predefinito: 0.

Percentuale utilizzata per calcolare il numero di repliche varianti di base e varianti canary dei carichi di lavoro contenuti nei file manifesto.

Per l'input percentuale specificato, calcolare:

(percentuale × numero di repliche) / 100

Se il risultato non è un intero, il piano matematico del risultato viene usato quando vengono create varianti baseline e canary.

Si supponga, ad esempio, che la distribuzione hello-world si trovi nel file manifesto di input e che le righe seguenti si trovino nell'input dell'attività:

replicas: 4
strategy: canary
percentage: 25

In questo caso, le distribuzioni hello-world-baseline e hello-world-canary vengono create con una replica ogni. La variante di base viene creata con la stessa immagine e tag della versione stabile, ovvero la variante di quattro repliche prima della distribuzione. La variante canary viene creata con l'immagine e il tag corrispondenti alle modifiche appena distribuite.

baselineAndCanaryReplicas - Repliche baseline e canary
string. Obbligatorio quando strategy = Canary && action = deploy && trafficSplitMethod = SMI. Valore predefinito: 1.

Quando si imposta trafficSplitMethod su smi, la divisione del traffico percentuale viene controllata nel piano della mesh di servizio. È possibile controllare il numero effettivo di repliche per le varianti canary e baseline in modo indipendente dalla suddivisione del traffico.

Si supponga, ad esempio, che il manifesto della distribuzione di input specifica 30 repliche per la variante stabile. Si supponga inoltre di specificare l'input seguente per l'attività:

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

In questo caso, la variante stabile riceve il 80% del traffico, mentre le varianti baseline e canary ricevono la metà del 20%. Le varianti baseline e canary non ricevono tre repliche. Ricevono invece il numero specificato di repliche, che significa che ogni replica riceve una replica.

manifests - Manifesti
string. Obbligatorio quando action = deploy || action = promote || action = reject.

Specifica il percorso dei file manifesto da usare per la distribuzione. Ogni riga rappresenta un singolo percorso. Un modello di corrispondenza file è un valore accettabile per ogni riga.

containers - Contenitori
string. Facoltativa. Usare quando action = deploy || action = promote || action = bake.

Specifica l'URL completo della risorsa dell'immagine da usare per le sostituzioni nei file manifesto. L'URL contosodemo.azurecr.io/helloworld:test è un esempio.

imagePullSecrets - ImagePullSecrets
string. Facoltativa. Usare quando action = deploy || action = promote.

Specifica un input multilinea in cui ogni riga contiene il nome di un segreto del Registro Di sistema Docker già configurato all'interno del cluster. Ogni nome segreto viene aggiunto in imagePullSecrets per i carichi di lavoro trovati nei file manifesto di input.

renderType - Motore di rendering
string. Facoltativa. Usare quando action = bake. Valori consentiti: helm, kompose, kustomize. Valore predefinito: helm.

Specifica il tipo di rendering usato per produrre i file manifesto.

dockerComposeFile - Percorso del file di composizione docker
string. Obbligatorio quando action = bake && renderType = kompose.

Specifica un percorso di file docker-compose.

helmChart - Grafico Helm
string. Obbligatorio quando action = bake && renderType = helm.

Specifica il percorso del grafico Helm da bake.

releaseName - Nome versione Helm
string. Facoltativa. Usare quando action = bake && renderType = helm.

Specifica il nome della versione Helm da usare.

overrideFiles - Eseguire l'override dei file
string. Facoltativa. Usare quando action = bake && renderType = helm.

Specifica un input multilinea che accetta il percorso dei file di override. I file vengono usati quando vengono creati i file manifesto dei grafici Helm.

overrides - Esegue l' override
string. Facoltativa. Usare quando action = bake && renderType = helm.

Specifica i valori di override da impostare.

kustomizationPath - Percorso di kustomizzazione
string. Facoltativa. Usare quando action = bake && renderType = kustomize.

Specifica l'argomento che deve essere il percorso della directory contenente il file o un URL del repository Git con un suffisso percorso che specifica same rispetto alla radice del repository.

resourceToPatch - Risorsa da applicare alle patch
string. Obbligatorio quando action = patch. Valori consentiti: file, name. Valore predefinito: file.

Indica uno dei metodi di patch seguenti:

• Un file manifesto identifica gli oggetti da applicare a patch.
• Un singolo oggetto viene identificato da tipo e nome come destinazione della patch.

I valori accettabili sono file e nome.

resourceFileToPatch - Percorso file
string. Obbligatorio quando action = patch && resourceToPatch = file.

Specifica il percorso del file usato per una patch.

kind - Gentile
string. Obbligatorio quando action = scale || resourceToPatch = name. Valori consentiti: deployment, replicaset, statefulset.

Specifica il tipo di oggetto K8s, ad esempio deployment, replicaSet e altro ancora.

name - Nome
string. Obbligatorio quando action = scale || resourceToPatch = name.

Specifica il nome dell'oggetto K8s.

replicas - Numero di repliche
string. Obbligatorio quando action = scale.

Specifica il numero di repliche da ridimensionare.

mergeStrategy - Strategia di unione
string. Obbligatorio quando action = patch. Valori consentiti: json, merge, strategic. Valore predefinito: strategic.

Specifica il tipo di patch specificato.

arguments - Argomenti
string. Facoltativa. Usare quando action = delete.

Specifica gli argomenti per il kubectl delete comando. Un esempio è: arguments: deployment hello-world foo-bar

patch - Benda
string. Obbligatorio quando action = patch.

Specifica il contenuto della patch.

secretType - Tipo di segreto
string. Obbligatorio quando action = createSecret. Valori consentiti: dockerRegistry, generic. Valore predefinito: dockerRegistry.

Crea o aggiorna un oggetto generico o docker imagepullsecret. Specificare per creare o aggiornare dockerRegistry l'oggetto imagepullsecret del Registro di sistema selezionato. Un imagePullSecret è un modo per passare un segreto che contiene una password del Registro contenitori a Kubelet, in modo che possa eseguire il pull di un'immagine privata per conto del pod.

secretName - Nome segreto
string. Facoltativa. Usare quando action = createSecret.

Specifica il nome del segreto. È possibile usare questo nome segreto nel file di configurazione YAML kubernetes.

secretArguments - Argomenti
string. Facoltativa. Usare quando action = createSecret && secretType = generic.

Specifica le chiavi e i valori letterali da inserire nel segreto. Ad esempio, --from-literal=key1=value1--from-literal=key2="top secret".

dockerRegistryEndpoint - Connessione del servizio del Registro di sistema Docker
string. Facoltativa. Usare quando action = createSecret && secretType = dockerRegistry.

Specifica le credenziali della connessione del servizio specificata usata per creare un segreto del Registro Di sistema Docker all'interno del cluster. I file manifesto nel imagePullSecrets campo possono quindi fare riferimento al nome del segreto.

rolloutStatusTimeout - Timeout per lo stato di implementazione
string. Facoltativa. Usare quando action = deploy || action = patch || action = scale || action = promote. Valore predefinito: 0.

Specifica il periodo di tempo (in secondi) da attendere prima di terminare watch on rollout lo stato.

Opzioni di controllo attività

Tutte le attività dispongono di opzioni di controllo oltre ai relativi input attività. Per altre informazioni, vedere Opzioni di controllo e proprietà comuni delle attività.

Variabili di output

Questa attività definisce le variabili di output seguenti, che è possibile utilizzare nei passaggi, nei processi e nelle fasi downstream.

manifestsBundle
Specifica il percorso dei bundle manifesto creati dall'azione bake.

Commenti

Nota

È disponibile una versione più recente di questa attività che fornisce supporto aggiuntivo per la destinazione di un cluster Kubernetes in modi diversi, usando la connectionType proprietà . Per altre informazioni, vedere KubernetesManifest@1 e KubernetesManifest@1 osservazioni sulla connessione al servizio

Usare un'attività manifesto Kubernetes in una pipeline di compilazione o versione per creare e distribuire manifesti nei cluster Kubernetes.

Questa attività supporta quanto segue:

• Sostituzione degli artefatti: l'azione di distribuzione accetta come input un elenco di immagini del contenitore che è possibile specificare insieme ai tag e ai digest. Lo stesso input viene sostituito nei file manifesto non con estensionemplatized prima dell'applicazione nel cluster. Questa sostituzione garantisce che i nodi del cluster estraggono la versione corretta dell'immagine.

• Stabilità manifesto: viene controllato lo stato di implementazione degli oggetti Kubernetes distribuiti. I controlli di stabilità vengono incorporati per determinare se lo stato dell'attività è un esito positivo o un errore.

• Annotazioni di tracciabilità: le annotazioni vengono aggiunte agli oggetti Kubernetes distribuiti per sovrapporre informazioni sulla tracciabilità. Sono supportate le annotazioni seguenti:

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

• Gestione dei segreti: l'azione createSecret consente di creare segreti del Registro Di sistema Docker usando le connessioni del servizio del Registro di sistema Docker. Consente inoltre di creare segreti generici usando variabili di testo normale o variabili segrete. Prima della distribuzione nel cluster, è possibile usare l'input secrets insieme all'azione deploy per aumentare i file manifesto di input con il valore appropriato imagePullSecrets .

• Manifesto bake: l'azione bake dell'attività consente di creare modelli in file manifesto Kubernetes. L'azione usa strumenti come Helm, Compose e Kustomize. Con la cottura, questi file manifesto kubernetes sono utilizzabili per le distribuzioni nel cluster.

• Strategia di distribuzione: la scelta della strategia con l'azione canarydeploy comporta la creazione di nomi di carico di lavoro suffisso con -baseline e .-canary L'attività supporta due metodi di suddivisione del traffico:

  • Interfaccia mesh del servizio: l'astrazione di Service Mesh Interface (SMI) consente la configurazione con provider di mesh di servizio come Linkerd e Istio. L'attività Manifesto Kubernetes esegue il mapping degli oggetti SMI TrafficSplit ai servizi stabili, baseline e canary durante il ciclo di vita della strategia di distribuzione.

    Le distribuzioni Canary basate su una mesh di servizio e usano questa attività sono più accurate. Questa accuratezza è dovuta al modo in cui i provider di mesh di servizio consentono la suddivisione granulare in base alla percentuale di traffico. La mesh del servizio usa il Registro di sistema del servizio e i contenitori sidecar inseriti nei pod. Questo inserimento si verifica insieme ai contenitori dell'applicazione per ottenere la suddivisione granulare del traffico.

  • Kubernetes senza mesh di servizio: in assenza di una mesh di servizio, potrebbe non essere possibile ottenere la percentuale esatta di divisione desiderata a livello di richiesta. È tuttavia possibile eseguire distribuzioni canary usando varianti di base e canary accanto alla variante stabile.

    Il servizio invia richieste ai pod di tutte e tre le varianti del carico di lavoro perché vengono soddisfatti i vincoli di etichetta del selettore. Il manifesto kubernetes rispetta queste richieste durante la creazione di varianti baseline e canary. Questo comportamento di routing ottiene l'effetto previsto del routing solo una parte delle richieste totali al canary.

  Confrontare i carichi di lavoro baseline e canary usando un'attività Intervento manuale nelle pipeline di rilascio o un'attività Ritardo nelle pipeline YAML. Eseguire il confronto prima di usare l'azione di promozione o rifiuto dell'attività.

Distribuire l'azione

Il codice YAML seguente è un esempio di distribuzione in uno spazio dei nomi Kubernetes usando file 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

Nell'esempio precedente, l'attività tenta di trovare corrispondenze per le immagini foo/demo e bar/demo nei campi immagine dei file manifesto. Per ogni corrispondenza trovata, il valore di tagVariable1 o tagVariable2 viene aggiunto come tag al nome dell'immagine. È anche possibile specificare i digest nell'input dei contenitori per la sostituzione degli artefatti.

Nota

Anche se è possibile creare deploy, promotee reject azioni con l'input YAML correlato alla strategia di distribuzione, il supporto per un'attività Di intervento manuale non è attualmente disponibile per le pipeline di compilazione.

Per le pipeline di rilascio, è consigliabile usare azioni e input correlati alla strategia di distribuzione nella sequenza seguente:

1. Azione di distribuzione specificata con strategy: canary e percentage: $(someValue).
2. Attività Intervento manuale in modo che sia possibile sospendere la pipeline e confrontare la variante di base con la variante canary.
3. Un'azione di promozione eseguita se viene ripresa un'attività Di intervento manuale e un'azione di rifiuto eseguita se viene rifiutata un'attività Di intervento manuale.

Creare un'azione privata

Il codice YAML seguente mostra una creazione di esempio dei segreti del Registro Di sistema Docker usando la connessione del servizio Registro Di sistema Docker:

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

Questo codice YAML mostra una creazione di esempio di segreti generici:

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

Azione bake

Il codice YAML seguente è un esempio di file manifesto di cottura dai grafici Helm. Si noti l'utilizzo di un input di nome nella prima attività. Questo nome viene fatto riferimento successivamente dal passaggio di distribuzione per specificare il percorso dei manifesti generati dal passaggio bake.

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

Per usare Helm direttamente per gestire le versioni e i rollback, vedere l'attività Pacchetto e distribuzione dei grafici Helm.

Esempio di Kustomize

Il codice YAML seguente è un esempio di file manifesto di cottura generati con Kustomize che contengono un kustomization.yaml file.

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)

Esempio di Kompose

Il codice YAML seguente è un esempio di file manifesto di cottura generati con Kompose, uno strumento di conversione per 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)

Ridimensionare l'azione

Il codice YAML seguente mostra un esempio di ridimensionamento degli oggetti:

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

Azione patch

Il codice YAML seguente mostra un esempio di patch dell'oggetto:

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

Elimina azione

Questo codice YAML mostra un'eliminazione di oggetti di esempio:

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

Risoluzione dei problemi

Il cluster Kubernetes si trova dietro un firewall e si stanno usando gli agenti ospitati. Come si esegue la distribuzione in questo cluster?

È possibile concedere l'accesso agli agenti ospitati tramite il firewall, consentendo gli indirizzi IP per gli agenti ospitati. Per altre informazioni dettagliate, vedere Intervalli IP dell'agente.

Come funzionano le richieste alle route dei servizi stabili e varianti con distribuzioni canary?

La relazione del selettore etichette tra pod e servizi in Kubernetes consente di configurare le distribuzioni in modo che un singolo servizio esegua il route delle richieste alle varianti sia stabili che canary. L'attività manifesto di Kubernetes usa tale relazione per le distribuzioni canary.

Se l'attività include gli input di e strategy: canary, per ogni carico di action: deploy lavoro (Distribuzione, ReplicaSet, Pod, ...) definiti nei file manifesto di input, viene creata una -baseline variante e -canary della distribuzione. In questo esempio è presente una distribuzione sampleapp nel file manifesto di input e che dopo il completamento del numero di esecuzione 22 della pipeline, la variante stabile di questa distribuzione denominata sampleapp viene distribuita nel cluster. Nell'esecuzione successiva (in questo caso eseguire il numero 23), l'attività manifesto kubernetes con action: deploy e strategy: canary comporta la creazione di distribuzioni sampleapp-baseline e sampleapp-canary il cui numero di repliche è determinato dal prodotto dell'input dell'attività percentage con il valore del numero desiderato di repliche per la variante stabile finale di sampleapp come per i file manifesto di input.

Escluso il numero di repliche, la versione di base ha la stessa configurazione della variante stabile mentre la versione canary presenta le nuove modifiche introdotte dall'esecuzione corrente (in questo caso, eseguire il numero 23). Se un intervento manuale viene configurato nella pipeline dopo il passaggio indicato in precedenza, è possibile sospendere la pipeline in modo che l'amministratore della pipeline possa valutare le metriche chiave per le versioni baseline e canary e prendere la decisione su se le modifiche canary sono sicure e sufficienti per un'implementazione completa.

Leaction: promote attività del manifesto e o o action: rejectstrategy: canary e strategy: canary di Kubernetes possono essere usate rispettivamente per promuovere o rifiutare le modifiche canary. Si noti che in entrambi i casi, alla fine di questo passaggio, solo la variante stabile dei carichi di lavoro dichiarati nei file manifesto di input rimarrà distribuita nel cluster, mentre le versioni di base e canary temporanee vengono pulite.

Requisiti

Requisito	Descrizione
Tipi di pipeline	YAML, build classica, versione classica
Esecuzione in	Agente, DeploymentGroup
Richieste	Nessuno
Capabilities	Questa attività non soddisfa le richieste per le attività successive nel processo.
Restrizioni dei comandi	Qualsiasi
Variabili impostabili	Qualsiasi
Versione agente	Tutte le versioni dell'agente supportate.
Categoria attività	Distribuire