Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Verwenden Sie das AWSTOE Component Document Framework für benutzerdefinierte Komponenten
Um eine Komponente mithilfe des Komponenten-Frameworks AWS Task Orchestrator and Executor (AWSTOE) zu erstellen, müssen Sie ein YAML-basiertes Dokument bereitstellen, das die Phasen und Schritte darstellt, die für die von Ihnen erstellte Komponente gelten. AWS-Services verwenden Sie Ihre Komponente, wenn sie ein neues Amazon Machine Image (AMI) oder Container-Image erstellen.
**Topics**
+ [Workflow für Komponenten-Dokumente](#component-doc-workflow)
+ [Protokollierung von Komponenten](#component-logging)
+ [Verkettung von Eingabe und Ausgabe](#document-chaining)
+ [Schema und Definitionen des Dokuments](#document-schema)
+ [Beispiele für Dokumente](#document-example)
+ [Verwenden Sie Variablen in Ihrem Dokument mit benutzerdefinierten Komponenten](toe-user-defined-variables.md)
+ [Verwenden Sie bedingte Konstrukte in AWSTOE](toe-conditional-constructs.md)
+ [Verwenden Sie Vergleichsoperatoren in AWSTOE Komponentendokumenten](toe-comparison-operators.md)
+ [Verwenden Sie logische Operatoren in AWSTOE Komponentendokumenten](toe-logical-operators.md)
+ [Verwenden Sie Looping-Konstrukte in AWSTOE](toe-looping-constructs.md)
## Workflow für Komponenten-Dokumente
Das AWSTOE Komponentendokument verwendet Phasen und Schritte, um verwandte Aufgaben zu gruppieren und diese Aufgaben in einem logischen Workflow für die Komponente zu organisieren.
**Tipp**
Der Dienst, der Ihre Komponente zum Erstellen eines Images verwendet, implementiert möglicherweise Regeln darüber, welche Phasen für den Build-Prozess verwendet werden sollen und wann diese Phasen ausgeführt werden dürfen. Dies ist wichtig, wenn Sie Ihre Komponente entwerfen.
**Phasen**
Phasen stellen den Verlauf Ihres Workflows durch den Image-Erstellungsprozess dar. Beispielsweise verwendet der Image Builder Builder-Dienst die `validate` Phasen `build` und Phasen während der *Erstellungsphase* für die von ihm erstellten Images. Es verwendet die `container-host-test` Phasen `test` und während der *Testphase*, um sicherzustellen, dass der Image-Snapshot oder das Container-Image die erwarteten Ergebnisse liefert, bevor das endgültige AMI erstellt oder das Container-Image verteilt wird.
Wenn die Komponente ausgeführt wird, werden die zugehörigen Befehle für jede Phase in der Reihenfolge angewendet, in der sie im Komponentendokument erscheinen.
**Regeln für Phasen**
+ Jeder Phasenname muss innerhalb eines Dokuments eindeutig sein.
+ Sie können viele Phasen in Ihrem Dokument definieren.
+ Sie müssen mindestens eine der folgenden Phasen in Ihr Dokument aufnehmen:
+ **build** — für Image Builder wird diese Phase in der Regel während der *Buildphase* verwendet.
+ **validieren** — für Image Builder wird diese Phase in der Regel während der *Erstellungsphase* verwendet.
+ **test** — für Image Builder wird diese Phase im Allgemeinen während der *Testphase* verwendet.
+ Phasen werden immer in der Reihenfolge ausgeführt, in der sie im Dokument definiert sind. Die Reihenfolge, in der sie für AWSTOE Befehle in angegeben sind, AWS CLI hat keine Auswirkung.
**Schritte**
Schritte sind einzelne Arbeitseinheiten, die den Arbeitsablauf innerhalb jeder Phase definieren. Die Schritte werden nacheinander ausgeführt. Die Eingabe oder Ausgabe für einen Schritt kann jedoch auch als Eingabe in einen nachfolgenden Schritt einfließen. Dies wird als „Verkettung“ bezeichnet.
**Regeln für Schritte**
+ Der Schrittname muss für die Phase eindeutig sein.
+ Der Schritt muss eine unterstützte Aktion (Aktionsmodul) verwenden, die einen Exit-Code zurückgibt.
Eine vollständige Liste der unterstützten Aktionsmodule, deren Funktionsweise, input/output Werte und Beispiele finden Sie unter[Aktionsmodule, die vom AWSTOE Komponentenmanager unterstützt werden](toe-action-modules.md).
## Protokollierung von Komponenten
AWSTOE erstellt bei jeder Ausführung Ihrer Komponente einen neuen Protokollordner auf den EC2-Instances, die zum Erstellen und Testen eines neuen Images verwendet werden. Bei Container-Images wird der Protokollordner im Container gespeichert.
Zur Unterstützung bei der Problembehandlung, falls bei der Erstellung des Images ein Fehler auftritt, werden das Eingabedokument und alle Ausgabedateien, die bei der Ausführung der Komponente AWSTOE erstellt werden, im Protokollordner gespeichert.
Der Name des Protokollordners besteht aus den folgenden Teilen:
1. **Protokollverzeichnis** — Wenn ein Dienst eine AWSTOE Komponente ausführt, übergibt sie das Protokollverzeichnis zusammen mit anderen Einstellungen für den Befehl. In den folgenden Beispielen zeigen wir das Protokolldateiformat, das Image Builder verwendet.
+ **Linux und macOS**: `/var/lib/amazon/toe/`
+ **Windows**: `$env:ProgramFiles\Amazon\TaskOrchestratorAndExecutor\`
1. **Dateipräfix** — Dies ist ein Standardpräfix, das für alle Komponenten verwendet wird: "`TOE_`“.
1. **Laufzeit — Dies ist ein Zeitstempel** im Format YYYY-MM-DD \$1HH-MM-SS\$1UTC-0.
1. **Ausführungs-ID — Dies ist die GUID**, die zugewiesen wird, wenn eine oder mehrere Komponenten ausgeführt werden. AWSTOE
Beispiel: `/var/lib/amazon/toe/TOE_2021-07-01_12-34-56_UTC-0_a1bcd2e3-45f6-789a-bcde-0fa1b2c3def4`
AWSTOE speichert die folgenden Kerndateien im Protokollordner:
**Eingabedateien**
+ **document.yaml** — Das Dokument, das als Eingabe für den Befehl verwendet wird. Nachdem die Komponente ausgeführt wurde, wird diese Datei als Artefakt gespeichert.
**Ausgabedateien**
+ **application.log** — Das Anwendungsprotokoll enthält Informationen auf Debug-Ebene mit Zeitstempel AWSTOE darüber, was passiert, während die Komponente ausgeführt wird.
+ **detailedoutput.json** — Diese JSON-Datei enthält detaillierte Informationen zum Ausführungsstatus, zu Eingaben, Ausgaben und Fehlern für alle Dokumente, Phasen und Schritte, die für die Komponente gelten, während sie ausgeführt wird.
+ **console.log** — Das Konsolenprotokoll enthält alle Standardausgangsinformationen (stdout) und Standardfehlerinformationen (stderr), die in die Konsole AWSTOE geschrieben werden, während die Komponente ausgeführt wird.
+ **chaining.json** — Diese JSON-Datei stellt Optimierungen dar, die zur Auflösung von Verkettungsausdrücken angewendet wurden. AWSTOE
**Anmerkung**
Der Protokollordner kann auch andere temporäre Dateien enthalten, die hier nicht behandelt werden.
## Verkettung von Eingabe und Ausgabe
Die AWSTOE Konfigurationsverwaltungsanwendung bietet eine Funktion zum Verketten von Eingaben und Ausgaben, indem Verweise in den folgenden Formaten geschrieben werden:
`{{ phase_name.step_name.inputs/outputs.variable }}`
oder
`{{ phase_name.step_name.inputs/outputs[index].variable }}`
Mit der Verkettungsfunktion können Sie Code recyceln und die Wartbarkeit des Dokuments verbessern.
**Regeln für die Verkettung**
+ Verkettungsausdrücke können nur im Eingabebereich jedes Schritts verwendet werden.
+ Anweisungen mit verketteten Ausdrücken müssen in Anführungszeichen gesetzt werden. Beispiel:
+ **Ungültiger Ausdruck**: `echo {{ phase.step.inputs.variable }}`
+ **Gültiger Ausdruck**: `"echo {{ phase.step.inputs.variable }}"`
+ **Gültiger Ausdruck**: `'echo {{ phase.step.inputs.variable }}'`
+ Durch Verkettung von Ausdrücken können Variablen aus anderen Schritten und Phasen desselben Dokuments referenziert werden. Der aufrufende Dienst verfügt jedoch möglicherweise über Regeln, nach denen Verkettungsausdrücke nur im Kontext einer einzelnen Phase ausgeführt werden dürfen. Image Builder unterstützt beispielsweise keine Verkettung von der *Buildphase* zur *Testphase, da jede Phase* unabhängig ausgeführt wird.
+ Indizes in der Verkettung von Ausdrücken folgen einer nullbasierten Indizierung. Der Index beginnt mit Null (0), um auf das erste Element zu verweisen.
**Beispiele**
Um im zweiten Eintrag des folgenden Beispielschritts auf die Quellvariable zu verweisen, lautet `{{ build.SampleS3Download.inputs[1].source }}` das Verkettungsmuster.
```
phases:
- name: 'build'
steps:
- name: SampleS3Download
action: S3Download
timeoutSeconds: 60
onFailure: Abort
maxAttempts: 3
inputs:
- source: 's3://sample-bucket/sample1.ps1'
destination: 'C:\sample1.ps1'
- source: 's3://sample-bucket/sample2.ps1'
destination: 'C:\sample2.ps1'
```
Um auf die Ausgangsvariable (entspricht „Hello“) des folgenden Beispielschritts zu verweisen, lautet das Verkettungsmuster. `{{ build.SamplePowerShellStep.outputs.stdout }}`
```
phases:
- name: 'build'
steps:
- name: SamplePowerShellStep
action: ExecutePowerShell
timeoutSeconds: 120
onFailure: Abort
maxAttempts: 3
inputs:
commands:
- 'Write-Host "Hello"'
```
## Schema und Definitionen des Dokuments
Das Folgende ist das YAML-Schema für ein Dokument.
```
name: (optional)
description: (optional)
schemaVersion: "string"
phases:
- name: "string"
steps:
- name: "string"
action: "string"
timeoutSeconds: integer
onFailure: "Abort|Continue|Ignore"
maxAttempts: integer
inputs:
```
Die Schemadefinitionen für ein Dokument lauten wie folgt.
| Feld | Description | Typ | Erforderlich |
| --- | --- | --- | --- |
| Name | Name des Dokuments. | Zeichenfolge | Nein |
| description | Beschreibung des Dokuments. | Zeichenfolge | Nein |
| schemaVersion | Schemaversion des Dokuments, derzeit 1.0. | Zeichenfolge | Ja |
| phases | Eine Liste der Phasen mit ihren Schritten. | Auflisten | Ja |
Die Schemadefinitionen für eine Phase lauten wie folgt.
| Feld | Description | Typ | Erforderlich |
| --- | --- | --- | --- |
| Name | Name der Phase. | Zeichenfolge | Ja |
| steps | Liste der Schritte in der Phase. | Auflisten | Ja |
Die Schemadefinitionen für einen Schritt lauten wie folgt.
| Feld | Description | Typ | Erforderlich | Standardwert |
| --- | --- | --- | --- | --- |
| Name | Benutzerdefinierter Name für den Schritt. | Zeichenfolge | | |
| action | Schlüsselwort, das sich auf das Modul bezieht, das den Schritt ausführt. | Zeichenfolge | | |
| timeoutSeconds | Anzahl der Sekunden, die der Schritt ausgeführt wird, bevor er fehlschlägt oder es erneut versucht. Unterstützt auch den Wert -1, was auf ein unendliches Timeout hinweist. 0 und andere negative Werte sind nicht zulässig. | Ganzzahl | Nein | 7.200 Sekunden (120 Minuten) |
| onFailure | Gibt an, wie der Schritt im Falle eines Fehlers vorgehen soll. Gültige Werte sind: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/imagebuilder/latest/userguide/toe-use-documents.html) | Zeichenfolge | Nein | Abbrechen |
| maxAttempts | Höchstzahl zulässiger Versuche, bevor der Schritt fehlschlägt. | Ganzzahl | Nein | 1 |
| inputs | Enthält Parameter, die das Aktionsmodul benötigt, um den Schritt auszuführen. | Diktieren | Ja | |
## Beispiele für Dokumente
Die folgenden Beispiele zeigen AWSTOE Komponentendokumente, die Aufgaben für das Zielbetriebssystem ausführen.
------
#### [ Linux ]
**Beispiel 1: Führen Sie eine benutzerdefinierte Binärdatei aus**
Im Folgenden finden Sie ein Beispieldokument, das eine benutzerdefinierte Binärdatei herunterlädt und auf einer Linux-Instanz ausführt.
```
name: LinuxBin
description: Download and run a custom Linux binary file.
schemaVersion: 1.0
phases:
- name: build
steps:
- name: Download
action: S3Download
inputs:
- source: s3://amzn-s3-demo-source-bucket/myapplication
destination: /tmp/myapplication
- name: Enable
action: ExecuteBash
onFailure: Continue
inputs:
commands:
- 'chmod u+x {{ build.Download.inputs[0].destination }}'
- name: Install
action: ExecuteBinary
onFailure: Continue
inputs:
path: '{{ build.Download.inputs[0].destination }}'
arguments:
- '--install'
- name: Delete
action: DeleteFile
inputs:
- path: '{{ build.Download.inputs[0].destination }}'
```
------
#### [ Windows ]
**Beispiel 1: Installieren Sie Windows-Updates**
Das folgende Beispieldokument installiert alle verfügbaren Windows-Updates, führt ein Konfigurationsskript aus, überprüft die Änderungen, bevor das AMI erstellt wird, und testet die Änderungen, nachdem das AMI erstellt wurde.
```
name: RunConfig_UpdateWindows
description: 'This document will install all available Windows updates and run a config script. It will then validate the changes before an AMI is created. Then after AMI creation, it will test all the changes.'
schemaVersion: 1.0
phases:
- name: build
steps:
- name: DownloadConfigScript
action: S3Download
timeoutSeconds: 60
onFailure: Abort
maxAttempts: 3
inputs:
- source: 's3://customer-bucket/config.ps1'
destination: 'C:\config.ps1'
- name: RunConfigScript
action: ExecutePowerShell
timeoutSeconds: 120
onFailure: Abort
maxAttempts: 3
inputs:
file: '{{build.DownloadConfigScript.inputs[0].destination}}'
- name: Cleanup
action: DeleteFile
onFailure: Abort
maxAttempts: 3
inputs:
- path: '{{build.DownloadConfigScript.inputs[0].destination}}'
- name: RebootAfterConfigApplied
action: Reboot
inputs:
delaySeconds: 60
- name: InstallWindowsUpdates
action: UpdateOS
- name: validate
steps:
- name: DownloadTestConfigScript
action: S3Download
timeoutSeconds: 60
onFailure: Abort
maxAttempts: 3
inputs:
- source: 's3://customer-bucket/testConfig.ps1'
destination: 'C:\testConfig.ps1'
- name: ValidateConfigScript
action: ExecutePowerShell
timeoutSeconds: 120
onFailure: Abort
maxAttempts: 3
inputs:
file: '{{validate.DownloadTestConfigScript.inputs[0].destination}}'
- name: Cleanup
action: DeleteFile
onFailure: Abort
maxAttempts: 3
inputs:
- path: '{{validate.DownloadTestConfigScript.inputs[0].destination}}'
- name: test
steps:
- name: DownloadTestConfigScript
action: S3Download
timeoutSeconds: 60
onFailure: Abort
maxAttempts: 3
inputs:
- source: 's3://customer-bucket/testConfig.ps1'
destination: 'C:\testConfig.ps1'
- name: ValidateConfigScript
action: ExecutePowerShell
timeoutSeconds: 120
onFailure: Abort
maxAttempts: 3
inputs:
file: '{{test.DownloadTestConfigScript.inputs[0].destination}}'
```
**Beispiel 2: Installieren Sie das AWS CLI auf einer Windows-Instanz**
Im Folgenden finden Sie ein Beispieldokument, das mithilfe der Setup-Datei AWS CLI auf einer Windows-Instanz installiert wird.
```
name: InstallCLISetUp
description: Install &CLI; using the setup file
schemaVersion: 1.0
phases:
- name: build
steps:
- name: Download
action: S3Download
inputs:
- source: s3://aws-cli/AWSCLISetup.exe
destination: C:\Windows\temp\AWSCLISetup.exe
- name: Install
action: ExecuteBinary
onFailure: Continue
inputs:
path: '{{ build.Download.inputs[0].destination }}'
arguments:
- '/install'
- '/quiet'
- '/norestart'
- name: Delete
action: DeleteFile
inputs:
- path: '{{ build.Download.inputs[0].destination }}'
```
**Beispiel 3: Installieren Sie das AWS CLI mit dem MSI-Installationsprogramm**
Im Folgenden finden Sie ein Beispieldokument, das AWS CLI mit dem MSI-Installationsprogramm installiert wird.
```
name: InstallCLIMSI
description: Install &CLI; using the MSI installer
schemaVersion: 1.0
phases:
- name: build
steps:
- name: Download
action: S3Download
inputs:
- source: s3://aws-cli/AWSCLI64PY3.msi
destination: C:\Windows\temp\AWSCLI64PY3.msi
- name: Install
action: ExecuteBinary
onFailure: Continue
inputs:
path: 'C:\Windows\System32\msiexec.exe'
arguments:
- '/i'
- '{{ build.Download.inputs[0].destination }}'
- '/quiet'
- '/norestart'
- name: Delete
action: DeleteFile
inputs:
- path: '{{ build.Download.inputs[0].destination }}'
```
------
#### [ macOS ]
**Beispiel 1: Eine benutzerdefinierte macOS-Binärdatei ausführen**
Im Folgenden finden Sie ein Beispieldokument, das eine benutzerdefinierte Binärdatei herunterlädt und auf einer macOS-Instanz ausführt.
```
name: macOSBin
description: Download and run a binary file on macOS.
schemaVersion: 1.0
phases:
- name: build
steps:
- name: Download
action: S3Download
inputs:
- source: s3://amzn-s3-demo-source-bucket/myapplication
destination: /tmp/myapplication
- name: Enable
action: ExecuteBash
onFailure: Continue
inputs:
commands:
- 'chmod u+x {{ build.Download.inputs[0].destination }}'
- name: Install
action: ExecuteBinary
onFailure: Continue
inputs:
path: '{{ build.Download.inputs[0].destination }}'
arguments:
- '--install'
- name: Delete
action: DeleteFile
inputs:
- path: '{{ build.Download.inputs[0].destination }}'
```
------
# Verwenden Sie Variablen in Ihrem Dokument mit benutzerdefinierten Komponenten
Variablen bieten eine Möglichkeit, Daten mit aussagekräftigen Namen zu versehen, die in der gesamten Anwendung verwendet werden können. Sie können benutzerdefinierte Variablen mit einfachen und lesbaren Formaten für komplexe Workflows definieren und sie im YAML-Anwendungskomponentendokument für eine AWSTOE Komponente referenzieren.
Dieser Abschnitt enthält Informationen, die Ihnen helfen, Variablen für Ihre AWSTOE Komponente im Dokument für die YAML-Anwendungskomponente zu definieren, einschließlich Syntax, Namenseinschränkungen und Beispielen.
## Konstanten
Konstanten sind unveränderliche Variablen, die nach ihrer Definition nicht geändert oder überschrieben werden können. Konstanten können mithilfe von Werten im Abschnitt eines Dokuments definiert werden. `constants` AWSTOE
**Regeln für Konstantennamen**
+ Der Name muss zwischen 3 und 128 Zeichen lang sein.
+ Der Name darf nur alphanumerische Zeichen (a-z, A-Z, 0-9), Bindestriche (-) oder Unterstriche (\$1) enthalten.
+ Der Name muss innerhalb des Dokuments eindeutig sein.
+ Der Name muss als YAML-Zeichenfolge angegeben werden.
**Syntax**
```
constants:
- :
type:
value:
```
| Tastenname | Erforderlich | Beschreibung |
| --- | --- | --- |
| `name` | Ja | Name der Konstante. Muss für das Dokument eindeutig sein (er darf nicht mit anderen Parameternamen oder Konstanten identisch sein). |
| `value` | Ja | Wert der Konstante. |
| `type` | Ja | Typ der Konstante. Der unterstützte Typ iststring. |
**Verweisen Sie auf konstante Werte in einem Dokument**
Sie können in Step- oder Loop-Eingaben in Ihrem YAML-Dokument wie folgt auf Konstanten verweisen:
+ Bei konstanten Verweisen wird zwischen Groß- und Kleinschreibung unterschieden, und der Name muss exakt übereinstimmen.
+ Der Name muss in doppelte geschweifte Klammern eingeschlossen werden. `{{` *MyConstant* `}}`
+ Leerzeichen sind in geschweiften Klammern zulässig und werden automatisch gekürzt. Beispielsweise sind alle der folgenden Verweise gültig:
`{{ MyConstant }}`, `{{ MyConstant}}`, `{{MyConstant }}`, `{{MyConstant}}`
+ Der Verweis im YAML-Dokument muss als Zeichenfolge (in einfache oder doppelte Anführungszeichen eingeschlossen) angegeben werden.
Zum Beispiel: `- {{ MyConstant }}` ist nicht gültig, da es nicht als Zeichenfolge identifiziert wird.
Die folgenden Verweise sind jedoch beide gültig: `- '{{ MyConstant }}'` und`- "{{ MyConstant }}"`.
**Beispiele**
In Schritteingaben referenzierte Konstante
```
name: Download AWS CLI version 2
schemaVersion: 1.0
constants:
- Source:
type: string
value: https://awscli.amazonaws.com/AWSCLIV2.msi
phases:
- name: build
steps:
- name: Download
action: WebDownload
inputs:
- source: '{{ Source }}'
destination: 'C:\Windows\Temp\AWSCLIV2.msi'
```
In Loop-Eingängen wird auf eine Konstante verwiesen
```
name: PingHosts
schemaVersion: 1.0
constants:
- Hosts:
type: string
value: 127.0.0.1,amazon.com
phases:
- name: build
steps:
- name: Ping
action: ExecuteBash
loop:
forEach:
list: '{{ Hosts }}'
delimiter: ','
inputs:
commands:
- ping -c 4 {{ loop.value }}
```
## Parameters
Parameter sind veränderbare Variablen mit Einstellungen, die die aufrufende Anwendung zur Laufzeit bereitstellen kann. Sie können Parameter im `Parameters` Abschnitt des YAML-Dokuments definieren.
**Regeln für Parameternamen**
+ Der Name muss zwischen 3 und 128 Zeichen lang sein.
+ Der Name darf nur alphanumerische Zeichen (a-z, A-Z, 0-9), Bindestriche (-) oder Unterstriche (\$1) enthalten.
+ Der Name muss innerhalb des Dokuments eindeutig sein.
+ Der Name muss als YAML-Zeichenfolge angegeben werden.
### Syntax
```
parameters:
- :
type:
default:
description:
```
| Tastenname | Erforderlich | Beschreibung |
| --- | --- | --- |
| `name` | Ja | Der Name des Parameters. Muss für das Dokument eindeutig sein (er darf nicht mit anderen Parameternamen oder Konstanten identisch sein). |
| `type` | Ja | Der Datentyp des Parameters. Zu den unterstützten Typen gehören:`string`. |
| `default` | Nein | Der Standardwert für den Parameter. |
| `description` | Nein | Beschreibt den Parameter. |
### Referenzparameterwerte in einem Dokument
Sie können Parameter in Step- oder Loop-Eingaben innerhalb Ihres YAML-Dokuments wie folgt referenzieren:
+ Bei Parameterreferenzen wird zwischen Groß- und Kleinschreibung unterschieden, und der Name muss exakt übereinstimmen.
+ Der Name muss in doppelte geschweifte Klammern eingeschlossen werden. `{{` *MyParameter* `}}`
+ Leerzeichen sind in geschweiften Klammern zulässig und werden automatisch gekürzt. Beispielsweise sind alle der folgenden Verweise gültig:
`{{ MyParameter }}`, `{{ MyParameter}}`, `{{MyParameter }}`, `{{MyParameter}}`
+ Der Verweis im YAML-Dokument muss als Zeichenfolge (in einfache oder doppelte Anführungszeichen eingeschlossen) angegeben werden.
Zum Beispiel: `- {{ MyParameter }}` ist nicht gültig, da es nicht als Zeichenfolge identifiziert wird.
Die folgenden Verweise sind jedoch beide gültig: `- '{{ MyParameter }}'` und`- "{{ MyParameter }}"`.
**Beispiele**
Die folgenden Beispiele zeigen, wie Sie Parameter in Ihrem YAML-Dokument verwenden können:
+ Beziehen Sie sich auf einen Parameter in den Schritteingaben:
```
name: Download AWS CLI version 2
schemaVersion: 1.0
parameters:
- Source:
type: string
default: 'https://awscli.amazonaws.com/AWSCLIV2.msi'
description: The AWS CLI installer source URL.
phases:
- name: build
steps:
- name: Download
action: WebDownload
inputs:
- source: '{{ Source }}'
destination: 'C:\Windows\Temp\AWSCLIV2.msi'
```
+ Beziehen Sie sich auf einen Parameter in Loop-Eingängen:
```
name: PingHosts
schemaVersion: 1.0
parameters:
- Hosts:
type: string
default: 127.0.0.1,amazon.com
description: A comma separated list of hosts to ping.
phases:
- name: build
steps:
- name: Ping
action: ExecuteBash
loop:
forEach:
list: '{{ Hosts }}'
delimiter: ','
inputs:
commands:
- ping -c 4 {{ loop.value }}
```
### Parameter zur Laufzeit überschreiben
Sie können die `--parameters` Option AWS CLI mit einem Schlüssel-Wert-Paar verwenden, um zur Laufzeit einen Parameterwert festzulegen.
+ Geben Sie das Schlüssel-Wert-Paar für den Parameter als Namen und Wert an, getrennt durch ein Gleichheitszeichen (=).
+ Mehrere Parameter müssen durch ein Komma getrennt werden.
+ Parameternamen, die im YAML-Komponentendokument nicht gefunden werden, werden ignoriert.
+ Der Parametername und der Wert sind beide erforderlich.
**Wichtig**
Bei den Komponentenparametern handelt es sich um reine Textwerte, die angemeldet sind AWS CloudTrail. Wir empfehlen, dass Sie AWS Secrets Manager oder den AWS Systems Manager Parameter Store verwenden, um Ihre Geheimnisse zu speichern. Weitere Informationen zu Secrets Manager finden Sie unter [Was ist Secrets Manager?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) im *AWS Secrets Manager Benutzerhandbuch*. Weitere Informationen zum AWS Systems Manager Parameterspeicher finden Sie unter [AWS Systems Manager Parameterspeicher](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) im *AWS Systems Manager Benutzerhandbuch*.
#### Syntax
```
--parameters name1=value1,name2=value2...
```
| CLI-Option | Erforderlich | Description |
| --- | --- | --- |
| --parameter *name* =*value*,... | Nein | Diese Option verwendet eine Liste von Schlüssel-Wert-Paaren mit dem Parameternamen als Schlüssel. |
**Beispiele**
Die folgenden Beispiele zeigen, wie Sie Parameter in Ihrem YAML-Dokument verwenden können:
+ Das in dieser `--parameter` Option angegebene Parameter-Schlüssel-Wert-Paar ist nicht gültig:
```
--parameters ntp-server=
```
+ Legen Sie ein Parameter-Schlüssel-Wert-Paar mit der `--parameter` folgenden Option fest: AWS CLI
```
--parameters ntp-server=ntp-server-windows-qe.us-east1.amazon.com
```
+ Legen Sie mehrere Parameter-Schlüssel-Wert-Paare mit der Option im `--parameter` Feld fest: AWS CLI
```
--parameters ntp-server=ntp-server.amazon.com,http-url=https://internal-us-east1.amazon.com
```
## Verwenden Sie die Parameter Store-Parameter von Systems Manager
Sie können AWS Systems Manager Parameter Store-Parameter (SSM-Parameter) in Ihren Komponentendokumenten referenzieren, indem Sie Variablen das Präfix voranstellen. `aws:ssm` Zum Beispiel
`{{ aws:ssm:/my/param }}`wird in den Wert des SSM-Parameters aufgelöst. `/my/param`
Diese Funktion unterstützt die folgenden SSM-Parametertypen:
+ Zeichenfolge — Ordnet dem AWSTOE String-Typ zu.
+ StringList — Ordnet dem AWSTOE `stringList` Typ zu.
+ SecureString — Ordnet dem AWSTOE String-Typ zu.
Weitere Informationen zum Parameterspeicher finden Sie unter [AWS Systems Manager Parameterspeicher](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) im *AWS Systems Manager Benutzerhandbuch*.
Sie können auch mithilfe eines SSM-Parameters `SecureString` auf AWS Secrets Manager Geheimnisse verweisen. Beispiel: `{{ aws:ssm:/aws/reference/secretsmanager/test/test-secret }}`. Weitere Informationen finden Sie unter [Referenzieren von AWS Secrets Manager Geheimnissen aus Parameterspeicher-Parametern](https://docs.aws.amazon.com/systems-manager/latest/userguide/integration-ps-secretsmanager.html).
**Wichtig**
Image Builder schließt die `SecureString` Parameterauflösung aus seinen Protokollen aus. Sie sind jedoch auch dafür verantwortlich, sicherzustellen, dass vertrauliche Informationen nicht über Befehle protokolliert werden, die im Komponentendokument ausgegeben werden. Wenn Sie den `echo` Befehl beispielsweise mit einer sicheren Zeichenfolge verwenden, schreibt der Befehl einen Klartextwert in das Protokoll.
### Erforderliche IAM-Berechtigungen
Um Systems Manager Manager-Parameter in Ihren Komponenten verwenden zu können, muss Ihre Instanzrolle über die `ssm:GetParameter` Berechtigung für die Parameterressource ARN verfügen. Beispiel:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ssm:GetParameter",
"Resource": "arn:aws:ssm:*:111122223333:parameter/ImageBuilder-*"
}
]
}
```
------
Für den Zugriff auf verschlüsselte Werte benötigen Sie außerdem die folgenden Berechtigungen:
+ Fügen Sie `kms:Decrypt` `SecureString` Parameter oder AWS Secrets Manager Werte hinzu, die verschlüsselt sind und von einem Kunden verwaltet werden AWS KMS key.
+ Fügen Sie hinzu`secretsmanager:GetSecretValue`, wenn Sie auf ein Secrets Manager Manager-Geheimnis verweisen.
### Verweisen Sie in einem Komponentendokument auf einen SSM-Parameter
Das folgende Beispiel zeigt, wie auf einen Systems Manager Parameter Store-Parameter von Systems Manager Manager-Parametern in einer Komponente verwiesen wird:
```
name: UseSSMParameterVariable
description: This is a sample component document that prints out the value of an SSM Parameter. Never do this for a SecureString parameter.
schemaVersion: 1.0
phases:
- name: verify
steps:
- name: EchoParameterValue
action: ExecuteBash
inputs:
commands:
- echo "Log SSM parameter name: /my/test/param, value {{ aws:ssm:/my/test/param }}."
```
### Dynamische Auflösung von Laufzeitvariablen für SSM-Parameter
AWSTOE stellt die folgende integrierte Funktion bereit, die Sie innerhalb von Variablenreferenzen verwenden können, um Werte zur Laufzeit zu manipulieren oder zu transformieren.
#### Funktion auflösen
Die `resolve` Funktion löst eine Variablenreferenz innerhalb einer anderen Variablenreferenz auf und ermöglicht so eine dynamische Referenzierung von Variablennamen. Dies ist nützlich, wenn Sie mit SSM-Parametern arbeiten, bei denen ein Teil des Parameterpfads variabel sein und als Dokumentparameter übergeben werden kann.
Die `resolve` Funktion unterstützt nur die dynamische Auflösung des Namensteils eines SSM-Parameters.
##### Syntax
Das `dynamic_variable` folgende Beispiel stellt den Namen eines SSM-Parameters dar und muss einer der folgenden sein:
+ Eine SSM-Parameterreferenz (zum Beispiel) `aws:ssm:/my/param`
+ Eine Parameterreferenz für ein Komponentendokument (z. B.`parameter-name`)
```
{{ aws:ssm:resolve(dynamic_variable) }}
```
##### Beispiel: Einen SSM-Parameter zur Laufzeit auflösen
Das folgende Beispiel zeigt, wie die `resolve` Funktion in einem YAML-Komponentendokument verwendet wird:
```
name: SsmParameterTest
description: This component verifies an SSM parameter variable reference with the echo command.
schemaVersion: 1.0
parameters:
- parameter-name:
type: string
description: "test"
phases:
- name: validate
steps:
- name: PrintDynamicVariable
action: ExecuteBash
inputs:
commands:
- echo "{{ aws:ssm:resolve(parameter-name) }}"
```
# Verwenden Sie bedingte Konstrukte in AWSTOE
Bedingte Konstrukte führen unterschiedliche Aktionen in Ihrem Komponentendokument aus, je nachdem, ob der angegebene bedingte Ausdruck als oder ausgewertet wird. `true` `false` Sie können das `if` Konstrukt verwenden, um den Ausführungsablauf in Ihrem Komponentendokument zu steuern.
## wenn Konstrukt
Sie können das `if` Konstrukt verwenden, um zu bewerten, ob ein Schritt ausgeführt werden soll oder nicht. Standardmäßig wird der Schritt AWSTOE ausgeführt, wenn der `if` bedingte Ausdruck zu ausgewertet wird`true`, und wenn die Bedingung zu ausgewertet wird`false`, wird der Schritt AWSTOE übersprungen. Wenn ein Schritt übersprungen wird, wird er bei der AWSTOE Bewertung, ob die Phase und das Dokument erfolgreich ausgeführt wurden, als erfolgreicher Schritt behandelt.
**Anmerkung**
Eine `if` Anweisung wird nur einmal ausgewertet, auch wenn der Schritt einen Neustart auslöst. Wenn ein Schritt neu gestartet wird, erkennt er, dass die `if` Anweisung bereits ausgewertet wurde, und setzt dort fort, wo sie aufgehört hat.
### Syntax
```
if:
- :
[then: ]
[else: ]
```
| Tastenname | Erforderlich | Description |
| --- | --- | --- |
| bedingter Ausdruck | Ja | Der bedingte Ausdruck kann genau einen der folgenden Typen von Operatoren auf oberster Ebene enthalten. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/imagebuilder/latest/userguide/toe-conditional-constructs.html) Wenn Ihr Ausdruck mehrere Bedingungen erfüllen muss, verwenden Sie einen logischen Operator, um Ihre Bedingungen anzugeben. |
| then | Nein | Definiert die Aktion, die ausgeführt werden soll, wenn der bedingte Ausdruck zu `true` ausgewertet wird. |
| else | Nein | Definiert die Aktion, die ausgeführt werden soll, wenn der bedingte Ausdruck als Ergebnis ausgewertet wird. `false` |
| Schritt, Aktion | Bedingt | Wenn Sie `then` oder verwenden`else`, müssen Sie eine der folgenden Schrittaktionen angeben: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/imagebuilder/latest/userguide/toe-conditional-constructs.html) |
**Beispiel 1: Paket installieren**
In den folgenden Beispielschritten aus einem AWSTOE Komponentendokument werden logische Operatoren verwendet, um einen Parameterwert zu testen und die entsprechenden Paketmanager-Befehle auszuführen, um eine Anwendung zu installieren, falls das Paket entpackt ist.
```
- name: InstallUnzipAptGet
action: ExecuteBash
if:
and:
- binaryExists: 'apt-get'
- not:
binaryExists: 'unzip'
inputs:
commands:
- sudo apt-get update
- sudo apt-get install -y unzip
- name: InstallUnzipYum
action: ExecuteBash
if:
and:
- binaryExists: 'yum'
- not:
binaryExists: 'unzip'
inputs:
commands:
- sudo yum install -y unzip
- name: InstallUnzipZypper
action: ExecuteBash
if:
and:
- binaryExists: 'zypper'
- not:
binaryExists: 'unzip'
inputs:
commands:
- sudo zypper refresh
- sudo zypper install -y unzip
```
**Beispiel 2: Einen Schritt überspringen**
Das folgende Beispiel zeigt zwei Möglichkeiten, einen Schritt zu überspringen. Einer verwendet einen logischen Operator, und einer verwendet einen Vergleichsoperator mit der `Skip` Schrittaktion.
```
# Creates a file if it does not exist using not
- name: CreateMyConfigFile-1
action: ExecuteBash
if:
not:
fileExists: '/etc/my_config'
inputs:
commands:
- echo "Hello world" > '/etc/my_config'
# Creates a file if it does not exist using then and else
- name: CreateMyConfigFile-2
action: ExecuteBash
if:
fileExists: '/etc/my_config'
then: Skip
else: Execute
inputs:
commands:
- echo "Hello world" > '/etc/my_config'
```
# Verwenden Sie Vergleichsoperatoren in AWSTOE Komponentendokumenten
Sie können die folgenden Vergleichsoperatoren mit dem **[Bestätigen](toe-action-modules.md#action-modules-assertion)** Aktionsmodul und mit bedingten Ausdrücken verwenden, die den verwenden[wenn KonstruktSyntax](toe-conditional-constructs.md#toe-conditional-if). Ein Vergleichsoperator kann beispielsweise `stringIsEmpty` mit einem einzelnen Wert arbeiten oder einen Basiswert mit einem zweiten Wert (Variablenwert) vergleichen, um festzustellen, ob der bedingte Ausdruck als `true` oder `false` ausgewertet wird.
Wenn der Vergleich auf zwei Werten basiert, kann der zweite Wert eine verkettete Variable sein.
Beim Vergleich von Werten eines anderen Typs können vor dem Vergleich die folgenden Wertekonvertierungen erfolgen:
+ Wenn der Variablenwert bei numerischen Vergleichen eine Zeichenfolge ist, wird die Zeichenfolge vor der Auswertung in eine Zahl AWSTOE umgewandelt. Wenn die Konvertierung nicht möglich ist, kehrt der Vergleich zurück`false`. Wenn der Variablenwert beispielsweise ist`"1.0"`, funktioniert die Konvertierung, aber wenn der Variablenwert ist, schlägt `"a10"` die Konvertierung fehl.
+ Wenn der Variablenwert bei Zeichenkettenvergleichen eine Zahl ist, wird er vor der Auswertung in eine Zeichenfolge AWSTOE umgewandelt.
## Vergleiche Zeichenketten
Die folgenden Vergleichsoperatoren verwenden Zeichenketten, um Werte zu vergleichen, auf Leerzeichen oder eine leere Zeichenfolge zu testen oder einen Eingabewert mit einem Regex-Muster zu vergleichen. Bei Zeichenfolgenvergleichen wird nicht zwischen Groß- und Kleinschreibung unterschieden und Leerzeichen am Anfang oder Ende der Zeichenketteneingaben werden nicht gekürzt.
**Operatoren zum Vergleich von Zeichenketten**
+ [stringIsEmpty](#stringIsEmpty)
+ [stringIsWhitespace](#stringIsWhitespace)
+ [stringEquals](#stringEquals)
+ [stringLessThan](#stringLessThan)
+ [stringLessThanEquals](#stringLessThanEquals)
+ [stringGreaterThan](#stringGreaterThan)
+ [stringGreaterThanEquals](#stringGreaterThanEquals)
+ [patternMatches](#patternMatches)
**stringIsEmpty**
Der `stringIsEmpty` Operator kehrt zurück, `true` wenn die angegebene Zeichenfolge keine Zeichen enthält. Beispiel:
```
# Evaluates to true
stringIsEmpty: ""
# Evaluates to false
stringIsEmpty: " "
# Evaluates to false
stringIsEmpty: "Hello."
```
**stringIsWhitespace**
Testet, ob die für angegebene Zeichenfolge nur Leerzeichen `stringIsWhitespace` enthält. Beispiel:
```
# Evaluates to true
stringIsWhitespace: " "
# Evaluates to false
stringIsWhitespace: ""
# Evaluates to false
stringIsWhitespace: " Hello?"
```
**Zeichenfolge ist gleich**
Testet, ob die für `stringEquals` angegebene Zeichenfolge exakt mit der im Parameter angegebenen Zeichenfolge übereinstimmt. `value` Beispiel:
```
# Evaluates to true
stringEquals: 'Testing, testing...'
value: 'Testing, testing...'
# Evaluates to false
stringEquals: 'Testing, testing...'
value: 'Hello again.'
# Evaluates to false
stringEquals: 'Testing, testing...'
value: 'TESTING, TESTING....'
# Evaluates to false
stringEquals: 'Testing, testing...'
value: ' Testing, testing...'
# Evaluates to false
stringEquals: 'Testing, testing...'
value: 'Testing, testing... '
```
**stringLessThan**
Testet, ob die für angegebene Zeichenfolge kleiner als die im `value` Parameter angegebene Zeichenfolge `stringLessThan` ist. Beispiel:
```
# Evaluates to true
# This comparison operator isn't case sensitive
stringlessThan: 'A'
value: 'a'
# Evaluates to true - 'a' is less than 'b'
stringlessThan: 'b'
value: 'a'
# Evaluates to true
# Numeric strings compare as less than alphabetic strings
stringlessThan: 'a'
value: '0'
# Evaluates to false
stringlessThan: '0'
value: 'a'
```
**stringLessThanEntspricht**
Testet, ob die für angegebene Zeichenfolge kleiner oder gleich der im `value` Parameter angegebenen Zeichenfolge `stringLessThanEquals` ist. Beispiel:
```
# Evaluates to true - 'a' is equal to 'a'
stringLessThanEquals: 'a'
value: 'a'
# Evaluates to true - since the comparison isn't case sensitive, 'a' is equal to 'A'
stringLessThanEquals: 'A'
value: 'a'
# Evaluates to true - 'a' is less than 'b'
stringLessThanEquals: 'b'
value: 'a'
# Evaluates to true - '0' is less than 'a'
stringLessThanEquals: 'a'
value: '0'
# Evaluates to false - 'a' is greater than '0'
stringLessThanEquals: '0'
value: 'a'
```
**stringGreaterThan**
Testet, ob die für angegebene Zeichenfolge größer als die im `value` Parameter angegebene Zeichenfolge `stringGreaterThan` ist. Beispiel:
```
# Evaluates to false - since the comparison isn't case sensitive, 'A' is equal to 'a'
stringGreaterThan: 'a'
value: 'A'
# Evaluates to true - 'b' is greater than 'a'
stringGreaterThan: 'a'
value: 'b'
# Evaluates to true - 'a' is greater than '0'
stringGreaterThan: '0'
value: 'a'
# Evaluates to false - '0' is less than 'a'
stringGreaterThan: 'a'
value: '0'
```
**stringGreaterThanEntspricht**
Testet, ob die für angegebene Zeichenfolge größer oder gleich der im `value` Parameter angegebenen Zeichenfolge `stringGreaterThanEquals` ist. Beispiel:
```
# Evaluates to true - 'a' is equal to 'A'
stringGreaterThanEquals: 'A'
value: 'a'
# Evaluates to true - 'b' is greater than 'a'
stringGreaterThanEquals: 'a'
value: 'b'
# Evaluates to true - 'a' is greater than '0'
stringGreaterThanEquals: '0'
value: 'a'
# Evaluates to false - '0' is less than 'a'
stringGreaterThanEquals: 'a'
value: '0'
```
**PatternMatches**
Testet, ob die im `value` Parameter angegebene Zeichenfolge mit dem für angegebenen Regex-Muster übereinstimmt. `patternMatches` Der Vergleich verwendet das [Golang-Regexp-Paket, das](https://pkg.go.dev/regexp) der Syntax entspricht. RE2 Weitere Informationen zu RE2 Regeln finden Sie im [google/re2-Repository](https://github.com/google/re2/wiki/Syntax) unter. *GitHub*
Das folgende Beispiel zeigt eine Musterübereinstimmung, die Folgendes zurückgibt`true`:
```
patternMatches: '^[a-z]+$'
value: 'ThisIsValue'
```
## Zahlen vergleichen
Die folgenden Vergleichsoperatoren arbeiten mit Zahlen. Bei den für diese Operatoren bereitgestellten Werte muss es sich gemäß der YAML-Spezifikation um einen der folgenden Typen handeln. Die Support für numerische Vergleiche verwendet den Golang Big Package Comparison Operator, zum Beispiel: [func (\$1Float](https://pkg.go.dev/math/big#Float.Cmp)) Cmp.
+ Ganzzahl
+ Float (basiert auf float64, das Zahlen von -1.7e\$1308 bis \$11.7e\$1308 unterstützt)
+ Eine Zeichenfolge, die dem folgenden Regex-Muster entspricht: `^[-+]?([0-9]+[.])?[0-9]+$`
**Operatoren für den Zahlenvergleich**
+ [numberEquals](#numberEquals)
+ [numberLessThan](#numberLessThan)
+ [numberLessThanEquals](#numberLessThanEquals)
+ [numberGreaterThan](#numberGreaterThan)
+ [numberGreaterThanEquals](#numberGreaterThanEquals)
**Zahl ist gleich**
Testet, ob die für `numberEquals` angegebene Zahl der im Parameter angegebenen Zahl entspricht. `value` Alle folgenden Beispielvergleiche geben Folgendes zurück`true`:
```
# Values provided as a positive number
numberEquals: 1
value: 1
# Comparison value provided as a string
numberEquals: '1'
value: 1
# Value provided as a string
numberEquals: 1
value: '1'
# Values provided as floats
numberEquals: 5.0
value: 5.0
# Values provided as a negative number
numberEquals: -1
value: -1
```
**numberLessThan**
Testet, ob die für angegebene Zahl kleiner als die im `value` Parameter angegebene Zahl `numberLessThan` ist. Beispiel:
```
# Evaluates to true
numberLessThan: 2
value: 1
# Evaluates to true
numberLessThan: 2
value: 1.9
# Evaluates to false
numberLessThan: 2
value: '2'
```
**numberLessThanEntspricht**
Testet, ob die für angegebene Zahl kleiner oder gleich der im `value` Parameter angegebenen Zahl `numberLessThanEquals` ist. Beispiel:
```
# Evaluates to true
numberLessThanEquals: 2
value: 1
# Evaluates to true
numberLessThanEquals: 2
value: 1.9
# Evaluates to true
numberLessThanEquals: 2
value: '2'
# Evaluates to false
numberLessThanEquals: 2
value: 2.1
```
**numberGreaterThan**
Testet, ob die für angegebene Zahl größer als die im `value` Parameter angegebene Zahl `numberGreaterThan` ist. Beispiel:
```
# Evaluates to true
numberGreaterThan: 1
value: 2
# Evaluates to true
numberGreaterThan: 1
value: 1.1
# Evaluates to false
numberGreaterThan: 1
value: '1'
```
**numberGreaterThanEntspricht**
Testet, ob die für angegebene Zahl größer oder gleich der im `value` Parameter angegebenen Zahl `numberGreaterThanEquals` ist. Beispiel:
```
# Evaluates to true
numberGreaterThanEquals: 1
value: 2
# Evaluates to true
numberGreaterThanEquals: 1
value: 1.1
# Evaluates to true
numberGreaterThanEquals: 1
value: '1'
# Evaluates to false
numberGreaterThanEquals: 1
value: 0.8
```
## Überprüfen Sie die Dateien
Die folgenden Vergleichsoperatoren überprüfen den Datei-Hash oder prüfen, ob eine Datei oder ein Ordner existiert.
**Datei- und Ordneroperatoren**
+ [binaryExists](#binaryExists)
+ [fileExists](#fileExists)
+ [folderExists](#folderExists)
+ [fileMD5Equals](#fileMD5Equals)
+ [fileSHA1Equals](#fileSHA1Equals)
+ [fileSHA256Equals](#fileSHA256Equals)
+ [fileSHA512Equals](#fileSHA512Equals)
**Binärdatei existiert**
Testet, ob eine Anwendung im aktuellen Pfad verfügbar ist. Beispiel:
```
binaryExists: 'foo'
```
Auf Linux- und macOS-Systemen funktioniert dies für eine Anwendung mit dem Namen *foo* genauso wie der folgende Bash-Befehl:**type *foo* >/dev/null 2>&1**, wobei **\$1? == 0** auf einen erfolgreichen Vergleich hinweist.
Auf Windows-Systemen funktioniert dies für eine Anwendung mit dem Namen genauso wie der PowerShell Befehl *foo***& C:\$1Windows\$1System32\$1where.exe /Q *foo***, der **\$1LASTEXITCODE = 0** auf einen erfolgreichen Vergleich hinweist.
**Die Datei ist vorhanden**
Testet, ob eine Datei im angegebenen Pfad existiert. Sie können einen absoluten oder relativen Pfad angeben. Wenn der von Ihnen angegebene Speicherort existiert und es sich um `true` eine Datei handelt, ergibt der Vergleich Folgendes: Beispiel:
```
fileExists: '/path/to/file'
```
Auf Linux- und macOS-Systemen funktioniert dies genauso wie der folgende Bash-Befehl:**-d */path/to/file***, wobei **\$1? == 0** auf einen erfolgreichen Vergleich hinweist.
Auf Windows-Systemen funktioniert das genauso wie der PowerShell Befehl**Test-Path -Path '*C:\$1path\$1to\$1file*' -PathType 'Leaf'**.
**Ordner ist vorhanden**
Testet, ob ein Ordner im angegebenen Pfad existiert. Sie können einen absoluten oder relativen Pfad angeben. Wenn der von Ihnen angegebene Speicherort vorhanden ist und es sich um `true` einen Ordner handelt, ergibt der Vergleich Folgendes: Beispiel:
```
folderExists: '/path/to/folder'
```
Auf Linux- und macOS-Systemen funktioniert dies genauso wie der folgende Bash-Befehl:**-d */path/to/folder***, wobei **\$1? == 0** auf einen erfolgreichen Vergleich hinweist.
Auf Windows-Systemen funktioniert das genauso wie der PowerShell Befehl**Test-Path -Path '*C:\$1path\$1to\$1folder*' -PathType 'Container'**.
**Datei MD5 ist gleich**
Testet, ob der MD5 Hash einer Datei einem bestimmten Wert entspricht. Beispiel:
```
fileMD5Equals: ''
path: '/path/to/file'
```
**Datei SHA1 ist gleich**
Testet, ob der SHA1 Hash einer Datei einem bestimmten Wert entspricht. Beispiel:
```
fileSHA1Equals: ''
path: '/path/to/file'
```
**Datei SHA256 ist gleich**
Testet, ob der SHA256 Hash einer Datei einem bestimmten Wert entspricht. Beispiel:
```
fileSHA256Equals: ''
path: '/path/to/file'
```
**Datei SHA512 ist gleich**
Testet, ob der SHA512 Hash einer Datei einem bestimmten Wert entspricht. Beispiel:
```
fileSHA512Equals: ''
path: '/path/to/file'
```
# Verwenden Sie logische Operatoren in AWSTOE Komponentendokumenten
Sie können die folgenden logischen Operatoren verwenden, um bedingte Ausdrücke in Ihrem Komponentendokument hinzuzufügen oder zu ändern. AWSTOE wertet bedingte Ausdrücke in der Reihenfolge aus, in der die Bedingungen angegeben sind. Weitere Hinweise zu Vergleichsoperatoren für Komponentendokumente finden Sie unter[Verwenden Sie Vergleichsoperatoren in AWSTOE Komponentendokumenten](toe-comparison-operators.md).
**und**
Mit dem `and` Operator können Sie zwei oder mehr Vergleiche als einen einzigen Ausdruck auswerten. Der Ausdruck wird ausgewertet, `true` wenn alle Bedingungen in der Liste erfüllt sind. Andernfalls wird der Ausdruck zu ausgewertet. `false`
**Beispiele:**
Im folgenden Beispiel werden zwei Vergleiche durchgeführt — eine Zeichenfolge und eine Zahl. Beide Vergleiche sind wahr, sodass der Ausdruck als wahr ausgewertet wird.
```
and:
- stringEquals: 'test_string'
value: 'test_string'
- numberEquals: 1
value: 1
```
Im folgenden Beispiel werden auch zwei Vergleiche durchgeführt. Der erste Vergleich ist falsch. An diesem Punkt stoppt die Auswertung und der zweite Vergleich wird übersprungen. Der Ausdruck wird zu ausgewertet. `false`
```
and:
- stringEquals: 'test_string'
value: 'Hello world!'
- numberEquals: 1
value: 1
```
**oder**
Mit dem `or` Operator können Sie zwei oder mehr Vergleiche als einen einzigen Ausdruck auswerten. Der Ausdruck wird ausgewertet, `true` wenn einer der angegebenen Vergleiche wahr ist. Wenn keiner der angegebenen Vergleiche als Ergebnis ausgewertet wird`true`, wird der Ausdruck als ausgewertet. `false`
**Beispiele:**
Im folgenden Beispiel werden zwei Vergleiche durchgeführt — eine Zeichenfolge und eine Zahl. Der erste Vergleich ist wahr, daher wird der Ausdruck zu ausgewertet `true` und der zweite Vergleich wird übersprungen.
```
or:
- stringEquals: 'test_string'
value: 'test_string'
- numberEquals: 1
value: 3
```
Im folgenden Beispiel werden auch zwei Vergleiche durchgeführt. Der erste Vergleich ist falsch, und die Auswertung wird fortgesetzt. Der zweite Vergleich ist wahr, daher wird der Ausdruck zu `true` ausgewertet.
```
or:
- stringEquals: 'test_string'
value: 'Hello world!'
- numberEquals: 1
value: 1
```
Im letzten Beispiel sind beide Vergleiche falsch, sodass der Ausdruck zu ausgewertet wird. `false`
```
or:
- stringEquals: 'test_string'
value: 'Hello world!'
- numberEquals: 1
value: 3
```
**nicht**
Mit dem `not` Operator können Sie einen einzelnen Vergleich negieren. Der Ausdruck ergibt, `true` ob der Vergleich falsch ist. Wenn der Vergleich wahr ist, wird der Ausdruck zu ausgewertet. `false`
**Beispiele:**
Im folgenden Beispiel wird ein Zeichenkettenvergleich durchgeführt. Der Vergleich ist falsch, daher wird der Ausdruck zu `true` ausgewertet.
```
not:
- stringEquals: 'test_string'
value: 'Hello world!'
```
Im folgenden Beispiel wird auch ein Zeichenfolgenvergleich durchgeführt. Der Vergleich ist wahr, daher wird der Ausdruck zu `false` ausgewertet.
```
not:
- stringEquals: 'test_string'
value: 'test_string'
```
# Verwenden Sie Looping-Konstrukte in AWSTOE
Dieser Abschnitt enthält Informationen, die Ihnen beim Erstellen von Schleifenkonstrukten in der helfen sollen. AWSTOE Schleifenkonstrukte definieren eine sich wiederholende Abfolge von Befehlen. Sie können die folgenden Typen von Schleifenkonstrukten verwenden in: AWSTOE
+ `for`Konstrukte — Iterieren Sie über eine begrenzte Folge von ganzen Zahlen.
+ `forEach`Konstrukte
+ `forEach`Schleife mit Eingabeliste — Iteriert über eine endliche Sammlung von Zeichenketten.
+ `forEach`Schleife mit begrenzter Liste — Iteriert über eine endliche Sammlung von Zeichenketten, die durch ein Trennzeichen verbunden sind.
**Anmerkung**
Schleifenkonstrukte unterstützen nur Zeichenkettendatentypen.
**Topics**
+ [Referenz-Iterationsvariablen](#toe-loop-iteration-variables)
+ [Arten von Looping-Konstrukten](#toe-loop-types)
+ [Felder für Schritte](#toe-loop-step-fields)
+ [Ausgaben für Schritt und Iteration](#toe-loop-step-output)
## Referenz-Iterationsvariablen
Um auf den Index und den Wert der aktuellen Iterationsvariablen zu verweisen, `{{ loop.* }}` muss der Referenzausdruck im Eingabekörper eines Schritts verwendet werden, der ein Schleifenkonstrukt enthält. Dieser Ausdruck kann nicht verwendet werden, um auf die Iterationsvariablen des Schleifenkonstrukts eines anderen Schritts zu verweisen.
Der Referenzausdruck besteht aus den folgenden Elementen:
+ `{{ loop.index }}`— Die Ordinalposition der aktuellen Iteration, die indexiert ist. `0`
+ `{{ loop.value }}`— Der Wert, der der aktuellen Iterationsvariablen zugeordnet ist.
### Namen von Schleifen
Alle Schleifenkonstrukte haben ein optionales Namensfeld zur Identifizierung. Wenn ein Schleifenname angegeben wird, kann er verwendet werden, um auf Iterationsvariablen im Eingabekörper des Schritts zu verweisen. Um auf die Iterationsindizes und Werte einer benannten Schleife zu verweisen, verwenden Sie `{{ .* }}` with `{{ loop.* }}` im Eingabebereich des Schritts. Dieser Ausdruck kann nicht verwendet werden, um auf das benannte Schleifenkonstrukt eines anderen Schritts zu verweisen.
Der Referenzausdruck besteht aus den folgenden Elementen:
+ `{{ .index }}`— Die Ordinalposition der aktuellen Iteration der benannten Schleife, die indexiert ist. `0`
+ `{{ .value }}`— Der Wert, der der aktuellen Iterationsvariablen der benannten Schleife zugeordnet ist.
### Referenzausdrücke auflösen
Der AWSTOE löst Referenzausdrücke wie folgt auf:
+ `{{ .* }}`— AWSTOE löst diesen Ausdruck mit der folgenden Logik auf:
+ Wenn die Schleife des aktuell laufenden Schritts mit dem `` Wert übereinstimmt, wird der Referenzausdruck in das Schleifenkonstrukt des aktuell laufenden Schritts aufgelöst.
+ ``wird in das benannte Schleifenkonstrukt aufgelöst, wenn es im aktuell laufenden Schritt vorkommt.
+ `{{ loop.* }}`— AWSTOE löst den Ausdruck unter Verwendung des Schleifenkonstrukts auf, das im aktuell ausgeführten Schritt definiert wurde.
Wenn Referenzausdrücke innerhalb eines Schritts verwendet werden, der keine Schleife enthält, werden die Ausdrücke AWSTOE nicht aufgelöst und sie erscheinen im Schritt ohne Ersatz.
**Anmerkung**
Referenzausdrücke müssen in doppelte Anführungszeichen eingeschlossen werden, damit sie vom YAML-Compiler korrekt interpretiert werden.
## Arten von Looping-Konstrukten
Dieser Abschnitt enthält Informationen und Beispiele zu Schleifenkonstrukttypen, die in der verwendet werden können. AWSTOE
**Topics**
+ [`for`Schleife](#toe-loop-types-for)
+ [`forEach`Schleife mit Eingabeliste](#toe-loop-types-foreach)
+ [`forEach`Schleife mit begrenzter Liste](#toe-loop-types-foreach-delimited)
### `for`Schleife
Die `for` Schleife iteriert über einen Bereich von ganzen Zahlen, die innerhalb einer Grenze angegeben sind, die durch den Anfang und das Ende der Variablen umrissen wird. Die iterierenden Werte befinden sich in der Menge `[start, end]` und enthalten Grenzwerte.
AWSTOE überprüft die `updateBy` Werte`start`, und`end`, um sicherzustellen, dass die Kombination nicht zu einer Endlosschleife führt.
`for`Schleifenschema
```
- name: "StepName"
action: "ActionModule"
loop:
name: "string"
for:
start: int
end: int
updateBy: int
inputs:
...
```
**`for`Schleifeneingabe**
| Feld | Description | Typ | Erforderlich | Standard |
| --- | --- | --- | --- | --- |
| `name` | Eindeutiger Name der Schleife. Er muss im Vergleich zu anderen Schleifennamen in derselben Phase eindeutig sein. | Zeichenfolge | Nein | "" |
| `start` | Startwert der Iteration. Akzeptiert keine Verkettung von Ausdrücken. | Ganzzahl | Ja | – |
| `end` | Endwert der Iteration. Akzeptiert keine Verkettung von Ausdrücken. | Ganzzahl | Ja | – |
| `updateBy` | Unterschied, um den ein iterierender Wert durch Addition aktualisiert wird. Es muss ein negativer oder positiver Wert ungleich Null sein. Akzeptiert keine Verkettung von Ausdrücken. | Ganzzahl | Ja | – |
`for`Beispiel für eine Schleifeneingabe
```
- name: "CalculateFileUploadLatencies"
action: "ExecutePowerShell"
loop:
for:
start: 100000
end: 1000000
updateBy: 100000
inputs:
commands:
- |
$f = new-object System.IO.FileStream c:\temp\test{{ loop.index }}.txt, Create, ReadWrite
$f.SetLength({{ loop.value }}MB)
$f.Close()
- c:\users\administrator\downloads\latencyTest.exe --file c:\temp\test{{ loop.index }}.txt
- AWS s3 cp c:\users\administrator\downloads\latencyMetrics.json s3://bucket/latencyMetrics.json
- |
Remove-Item -Path c:\temp\test{{ loop.index }}.txt
Remove-Item -Path c:\users\administrator\downloads\latencyMetrics.json
```
### `forEach`Schleife mit Eingabeliste
Die `forEach` Schleife iteriert anhand einer expliziten Werteliste, bei der es sich um Zeichenketten und verkettete Ausdrücke handeln kann.
`forEach`Schleife mit Eingabelistenschema
```
- name: "StepName"
action: "ActionModule"
loop:
name: "string"
forEach:
- "string"
inputs:
...
```
**`forEach`Schleife mit Eingabe in die Eingabeliste**
| Feld | Description | Typ | Erforderlich | Standard |
| --- | --- | --- | --- | --- |
| `name` | Eindeutiger Name der Schleife. Er muss im Vergleich zu anderen Schleifennamen in derselben Phase eindeutig sein. | Zeichenfolge | Nein | "" |
| Liste der Zeichenketten der `forEach` Schleife | Liste der Zeichenketten für die Iteration. Akzeptiert verkettete Ausdrücke als Zeichenketten in der Liste. Verkettete Ausdrücke müssen in doppelte Anführungszeichen eingeschlossen werden, damit der YAML-Compiler sie korrekt interpretieren kann. | Liste von Zeichenfolgen | Ja | – |
`forEach`Schleife mit Eingabeliste, Beispiel 1
```
- name: "ExecuteCustomScripts"
action: "ExecuteBash"
loop:
name: BatchExecLoop
forEach:
- /tmp/script1.sh
- /tmp/script2.sh
- /tmp/script3.sh
inputs:
commands:
- echo "Count {{ BatchExecLoop.index }}"
- sh "{{ loop.value }}"
- |
retVal=$?
if [ $retVal -ne 0 ]; then
echo "Failed"
else
echo "Passed"
fi
```
`forEach`Schleife mit Eingabeliste, Beispiel 2
```
- name: "RunMSIWithDifferentArgs"
action: "ExecuteBinary"
loop:
name: MultiArgLoop
forEach:
- "ARG1=C:\Users ARG2=1"
- "ARG1=C:\Users"
- "ARG1=C:\Users ARG3=C:\Users\Administrator\Documents\f1.txt"
inputs:
commands:
path: "c:\users\administrator\downloads\runner.exe"
args:
- "{{ MultiArgLoop.value }}"
```
`forEach`Schleife mit Eingabeliste, Beispiel 3
```
- name: "DownloadAllBinaries"
action: "S3Download"
loop:
name: MultiArgLoop
forEach:
- "bin1.exe"
- "bin10.exe"
- "bin5.exe"
inputs:
- source: "s3://bucket/{{ loop.value }}"
destination: "c:\temp\{{ loop.value }}"
```
### `forEach`Schleife mit begrenzter Liste
Die Schleife iteriert über eine Zeichenfolge, die Werte enthält, die durch ein Trennzeichen getrennt sind. Um über die Bestandteile der Zeichenfolge zu iterieren, AWSTOE verwendet sie das Trennzeichen, um die Zeichenfolge in ein Array aufzuteilen, das für die Iteration geeignet ist.
`forEach`Schleife mit einem durch Trennzeichen getrennten Listenschema
```
- name: "StepName"
action: "ActionModule"
loop:
name: "string"
forEach:
list: "string"
delimiter: ".,;:\n\t -_"
inputs:
...
```
**`forEach`Schleife mit begrenzter Listeneingabe**
| Feld | Description | Typ | Erforderlich | Standard |
| --- | --- | --- | --- | --- |
| `name` | Der Schleife wurde ein eindeutiger Name gegeben. Er sollte im Vergleich zu anderen Schleifennamen in derselben Phase eindeutig sein. | Zeichenfolge | Nein | "" |
| `list` | Eine Zeichenfolge, die aus einzelnen Zeichenketten besteht, die durch ein gemeinsames Trennzeichen miteinander verbunden sind. Akzeptiert auch verkettete Ausdrücke. Stellen Sie bei verketteten Ausdrücken sicher, dass diese in doppelte Anführungszeichen eingeschlossen sind, damit sie vom YAML-Compiler korrekt interpretiert werden können. | Zeichenfolge | Ja | – |
| `delimiter` | Zeichen, das verwendet wird, um Zeichenketten innerhalb eines Blocks voneinander zu trennen. Die Standardeinstellung ist das Kommazeichen. Aus der angegebenen Liste ist nur ein Trennzeichen zulässig: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/imagebuilder/latest/userguide/toe-looping-constructs.html) Verkettungsausdrücke können nicht verwendet werden. | Zeichenfolge | Nein | Komma: "," |
**Anmerkung**
Der Wert von `list` wird als unveränderliche Zeichenfolge behandelt. Wenn die Quelle von während der Laufzeit geändert `list` wird, wird dies während der Ausführung nicht berücksichtigt.
`forEach`Schleife mit begrenzter Liste, Beispiel 1
In diesem Beispiel wird das folgende Verkettungsausdrucksmuster verwendet, um auf die Ausgabe eines anderen Schritts zu verweisen:. `..[inputs | outputs].`
```
- name: "RunMSIs"
action: "ExecuteBinary"
loop:
forEach:
list: "{{ build.GetAllMSIPathsForInstallation.outputs.stdout }}"
delimiter: "\n"
inputs:
commands:
path: "{{ loop.value }}"
```
`forEach`Schleife mit begrenzter Liste, Beispiel 2
```
- name: "UploadMetricFiles"
action: "S3Upload"
loop:
forEach:
list: "/tmp/m1.txt,/tmp/m2.txt,/tmp/m3.txt,..."
inputs:
commands:
- source: "{{ loop.value }}"
destination: "s3://bucket/key/{{ loop.value }}"
```
## Felder für Schritte
Loops sind Teil eines Schritts. Felder, die sich auf die Ausführung eines Schritts beziehen, werden nicht auf einzelne Iterationen angewendet. Schrittfelder gelten nur auf Schrittebene, und zwar wie folgt:
+ *timeoutSeconds* — Alle Iterationen der Schleife müssen innerhalb des in diesem Feld angegebenen Zeitraums ausgeführt werden. Wenn bei der Schleifenausführung eine AWSTOE Zeitüberschreitung eintritt, wird die Wiederholungsrichtlinie des Schritts ausgeführt und der Timeout-Parameter für jeden neuen Versuch zurückgesetzt. Wenn der Schleifenlauf nach Erreichen der maximalen Anzahl von Wiederholungen den Timeout-Wert überschreitet, gibt die Fehlermeldung des Schritts an, dass für den Schleifenlauf eine Zeitüberschreitung aufgetreten ist.
+ *onFailure* — Die Fehlerbehandlung wird wie folgt auf den Schritt angewendet:
+ Wenn *onFailure* auf gesetzt ist`Abort`, wird die Schleife AWSTOE beendet und der Schritt gemäß der Wiederholungsrichtlinie wiederholt. AWSTOE Markiert den aktuellen Schritt nach der maximalen Anzahl von Wiederholungsversuchen als fehlgeschlagen und beendet die Ausführung des Prozesses.
AWSTOE setzt den Statuscode für die übergeordnete Phase und das Dokument auf`Failed`.
**Anmerkung**
Nach dem fehlgeschlagenen Schritt werden keine weiteren Schritte ausgeführt.
+ Wenn *onFailure* auf gesetzt ist`Continue`, wird die Schleife AWSTOE beendet und der Schritt gemäß der Wiederholungsrichtlinie wiederholt. AWSTOE Markiert den aktuellen Schritt nach der maximalen Anzahl von Wiederholungsversuchen als fehlgeschlagen und fährt mit der Ausführung des nächsten Schritts fort.
AWSTOE setzt den Statuscode für die übergeordnete Phase und das Dokument auf`Failed`.
+ Wenn *onFailure* auf gesetzt ist`Ignore`, wird die Schleife AWSTOE beendet und der Schritt gemäß der Wiederholungsrichtlinie wiederholt. AWSTOE Markiert den aktuellen Schritt nach der maximalen Anzahl von Wiederholungsversuchen als `IgnoredFailure` und fährt mit der Ausführung des nächsten Schritts fort.
AWSTOE setzt den Statuscode für die übergeordnete Phase und das Dokument auf`SuccessWithIgnoredFailure`.
**Anmerkung**
Dies wird immer noch als erfolgreiche Ausführung angesehen, enthält jedoch Informationen, die Sie darüber informieren, dass ein oder mehrere Schritte fehlgeschlagen sind und ignoriert wurden.
+ *maxAttempts* — Bei jeder Wiederholung werden der gesamte Schritt und alle Iterationen von Anfang an ausgeführt.
+ *Status* — Der Gesamtstatus der Ausführung eines Schritts. `status`stellt nicht den Status einzelner Iterationen dar. Der Status eines Schritts mit Schleifen wird wie folgt bestimmt:
+ Wenn eine einzelne Iteration nicht ausgeführt werden kann, weist der Status eines Schritts auf einen Fehler hin.
+ Wenn alle Iterationen erfolgreich sind, deutet der Status eines Schritts auf Erfolg hin.
+ *StartTime* — Die Gesamtstartzeit der Ausführung eines Schritts. Stellt nicht die Startzeit einzelner Iterationen dar.
+ *EndTime* — Die Gesamtendzeit der Ausführung eines Schritts. Stellt nicht die Endzeit einzelner Iterationen dar.
+ *FailureMessage — Schließt* die Iterationsindizes ein, die bei Fehlern ohne Timeout fehlgeschlagen sind. Bei Timeoutfehlern gibt die Meldung an, dass der Schleifenlauf fehlgeschlagen ist. Es werden keine individuellen Fehlermeldungen für jede Iteration bereitgestellt, um die Größe der Fehlermeldungen zu minimieren.
## Ausgaben für Schritt und Iteration
Jede Iteration enthält eine Ausgabe. Am Ende eines Schleifenlaufs AWSTOE konsolidiert es alle erfolgreichen Iterationsausgaben in. `detailedOutput.json` Die konsolidierten Ausgaben sind eine Zusammenstellung von Werten, die zu den entsprechenden Ausgabeschlüsseln gehören, wie sie im Ausgabeschema des Aktionsmoduls definiert sind. Das folgende Beispiel zeigt, wie die Ausgaben konsolidiert werden:
**Ausgabe von `ExecuteBash` für Iteration 1**
```
{
"stdout":"Hello"
}
```
**Ausgabe von `ExecuteBash` für Iteration 2**
```
{
"stdout":"World"
}
```
**Ausgabe von `ExecuteBash` für Schritt**
```
{
"stdout":"Hello\nWorld"
}
```
Zum Beispiel `ExecuteBinary` sind `ExecuteBash``ExecutePowerShell`, und Aktionsmodule, die `STDOUT` als Aktionsmodulausgabe zurückgegeben werden. `STDOUT`Nachrichten werden mit dem neuen Zeilenzeichen verknüpft, um die Gesamtausgabe des Step-In zu erzeugen`detailedOutput.json`.
AWSTOE konsolidiert nicht die Ausgaben erfolgloser Iterationen.