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.

Syntax und Beispiele für die Upgrade-Rollout-Richtlinie

Eine Upgrade-Rollout-Richtlinie definiert, wie AWS Services automatische Upgrades auf Ihre Ressourcen anwenden. Wenn Sie die Richtliniensyntax verstehen, können Sie effektive Richtlinien erstellen, die den Upgrade-Anforderungen Ihres Unternehmens entsprechen.

Überlegungen

Bei der Implementierung von Richtlinien für die Einführung von Upgrades sollten Sie die folgenden wichtigen Faktoren berücksichtigen:

Grundlegende Richtlinienstruktur

Richtlinien für die Einführung von Upgrades verwenden eine JSON-Struktur, die die folgenden Hauptelemente umfasst:

Das folgende Beispiel zeigt eine grundlegende Richtlinienstruktur für die Einführung eines Upgrades:

{
   "upgrade_rollout":{
      "default":{
         "patch_order":{
            "@@assign":"last"
         }
      },
      "tags":{
         "devtag":{
            "tag_values":{
               "tag1":{
                  "patch_order":{
                     "@@assign":"first"
                  }
               },
               "tag2":{
                  "patch_order":{
                     "@@assign":"second"
                  }
               },
               "tag3":{
                  "patch_order":{
                     "@@assign":"last"
                  }
               }
            }
         }
      }
   }
}

Richtlinienkomponenten

Eine Upgrade-Rollout-Richtlinie besteht aus zwei Hauptkomponenten, die zusammen steuern, wie Upgrades auf Ihre Ressourcen angewendet werden. Zu diesen Komponenten gehören Konfigurationsoptionen sowohl für Standardverhalten als auch für tagbasierte Überschreibungen. Wenn Sie verstehen, wie diese Komponenten interagieren, können Sie effektive Richtlinien erstellen, die Ihren Unternehmensanforderungen entsprechen.

Standard-Setup für die Patch-Reihenfolge

Wenn Sie eine Upgrade-Rollout-Richtlinie erstellen, ohne ressourcenspezifische Überschreibungen anzugeben, wird für alle Ressourcen standardmäßig eine Basis-Upgrade-Reihenfolge verwendet. Sie können diese Standardeinstellung mithilfe des Felds „Standard“ in Ihrer Richtlinie festlegen. Ressourcen ohne ausdrückliche Zuweisung der Upgrade-Reihenfolge durch Tags folgen dieser Standardreihenfolge.

Das folgende Beispiel zeigt, wie Sie festlegen, dass alle Ressourcen standardmäßig zuletzt aktualisiert werden, sofern sie nicht durch Tags überschrieben werden. Dieser Ansatz ist nützlich, wenn Sie sicherstellen möchten, dass die meisten Ressourcen später im Upgrade-Zyklus aktualisiert werden:

"upgrade_rollout": {
    "default": {
        "patch_order": "last"
    }
}

Überschreiben der Ressourcenebene mithilfe von Tags

Sie können die standardmäßige Upgrade-Reihenfolge für bestimmte Ressourcen mithilfe von Tags überschreiben. Auf diese Weise können Sie detailliert steuern, welche Ressourcen in welcher Reihenfolge aktualisiert werden. Beispielsweise können Sie je nach Umgebungstyp, Entwicklungsphase oder Workload-Pritikalität unterschiedliche Upgrade-Bestellungen zuweisen.

Das folgende Beispiel zeigt, wie Sie Entwicklungsressourcen so konfigurieren, dass sie zuerst Upgrades erhalten und Produktionsressourcen, sie zuletzt erhalten. Diese Konfiguration stellt sicher, dass Ihre Entwicklungsumgebungen Upgrades validieren können, bevor sie in Produktion gehen:

"upgrade_rollout": {
    "tags": {
        "environment": {
            "tag_values": {
                "development": {
                    "patch_order": "first"
                },
                "production": {
                    "patch_order": "last"
                }
            }
        }
    }
}

Beispiele für Richtlinien zur Einführung von Upgrades

Im Folgenden finden Sie häufig vorkommende Richtlinienszenarien für die Einführung von Upgrades:

Beispiel 1: Zuerst die Entwicklungsumgebung

Dieses Beispiel zeigt, wie Sie Ressourcen in Ihrer Entwicklungsumgebung so konfigurieren, dass sie zuerst Upgrades erhalten. Indem Sie gezielt Ressourcen mit dem Umgebungs-Tag „Entwicklung“ auswählen, stellen Sie sicher, dass Ihre Entwicklungsumgebungen als Erste neue Upgrades erhalten und validieren. Dieses Muster hilft dabei, potenzielle Probleme zu identifizieren, bevor Upgrades kritischere Umgebungen erreichen:

{
    "tags": {
        "environment": {
            "tag_values": {
                "development": {
                    "upgrade_order": "first"
                }
            }
        }
    }
}

Beispiel 2: Letzte Produktionsumgebung

Dieses Beispiel zeigt, wie Sie sicherstellen können, dass Ihre Produktionsumgebungen zuletzt aktualisiert werden. Indem Sie Ressourcen mit Produktionskennzeichnung explizit auf die letzte Upgrade-Reihenfolge setzen, sorgen Sie für Stabilität in Ihrer Produktionsumgebung und ermöglichen gleichzeitig angemessene Tests in Vorproduktionsumgebungen. Dieser Ansatz ist besonders nützlich für Unternehmen mit strengen Anforderungen an das Änderungsmanagement:

{
    "tags": {
        "environment": {
            "tag_values": {
                "production": {
                    "upgrade_order": "last"
                }
            }
        }
    }
}

Beispiel 3: Mehrere Upgrade-Bestellungen mithilfe von Tags

Das folgende Beispiel zeigt, wie Sie einen einzelnen Tag-Schlüssel mit unterschiedlichen Werten verwenden, um alle drei Upgrade-Bestellungen anzugeben. Dieser Ansatz ist nützlich, wenn Sie Upgrade-Bestellungen über ein einziges Tagging-Schema verwalten möchten:

{
   "upgrade_rollout":{
      "default":{
         "patch_order":{
            "@@assign":"last"
         }
      },
      "tags":{
         "devtag":{
            "tag_values":{
               "tag1":{
                  "patch_order":{
                     "@@assign":"first"
                  }
               },
               "tag2":{
                  "patch_order":{
                     "@@assign":"second"
                  }
               },
               "tag3":{
                  "patch_order":{
                     "@@assign":"last"
                  }
               }
            }
         }
      }
   }
}