Upgrade-Leitfäden der Plattform (v4.4.0 bis v4.12.x)¶

Versionsspezifische Schritte, um das Konfigurations-Repository eines Kunden zu upgraden. Nutze sie zusammen mit dem allgemeinen Verfahren in Was zu tun ist, wenn eine neue Version veröffentlicht wird.

So nutzt du diese Leitfäden¶

Die Leitfäden sind kumulativ. Lies und befolge den Leitfaden jeder Version zwischen deiner aktuellen und deiner Zielversion, die älteste zuerst. Eine Version, die nicht aufgeführt ist (zum Beispiel v4.8 oder v4.10), braucht keine besonderen Schritte.
Erledige das Aufräumen im Portal, bevor du mit späteren Schritten weitermachst. Das Entfernen eines policy assignments oder einer Initiative braucht Berechtigung an der management group. Beantrage erhöhten Zugriff (PIM) zuerst, wenn dein Prozess das verlangt.
Pfade sind relativ zum Root des Konfigurations-Repositorys. Ältere Versionen nutzten ein Parameter-Repository mit demselben Layout. <env> steht für jeden Ordner einer Plattform-Umgebung (canary, prod) unter environments/. Führe jeden Dateischritt in jeder Umgebung aus.
Manche Leitfäden beschreiben das ältere Layout mit einer einzigen pipeline (pipelines/main.yaml). Im aktuellen Layout sind die Entry- pipelines hub, spoke, infrastructure und container (Pipelines und Workflows). Wo ein Schritt für dein Layout nicht gilt, sagt der Leitfaden es.
Wenn du über mehrere Versionen upgradest, plane einmal am Ende statt nach jedem Leitfaden. Lies den Plan auf unerwartete Löschungen oder Ersetzungen (Die spoke-Pläne lesen).

Version	Von	Zusammenfassung
v4.4.0	v4.3.x	policy-Dateien löschen, state-storage-Overrides setzen, zwei policy-Objekte im Portal entfernen
v4.5.0	v4.4.x	Entry-pipeline: das Konfigurations-Repository als resource hinzufügen und veröffentlichen
v4.5.1	v4.5.x	Eigene Alerting-Assignments, -Initiativen und `Deploy_*`-Definitionen entfernen
v4.6.0 und v4.6.1	v4.5.x	`ghrunners.auto.tfvars` hinzufügen
v4.7.0	v4.6.x	Drei Defender-for-Cloud-Assignments entfernen
v4.9.0	v4.7.x	tfvars-Pfade kürzen, eine firewall-Variable hinzufügen, den Parameter `environment` entfernen
v4.11.x	v4.9.x	Alte DNS- und BIO-policy-Dateien löschen, zwei Assignments und zwei Initiativen entfernen
v4.12.x	v4.11.x	Das Assignment und die Initiative für private DNS zones entfernen, `firewall_policy_id` prüfen

Version 4.4.0¶

Von v4.3.x. Die Konfiguration von policies und Monitoring ist in das Code-Repository gewandert, daher müssen die Kopien im Konfigurations- Repository weg (Historie).

Dateien aus dem Konfigurations-Repository entfernen¶

Mach das für beide, environments/prod/ und environments/canary/.

Pfad unter `environments/<env>/policies/`	Entfernen
`policy_assignments/01_management_groups/`	`policy_set_assignment_compliance_asc.json`, `policy_set_assignment_compliance_cis.json`, `policy_set_assignment_compliance_iso.json`, `policy_set_assignment_defender.json`, `policy_set_assignment_diagnostics.json`
`definitions/general/`	Jede `policy_definition_es_deploy_diagnostics_*.json` und `policy_definition_es_deploy_asc_securitycontacts.json`
`set_definitions/general/`	`policy_set_definition_defender_for_cloud.json`, `policy_set_definition_es_deploy_diagnostics_loganalytics.json`, `policy_set_definition_es_deploy_mdfc_config.json`

Den Ort des state storage setzen, wenn er nicht dem Standard entspricht¶

Die Plattform muss jetzt wissen, wo das Terraform-state-Storage-Account liegt. Wenn deines allen Standardwerten unten entspricht, musst du nichts tun.

Element	Standard
Name des Storage Accounts	`stlz<company short name>state001`
Resource group	`rg-<company short name>-tfstate-<location short name>-001`
Subscription	Die management-subscription

Wenn ein Wert abweicht, füge diese Variablen zu environments/prod/global.tfvars hinzu (und zum Gegenstück für canary):

Variable	Wert
`overwrite_state_storage_subscription_id`	Die subscription-ID des state-Storage-Accounts
`overwrite_state_storage_rg_name`	Der Name der resource group des state-Storage-Accounts
`overwrite_state_storage_name`	Der Name des state-Storage-Accounts

Zwei policy-Objekte im Azure-Portal entfernen¶

