Schemi, funzionalità ed esempi
I documenti AWS Systems Manager (SSM) utilizzano le seguenti versioni dello schema.
-
I documenti di tipo
Command
possono utilizzare le versione dello schema 1.2, 2.0 e 2.2. Se si utilizzano documenti con lo schema 1.2, consigliamo di creare documenti con la versione 2.2 dello schema. -
I documenti di tipo
Policy
devono utilizzare la versione dello schema 2.0 o una versione successiva. -
I documenti di tipo
Automation
devono utilizzare la versione dello schema 0.3. -
I documenti di tipo
Session
devono utilizzare la versione dello schema 1.0. -
Puoi creare documenti in formato JSON o YAML.
Per ulteriori informazioni sull'utilizzo del documento schema Session
, consulta Schema documento di sessione.
Utilizzando la versione più recente dello schema per documenti Command
e Policy
, puoi sfruttare le seguenti caratteristiche.
Funzionalità | Informazioni |
---|---|
Modifica dei documenti |
Ora i documenti possono essere aggiornati. Con la versione 1.2, qualsiasi aggiornamento a un documento doveva essere salvato con un nome diverso. |
Funzione Versioni multiple automatica |
Qualsiasi aggiornamento a un documento crea una nuova versione. Non si tratta di una versione dello schema, ma di una versione del documento. |
Versione predefinita |
Se disponi di più versioni di un documento, puoi specificare quale versione è il documento predefinito. |
Sequenziamento |
I plugin o le fasi in un documento vengono eseguiti nell'ordine specificato. |
Supporto multipiattaforma |
Il supporto multipiattaforma consente di specificare sistemi operativi differenti per plugin differenti all'interno dello stesso documento SSM. Il supporto multipiattaforma utilizza il parametro |
Nota
Per utilizzare nuove funzionalità di Systems Manager e caratteristiche del documento SSM, si deve mantenere SSM Agent di AWS Systems Manager sulle istanze aggiornato alla versione più recente. Per ulteriori informazioni, consultare Aggiornamento di SSM Agent utilizzando Run Command.
Nella tabella seguente vengono elencate le differenze tra le versioni principali dello schema.
Versione 1.2 | Versione 2.2 (versione più recente) | Informazioni |
---|---|---|
runtimeConfig |
mainSteps |
Nella versione 2.2, la sezione |
properties |
inputs |
Nella versione 2.2, la sezione |
commands |
runCommand |
Nella versione 2.2, la sezione |
id |
action |
Nella versione 2.2, |
non applicabile |
nome |
Nella versione 2.2, |
Utilizzo del parametro Precondition
Con la versione dello schema 2.2 o successiva, è possibile utilizzare il parametro precondition
per specificare il sistema operativo di destinazione per ciascun plugin o convalidare i parametri di input definiti nel documento SSM. Il parametro precondition
supporta il riferimento ai parametri di input del documento SSM e platformType
utilizzando i valori di Linux
, MacOS
, e Windows
. Soltanto l'operatore StringEquals
è supportato.
Per i documenti che utilizzano la versione dello schema 2.2 o successiva, se precondition
non è specificato, ogni plugin viene eseguito o ignorato in base alla relativa compatibilità con il sistema operativo. La compatibilità dei plugin con il sistema operativo viene valutata prima di precondition
. Per i documenti che utilizzano la versione dello schema 2.0 o precedente, i plugin non compatibili generano un errore.
Ad esempio, in un documento che utilizza la versione dello schema 2.2, se precondition
non è specificato e il plugin aws:runShellScript
è presente, la fase viene eseguita sulle istanze Linux, ma il sistema la ignora sulle istanze Windows Server, poiché aws:runShellScript
non è compatibile con le istanze Windows Server. Tuttavia, per un documento che utilizza la versione dello schema 2.0, se specifichi il plugin aws:runShellScript
ed esegui il documento su istanze Windows Server, l'esecuzione non va a buon fine. Un esempio del parametro Precondition in un documento SSM è disponibile più avanti in questa sezione.
Versione dello schema 2.2
Elementi di primo livello
L'esempio seguente mostra gli elementi di primo livello di un documento SSM che utilizza la versione dello schema 2.2.
Esempio con per la versione dello schema 2.2
Nell'esempio seguente viene utilizzato il plugin aws:runPowerShellScript
per eseguire un comando PowerShell sulle istanze di destinazione.
Esempi del parametro Precondition per la versione dello schema 2.2
La versione dello schema 2.2 offre il supporto multipiattaforma. Ciò significa che all'interno di un singolo documento SSM è possibile specificare sistemi operativi differenti per plugin differenti. Il supporto multipiattaforma utilizza il parametro precondition
all'interno di una fase, come mostrato nel seguente esempio. È possibile utilizzare il parametro precondition
anche per convalidare i parametri di input definiti nel documento SSM. Ne è la riprova il secondo dei seguenti esempi.
Esempio con State Manager per la versione dello schema 2.2
È possibile utilizzare il seguente documento SSM con State Manager, una funzionalità di Systems Manager, per scaricare e installare il software antivirus ClamAV. State Manager applica una configurazione specifica, per cui ogni volta che viene eseguita l'associazione a State Manager, il sistema verifica se il software ClamAV è installato. Se così non fosse, State Manager esegue nuovamente questo documento.
Esempio di versione dello schema 2.2 per un inventario
È possibile utilizzare il seguente documento con State Manager per raccogliere i metadati di inventario sulle istanze.
Esempio con AWS-ConfigureAWSPackage
per la versione dello schema 2.2
L'esempio seguente mostra il documento AWS-ConfigureAWSPackage
. La sezione mainSteps
include il plugin aws:configurePackage
nella fase action
.
Nota
Sui sistemi operativi Linux sono supportati solo i pacchetti AmazonCloudWatchAgent
e AWSSupport-EC2Rescue
.
Versione dello schema 1.2
L'esempio seguente mostra gli elementi di primo livello di un documento che utilizza la versione dello schema 1.2.
{ "schemaVersion":"1.2", "description":"
A description of the SSM document.
", "parameters":{ "parameter 1
":{ "one or more parameter properties
" }, "parameter 2
":{ "one or more parameter properties
" }, "parameter 3
":{ "one or more parameter properties
" } }, "runtimeConfig":{ "plugin 1
":{ "properties":[ { "one or more plugin properties
" } ] } } }
Esempio con aws:runShellScript
per la versione dello schema 1.2
L'esempio seguente mostra il documento SSM AWS-RunShellScript
. La sezione runtimeConfig include il plugin aws:runShellScript
.
{ "schemaVersion":"1.2", "description":"Run a shell script or specify the commands to run.", "parameters":{ "commands":{ "type":"StringList", "description":"(Required) Specify a shell script or a command to run.", "minItems":1, "displayType":"textarea" }, "workingDirectory":{ "type":"String", "default":"", "description":"(Optional) The path to the working directory on your instance.", "maxChars":4096 }, "executionTimeout":{ "type":"String", "default":"3600", "description":"(Optional) The time in seconds for a command to complete before it is considered to have failed. Default is 3600 (1 hour). Maximum is 172800 (48 hours).", "allowedPattern":"([1-9][0-9]{0,3})|(1[0-9]{1,4})|(2[0-7][0-9]{1,3})|(28[0-7][0-9]{1,2})|(28800)" } }, "runtimeConfig":{ "aws:runShellScript":{ "properties":[ { "id":"0.aws:runShellScript", "runCommand":"{{ commands }}", "workingDirectory":"{{ workingDirectory }}", "timeoutSeconds":"{{ executionTimeout }}" } ] } } }
Versione dello schema 0.3
Elementi di primo livello
L'esempio seguente mostra gli elementi di primo livello di un runbook di automazione che utilizza la versione dello schema 0.3 in formato JSON.
{ "description": "
document-description
", "schemaVersion": "0.3", "assumeRole": "{{assumeRole}}", "parameters": { "parameter1": { "type": "String", "description": "parameter-1-description
", "default": "" }, "parameter2": { "type": "String", "description": "parameter-2-description
", "default": "" } }, "variables": { "variable1": { "type": "StringMap", "description": "variable-1-description
", "default": {} }, "variable2": { "type": "String", "description": "variable-2-description
", "default": "default-value
" } }, "mainSteps": [ { "name": "myStepName
", "action": "action-name
", "maxAttempts": 1, "inputs": { "Handler": "python-only-handler-name
", "Runtime": "runtime-name
", "Attachment": "script-or-zip-name
" }, "outputs": { "Name": "output-name
", "Selector": "selector.value
", "Type": "data-type
" } } ], "files": { "script-or-zip-name
": { "checksums": { "sha256": "checksum
" }, "size":1234
} } }
Esempio di runbook di automazione YAML
L'esempio seguente mostra il contenuto di un runbook di automazione, in formato YAML. Questo esempio d'uso della versione 0.3 dello schema del documento dimostra anche l'utilizzo di Markdown per formattare le descrizioni dei documenti.
description: >- ##Title: LaunchInstanceAndCheckState ----- **Purpose**: This Automation runbook first launches an EC2 instance using the AMI ID provided in the parameter ```imageId```. The second step of this document continuously checks the instance status check value for the launched instance until the status ```ok``` is returned. ##Parameters: ----- Name | Type | Description | Default Value ------------- | ------------- | ------------- | ------------- assumeRole | String | (Optional) The ARN of the role that allows Automation to perform the actions on your behalf. | - imageId | String | (Optional) The AMI ID to use for launching the instance. The default value uses the latest Amazon Linux AMI ID available. | {{ ssm:/aws/service/ami-amazon-linux-latest/amzn-ami-hvm-x86_64-gp2 }} schemaVersion: '0.3' assumeRole: 'arn:aws:iam::111122223333::role/AutomationServiceRole' parameters: imageId: type: String default: '{{ ssm:/aws/service/ami-amazon-linux-latest/amzn-ami-hvm-x86_64-gp2 }}' description: >- (Optional) The AMI ID to use for launching the instance. The default value uses the latest released Amazon Linux AMI ID. tagValue: type: String default: ' LaunchedBySsmAutomation' description: >- (Optional) The tag value to add to the instance. The default value is LaunchedBySsmAutomation. instanceType: type: String default: t2.micro description: >- (Optional) The instance type to use for the instance. The default value is t2.micro. mainSteps: - name: LaunchEc2Instance action: 'aws:executeScript' outputs: - Name: payload Selector: $.Payload Type: StringMap inputs: Runtime: python3.8 Handler: launch_instance Script: '' InputPayload: image_id: '{{ imageId }}' tag_value: '{{ tagValue }}' instance_type: '{{ instanceType }}' Attachment: launch.py description: >- **About This Step** This step first launches an EC2 instance using the ```aws:executeScript``` action and the provided python script. - name: WaitForInstanceStatusOk action: 'aws:executeScript' inputs: Runtime: python3.8 Handler: poll_instance Script: |- def poll_instance(events, context): import boto3 import time ec2 = boto3.client('ec2') instance_id = events['InstanceId'] print('[INFO] Waiting for instance status check to report ok', instance_id) instance_status = "null" while True: res = ec2.describe_instance_status(InstanceIds=[instance_id]) if len(res['InstanceStatuses']) == 0: print("Instance status information is not available yet") time.sleep(5) continue instance_status = res['InstanceStatuses'][0]['InstanceStatus']['Status'] print('[INFO] Polling to get status of the instance', instance_status) if instance_status == 'ok': break time.sleep(10) return {'Status': instance_status, 'InstanceId': instance_id} InputPayload: '{{ LaunchEc2Instance.payload }}' description: >- **About This Step** The python script continuously polls the instance status check value for the instance launched in Step 1 until the ```ok``` status is returned. files: launch.py: checksums: sha256: 18871b1311b295c43d0f...[truncated]...772da97b67e99d84d342ef4aEXAMPLE