Öffne Azure Policy, dann Authoring > Definitions.
Suche nach Deploy-MDFC-Config und öffne die Initiative. Entferne auf dem Tab Assignments jedes Assignment. Geh zurück und lösche die Initiative.
Suche nach Deploy Microsoft Defender for Cloud Security Contacts und öffne die policy. Entferne jedes Assignment auf dem Tab Assignments, dann lösche die Definition.

Version 4.5.0¶

Von v4.4.x. Dieser Leitfaden gilt für das ältere Layout mit einer einzigen pipeline. Er sorgt dafür, dass die pipeline das Konfigurations- Repository explizit auscheckt und als Artefakt veröffentlicht. Dasselbe Release hat GitHub als Quelle für die Plattform- Konfiguration hinzugefügt.

In pipelines/main.yaml des Konfigurations-Repositorys:

Füge das Konfigurations-Repository als resource neben dem Code-Repository hinzu:

resources:
  repositories:
    - repository: <code repository resource name>
      type: git
      name: <project>/<code repository name>
      ref: refs/tags/<version>

    - repository: <configuration repository resource name>   # new
      type: git
      name: <configuration repository name>
      ref: $(Build.SourceBranch)

Achte darauf, dass der name der neuen resource der echte Name des Konfigurations-Repositorys ist.

Ändere den ersten Checkout-Schritt von self auf die neue resource:

- checkout: <configuration repository resource name>   # was: self
  path: s/customer
  fetchDepth: 0
  persistCredentials: true
  clean: true

- checkout: <code repository resource name>
  path: s/landingzone-core
  clean: true

Füge nach dem bestehenden Task für das firewall-Artefakt einen Task hinzu, der die Konfiguration als Artefakt veröffentlicht:

- task: PublishPipelineArtifact@1
  displayName: Publish Customer Content
  inputs:
    targetPath: '$(System.DefaultWorkingDirectory)/customer/'
    artifact: 'CustomerSource'
    publishLocation: 'pipeline'

Die aktuellen Entry-pipelines (hub.yaml und die anderen) checken das Konfigurations-Repository bereits aus. Für sie ist dieser Leitfaden nicht nötig.

Version 4.5.1¶

Von v4.5.x. Die Alerting-policies wurden durch Azure Monitor Baseline Alerts ersetzt, daher müssen die alten eigenen Alerting-Objekte entfernt werden (Wie Alerting funktioniert). Beantrage zuerst über PIM Owner-Zugriff auf die canary- und prod- Plattform. Führe die Schritte für beide, canary und prod, aus.

Entferne die Alerting-policy-Assignments. Entferne in Azure Policy > Assignments alle fünf Assignments mit dem Namen Xebia Custom - Alerting - *.
Entferne die Alerting-policy-Initiativen. Entferne in Azure Policy > Definitions alle fünf Definitionen mit dem Namen Alerting-*.
Entferne die Deploy_*-policy-Definitionen. Öffne eine Azure-PowerShell-Sitzung (lokal oder in Cloud Shell) und führe den Befehl unten für jede Umgebung aus, mit der management-group-ID der Plattform dieser Umgebung:
```
$managementGroupId = "<management group id of the platform>"
Get-AzPolicyDefinition -ManagementGroupName $managementGroupId | Where-Object {$_.Name -Like "Deploy_*"} | Remove-AzPolicyDefinition -Force
```

Prüfe zuerst, was der Filter trifft

Der Filter entfernt jede eigene policy-Definition an dieser management group, deren Name mit Deploy_ beginnt. Führe den ersten Teil des Befehls ohne Remove-AzPolicyDefinition aus und lies die Liste. Entferne nur Definitionen, die die Plattform erstellt hat.

Version 4.6.0 und 4.6.1¶

Von v4.5.x. Version 4.6.0 hat einen Layer mit dem Netzwerk für GitHub-gehostete Runner hinzugefügt. Der Layer braucht eine Variablendatei, auch wenn er nicht genutzt wird.

Füge für jede Umgebung und Region, die du deployst, environments/<env>/<region>/ghrunners.auto.tfvars hinzu:

# General
deploy_github_runners = false
location              = "northeurope"
location_short_name   = "neu"

# Virtual Network
virtual_network_address_space = null
virtual_network_dns_servers   = null

# Subnets
subnets = null

Setze location und location_short_name auf die Region des Ordners, in dem du dich befindest. Lass deploy_github_runners = false, es sei denn, der Kunde nutzt GitHub-gehostete Runner.

Aktuelle pipelines

Der Layer ghrunners existiert im Code, ist aber nicht Teil der aktuellen hub-pipeline. Die Datei hat dort keine Wirkung (Deployment-Layer). Nur ältere pipelines führen ihn aus.

Version 4.7.0¶

Von v4.6.x. Öffne im Azure-Portal Azure Policy > Authoring > Assignments, suche nach diesen Assignments und lösche sie:

Xebia Default - Defender for Cloud v2 - connectivity
Xebia Default - Defender for Cloud v2 - identity
Xebia Default - Defender for Cloud v2 - management

Version 4.9.0¶

Von v4.7.x. Drei Änderungen im Konfigurations-Repository.

Die Dateipfade in jeder tfvars-Datei kürzen¶

Finde jeden Pfad, der mit ../../../../customer/ beginnt, und entferne diesen Teil. Mach das in allen *.tfvars-Dateien.

Old: ../../../../customer/environments/prod/firewall_rule_configuration
New: environments/prod/firewall_rule_configuration

Eine Variable zu jeder firewall-tfvars-Datei hinzufügen¶

Füge in jeder firewall.auto.tfvars (eine pro Region) die Variable unten hinzu. Nimm prod oder canary, passend zum Umgebungs- Ordner der Datei.

firewall_rule_collection_global_file_location = "environments/prod/firewall_rule_configuration"

Den Parameter environment aus der Entry-pipeline entfernen¶

In pipelines/main.yaml (Layout mit einer einzigen pipeline):

Entferne bei der Template-Referenz für die canary-Umgebung (environment_canary) den Parameter environment: canary.
Entferne bei der Template-Referenz für die Produktionsumgebung (environment_prod) den Parameter environment: prod.

Version 4.11.x¶

Von v4.9.x. Die Plattform liefert jetzt eigene private-DNS-policies mit, und die eigene BIO-Initiative ist entfallen.

Alte DNS-policy-Dateien entfernen¶

Entferne in beiden, environments/canary/ und environments/prod/:

die Ordner policies/policy_set_definitions/private_dns_zones und policies/policy_definitions/private_dns_zones;
die Dateien policies/policy_set_definitions/general/policy_set_definition_es_deploy_private_dns_zones.json und policies/policy_set_definitions/general/policy_set_definition_es_enforce_encrypttransit.json;
die Datei policies/policy_assignments/01_management_groups/policy_set_assignment_xms_private_dns_zones.json.

Die alte BIO-Initiative entfernen¶

Entferne in beiden Umgebungen den Ordner policies/policy_set_definitions/bio_custom.

policy-Objekte im Azure-Portal entfernen¶

Öffne Azure Policy > Assignments. Setze den Scope auf die management group Landing Zones und entferne das Assignment Alerting-LandingZone.
Setze den Scope auf die management group Platform Root (die Gruppe cloudplatform) und entferne das Assignment XMS-Deploy-DNS-Zones.
Öffne Definitions. Setze den Scope auf Landing Zones und entferne die Initiative Alerting-LandingZone.
Setze den Scope auf den Platform Root und entferne die Initiative XMS-Deploy-DNS-Zones.

Namen und Scopes

Die Initiative Alerting-LandingZone ist auch der Name einer Initiative im aktuellen Alerting-Design (Monitoring-Regeln). Der Leitfaden entfernt das alte Objekt, das die vorherige Version deployt hat. Prüfe den Scope und den Namen des Assignments, bevor du löschst.

Version 4.12.x¶

Von v4.11.x. Zwei Schritte.

Die alten Objekte für private DNS zones im Azure-Portal entfernen¶

Öffne Azure Policy > Assignments. Setze den Scope auf Landing Zones und entferne das Assignment XMMS-Private-DNS-Zones.
Öffne Definitions. Setze den Scope auf die management group Platform Root und entferne die Initiative XMMS-Private-DNS-Zones.

Die ID der Application-Gateway-WAF-policy prüfen¶

Jede Application-Gateway-JSON-Datei braucht eine gültige firewall_policy_id.

Öffne jede environments/*/*/application_gateways/*.json im Konfigurations-Repository.
Wenn firewall_policy_id eine gültige Ressourcen-ID einer WAF-policy enthält, zum Beispiel /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Network/applicationGatewayWebApplicationFirewallPolicies/<waf-policy-name>, bist du mit dieser Datei fertig.
Wenn sie null oder ein leerer String ist, suche das Application Gateway im Azure-Portal anhand des name in der Datei und öffne es.
Öffne JSON View, wähle die neueste API-Version, finde "firewallPolicy" und kopiere den Wert von id in die Datei.
Ändere im eingefügten Wert ApplicationGatewayWebApplicationFirewallPolicies in applicationGatewayWebApplicationFirewallPolicies (ein kleines a am Anfang).
Wiederhole das für jede Datei, dann committe und pushe.

Den Rest der Datei findest du unter Application Gateway.

Nach den Leitfäden¶

Führe hub im Modus Plan aus und lies jeden Layer (Schritt 6).
Halte die befolgten Leitfäden im Work Item fest.
Wenn ein Schritt nicht wie beschrieben funktioniert hat oder ein Leitfaden fehlt, melde es, damit der Leitfaden korrigiert werden kann (Releasing).