Dokumentation Commerce Commerce in Cloud Manager

Konfigurieren von Services

Letzte Aktualisierung: 1. September 2026

Erstellt für:

Admin
Entwicklerin/Entwickler

Die services.yaml definiert die Services, die von Adobe Commerce in Cloud-Infrastrukturen wie MySQL, Redis oder Valkey sowie Elasticsearch oder OpenSearch unterstützt und verwendet werden. Sie müssen keine externen Dienstleister abonnieren.

NOTE

Die .magento/services.yaml wird lokal im .magento des Projekts verwaltet. Während der Bereitstellung verwendet Adobe Commerce in der Cloud-Infrastruktur diese Konfiguration, um unterstützte Services für die Zielumgebung bereitzustellen. Das .magento Verzeichnis wird nach der Bereitstellung vom Remote-Server entfernt, sodass services.yaml in der bereitgestellten Umgebung nicht vorhanden ist.

Das Bereitstellungsskript verwendet die Konfigurationsdateien im .magento, um die Umgebung mit den konfigurierten Services bereitzustellen. Ein Dienst wird für die Anwendung verfügbar, wenn er in der relationships der .magento.app.yaml enthalten ist. Die services.yaml-Datei enthält die Werte type und disk. Der Diensttyp definiert den Dienst name und version.

Die Service-Konfiguration in .magento/services.yaml ist getrennt von den PHP- und Composer-Paketabhängigkeiten, die in composer.json definiert und in composer.lock gesperrt sind.

Wo Service-Änderungen gelten

Wenn Sie eine Service-Konfiguration ändern, stellt eine -Bereitstellung die Umgebung mit den aktualisierten Services bereit, was sich auf die folgenden Umgebungen auswirkt:

Alle Starter-Umgebungen einschließlich master
Pro-Integrationsumgebungen

Pro Services-Support

Gehen Sie wie folgt vor, um ein Pro-Service-Upgrade in der Staging- oder Produktionsumgebung anzufordern und abzuschließen:

Um (Services nur in Staging und Production Umgebungen zu installieren zu aktualisieren senden Sie ein Adobe Commerce-Support-Ticket.

Geben Sie im Ticket die erforderlichen Service-Änderungen an, schließen Sie die aktualisierten .magento.app.yaml- und .magento/services.yaml-Dateien ein und notieren Sie sich die PHP-Zielversion.

PHP-Version, Composer-Updates, Erweiterungen und Umgebungseinstellungen sind Self-Service-Änderungen. Adobe muss möglicherweise den New Relic-Agenten aktualisieren, um die PHP-Versionskompatibilität zu gewährleisten. Siehe PHP-Einstellungen in Anwendungskonfiguration.

note important
IMPORTANT
Verwenden Sie bei der Auswahl des Felds Environment im Ticketformular die Umgebungsbenennung von Adobe. Wählen Sie beispielsweise Staging aus, auch wenn Sie diese Umgebung intern dev aufrufen. Sie können Ihren internen Namen in der Beschreibung angeben, aber das Feld Environment muss die Nomenklatur von Adobe verwenden.

Bestätigen Sie den Upgrade Zeitplan durch den zweiteiligen Prozess von Adobe: Sie bestätigen zuerst das angeforderte Datum und die angeforderte Uhrzeit und senden es dann an den Support zur endgültigen Bestätigung an das Infrastruktur-Team.

Produktionsänderungen (nur Pro) erfordern mindestens zwei Werktage Vorankündigung, Wochenenden ausgeschlossen. Beispielsweise muss das Cloud-Infrastruktur-Team ein Upgrade vom Montag bis zum vorhergehenden Mittwoch bestätigen. Bei Spitzennachfrage ist mit zusätzlicher Vorlaufzeit zu rechnen. Um Verzögerungen zu vermeiden, beantworten Sie die ursprüngliche Anfrage mindestens 48 Stunden vor dem Fenster. Das Upgrade gilt erst als geplant, wenn Sie eine endgültige Bestätigung erhalten.

note
NOTE
Bereitstellen von Wartungsfenstern in UTC. Staging-Upgrades sind nicht im Voraus geplant und werden in der Regel am selben Tag wie die Anfrage abgeschlossen.
Stellen Sie nach einem RabbitMQ-Upgrade die Umgebung erneut bereit, um die Nachrichtenwarteschlangen neu zu initialisieren.

Validieren Sie das Upgrade in einer Staging- oder Integrationsumgebung, bevor Sie es in der Produktionsumgebung planen.

Probleme, die durch Drittanbietermodule, benutzerdefinierten Code oder die Kompatibilität mit Abhängigkeiten verursacht werden, treten häufig während der erneuten Bereitstellung auf, die auf ein Service-Upgrade folgt. Zur Validierung mehrerer Service-Upgrades auf einmal ist eine angemessene Reihenfolge Valley oder Redis, dann RabbitMQ, dann OpenSearch, dann MariaDB. Dies ist keine erforderliche Sequenz. Datenbank-Upgrades haben die größte Auswirkung auf den Betrieb und verdienen höchste Vorsicht.

Adobe übernimmt keine Garantie für die genaue Dauer eines Produktionswartungsfensters im Voraus, da der Zeitpunkt von der Umgebung und den beteiligten Services abhängt. Nutzen Sie bei der Planung des Produktionsfensters die Zeit, die für das Staging-Upgrade benötigt wird.
Stellen Sie die Umgebung erneut, nachdem Adobe das Service-Upgrade abgeschlossen hat, damit die Änderung wirksam wird, auch wenn sich die Version der Adobe Commerce-Anwendung nicht ändert.

Wenn das Upgrade OpenSearch umfasst, planen Sie auch eine vollständige Neuindizierung. Adobe kann keine Ausfallzeiten für ein Service-Upgrade garantieren. Planen Sie daher ein Wartungsfenster, in dem Zeit für die Neubereitstellung, Neuindizierung bei Bedarf und die Validierung der Storefront und des Administrators bleibt, bevor Sie die Site erneut öffnen.

Kundenverfügbarkeit bei Upgrades

Ein Mitarbeiter Ihres Teams oder Implementierungspartners muss für die Dauer des geplanten Produktions-Upgrades online verfügbar sein. Durch die Planung während einer Zeit mit geringem Traffic ist das Upgrade nicht praktisch erledigt. Adobe verwaltet die Aktualisierung der Cloud-Infrastruktur, kann jedoch das Anwendungsverhalten, Integrationen, benutzerdefinierten Code oder Unternehmens-Workflows nicht validieren.

Der verfügbare Vertreter muss in der Lage sein,

Überwachen der Storefront und kritischer Geschäftstransaktionen während und nach dem Upgrade.
Beantworten Sie Fragen des Adobe-Supports oder des Cloud-Infrastruktur-Teams.
Bestätigen dass Integrationen, Erweiterungen, Anpassungen, Cron-Aufträge, Warteschlangen und andere kundenspezifische Funktionen erwartungsgemäß funktionieren.
Validieren geschäftskritische Workflows, wie z. B. Checkout, Katalogansichten, Suche, Anmeldung und Bestellabwicklung.
Bericht unerwartetes Verhalten sofort melden, während der Upgrade-Kontext und die Protokolle weiterhin verfügbar sind.

TIP

Für Pro-Projekte erfordern Service-Upgrades in der Produktion auch eine vorzeitige Planung und einen zweiteiligen Bestätigungsprozess mit Adobe-Support. Siehe Pro Services-Support.

Wartungsmodus

Der Wartungsmodus ist kein Ersatz für die Kundenverfügbarkeit. Der Wartungsmodus blockiert den Zugriff auf die Storefront, validiert jedoch nicht Anwendungsdienste, Integrationen, Warteschlangen, Cron-Aufträge, Checkout oder andere kundenspezifische Funktionen.

Wenn für die geplanten Arbeiten der Wartungsmodus erforderlich ist, koordinieren Sie die Verwendung mit dem Adobe-Support und befolgen Sie die Anweisungen für dieses Upgrade. Vergewissern Sie sich anschließend, dass die Storefront und die kritischen Workflows normal funktionieren, bevor Sie den Abschluss der Arbeit in Betracht ziehen.

Standard- und unterstützte Services

Adobe Commerce in Cloud-Infrastrukturen unterstützt die folgenden Services, die für Ihr Projekt konfiguriert werden können:

NOTE

Aktualisieren Sie RabbitMQ sequenziell zwischen verfügbaren Versionen. Aktualisieren Sie beispielsweise nicht von 3.9 direkt auf 4.1.

Um sicherzustellen, dass Ihre benutzerdefinierten Nachrichtenwarteschlangen nach dem Upgrade auf eine neue Version in RabbitMQ neu erstellt werden, erstellen Sie einen Trigger für eine vollständige Bereitstellung.

Anzeigen konfigurierter Services und Versionen

Sie können beispielhafte Service-Definitionen und Datenträgerwerte in der aktuellen services.yaml-Datei der Vorlage anzeigen. Die tatsächlichen standardmäßigen und unterstützten Dienstversionen hängen von Ihrer Adobe Commerce-Version und Ihrer aktuellen Cloud-Vorlage ab.

Das folgende Beispiel zeigt Service-Definitionen in der services.yaml-Konfigurationsdatei:

mysql:
    type: mysql:11.8
    disk: 5120

cache:
    type: valkey:9.0

opensearch:
    type: opensearch:3  # minor version not required; uses latest
    disk: 1024

rabbitmq:
    type: rabbitmq:4.3
    disk: 1024

activemq-artemis:
    type: activemq-artemis:2.42
    disk: 1024

Service-Werte

Geben Sie die Service-ID und den type: <name>:<version> für den Service-Typ an. Wenn der Service persistenten Speicher verwendet, müssen Sie einen Datenträgerwert angeben.

Verwenden Sie das folgende Format:

<service-id>:
    type: <name>:<version>
    disk: <value-MB>

`service-id`

Der service-id identifiziert den Service im Projekt. Sie können nur alphanumerische Kleinbuchstaben verwenden: a zu z und 0 zu 9, z. B. valkey.

Dieser service-id-Wert wird in der relationships-Eigenschaft der .magento.app.yaml-Konfigurationsdatei verwendet:

relationships:
    valkey: "valkey:valkey"

Sie können mehrere Instanzen jedes Service-Typs benennen. Sie können beispielsweise mehrere Valley-Instanzen verwenden, eine für die Sitzung und eine für den Cache.

valkey:
    type: valkey:<version>

valkey2:
    type: valkey:<version>

Umbenennen eines Dienstes in der services.yaml:

Öffnen Sie den vorhandenen Dienst, bevor Sie einen Dienst mit dem von Ihnen angegebenen neuen Namen erstellen.
Alle vorhandenen Daten für den Service werden entfernt. Adobe empfiehlt, Ihre Starter-Umgebung zu sichern bevor Sie den Namen eines vorhandenen Services ändern.

`type`

Der type gibt den Namen und die Version des Services an. Beispiel:

mysql:
    type: mysql:10.4

`disk`

Der disk gibt die Größe des persistenten Festplattenspeichers (in MB) an, der dem Service zugewiesen werden soll. Dienste, die persistenten Speicher verwenden, wie MySQL, müssen einen Festplattenwert angeben. Dienste, die Speicher anstelle von persistentem Speicher verwenden, wie z. B. Valley, benötigen keinen Festplattenwert.

mysql:
    type: mysql:10.4
    disk: 5120

Der aktuelle standardmäßige Speicherbedarf pro Projekt beträgt 5 GB oder 5.120 MB. Sie können diesen Betrag zwischen Ihrer Anwendung und den einzelnen zugehörigen Diensten aufteilen.

Service-Beziehungen

In Adobe Commerce in Cloud-Infrastrukturprojekten bestimmen ServiceBeziehungen, die in der .magento.app.yaml-Datei konfiguriert sind, welche Services für Ihre Anwendung verfügbar sind.

Sie können die Konfigurationsdaten für alle Service-Beziehungen aus der $MAGENTO_CLOUD_RELATIONSHIPS Umgebungsvariablen abrufen. Die Konfigurationsdaten umfassen den Dienstnamen, den Typ und die Version sowie alle erforderlichen Verbindungsdetails wie Port-Nummer und Anmeldeinformationen.

Überprüfen von Beziehungen aus Ihrer lokalen Entwicklungsumgebung

Zeigen Sie in Ihrer lokalen Entwicklungsumgebung die Beziehungen für die aktive Umgebung an.

code language-bash
`magento-cloud relationships`

Bestätigen Sie die service und type aus der Antwort. Die Antwort enthält Verbindungsinformationen wie IP-Adresse und Port-Nummer.

Abgekürzte Beispielantwort

code language-yaml
`valkey: - ... type: 'valkey:8.0' port: 6379 opensearch: - ... type: 'opensearch:3' port: 9200 database: - ... type: 'mysql:11.8' port: 3306`

Überprüfen von Beziehungen in Remote-Umgebungen

Verwenden Sie SSH, um sich bei der Remote-Umgebung anzumelden.

Auflisten der Beziehungskonfigurationsdaten für alle in der Umgebung konfigurierten Services.

code language-bash
`echo $MAGENTO_CLOUD_RELATIONSHIPS \| base64 -d \| json_pp`

Oder verwenden Sie den folgenden ece-tools-Befehl, um Beziehungen anzuzeigen:

code language-bash
`php ./vendor/bin/ece-tools env:config:show services`

Bestätigen Sie die service und type aus der Antwort. Die Antwort enthält Verbindungsinformationen wie IP-Adresse, Portnummer sowie die erforderlichen Benutzernamen- und Kennwortberechtigungen.

Service-Versionen

Versionen, die in der Cloud-Infrastruktur bereitgestellt und getestet wurden, bestimmen die Service-Version und Kompatibilitätsunterstützung für Adobe Commerce in der Cloud-Infrastruktur, die sich manchmal von den Versionen unterscheiden, die von lokalen Adobe Commerce-Bereitstellungen unterstützt werden. Siehe Systemanforderungen im Installationshandbuch für eine Liste der Abhängigkeiten von Drittanbieterprogrammen, die Adobe mit bestimmten Adobe Commerce- und Magento Open Source-Versionen getestet hat.

Software-EOL-Prüfungen

Während des Bereitstellungsprozesses überprüft das ece-tools-Paket die installierten Service-Versionen für jeden Service mit den Ablaufdaten (End of Life, EOL).

Wenn eine Service-Version innerhalb von drei Monaten nach dem Ende der Nutzungsdauer veröffentlicht wird, wird im Bereitstellungsprotokoll eine Benachrichtigung angezeigt.
Wenn das Ende der Nutzungsdauer in der Vergangenheit liegt, wird eine Warnmeldung angezeigt.

Um die Speichersicherheit aufrechtzuerhalten, aktualisieren Sie installierte Softwareversionen, bevor sie das Ende der Nutzungsdauer erreichen. Die EOL-Daten können in der eol.yaml-Datei ece-tools“ eingesehen .

Zu OpenSearch migrieren

WARNING

Elasticsearch 7 und höher wird für Adobe Commerce in der Cloud-Infrastruktur nicht unterstützt. Adobe Commerce 2.4.4 und höher unterstützt den OpenSearch-Service.

Informationen zu Adobe Commerce Version 2.4.4 und höher finden Sie unter Einrichten des OpenSearch-Service.

Service-Version ändern

Sie können die installierte Version des Services aktualisieren, um die Kompatibilität mit der Adobe Commerce-Version zu gewährleisten, die in Ihrer Cloud-Umgebung bereitgestellt wird.

Ein Downgrade der Service-Version für einen installierten Service ist nicht direkt möglich. Sie können jedoch einen Service mit der erforderlichen Version erstellen. Siehe Downgrade-Service-.

Upgrade der installierten Dienstversion

Sie können die installierte Version des Services aktualisieren, indem Sie die Service-Konfiguration in der services.yaml-Datei aktualisieren.

Ändern Sie den type für den Dienst in der .magento/services.yaml:

Ursprüngliche Service-Definition

code language-yaml
`mysql: type: mysql:11.8 disk: 2048`

Aktualisierte Service-Definition

code language-yaml
`mysql: type: mysql:12.3 disk: 5120`

Code-Änderungen hinzufügen, übertragen und per Push übertragen.

code language-bash
`git add .magento/services.yaml`

code language-bash
`git commit -m "Upgrade MySQL from MariaDB 11.8 to 12.3."`

code language-bash
`git push origin <branch-name>`

Version herunterstufen

Ein Downgrade eines installierten Services ist nicht direkt möglich. Sie haben zwei Möglichkeiten:

Benennen Sie einen vorhandenen Service mit der neuen Version um. Dadurch werden der vorhandene Service und die Daten entfernt und ein neuer hinzugefügt.
Erstellen Sie einen Service und speichern Sie die Daten aus dem vorhandenen Service.

Wenn Sie die Service-Version ändern, müssen Sie die Service-Konfiguration in der services.yaml-Datei aktualisieren und die Beziehungen in der .magento.app.yaml-Datei aktualisieren.

Herunterstufen einer Dienstversion durch Umbenennen eines vorhandenen Dienstes

Benennen Sie den vorhandenen Service in der .magento/services.yaml um und ändern Sie die Version.

note warning
WARNING
Beim Umbenennen eines vorhandenen Dienstes wird dieser ersetzt und alle Daten werden gelöscht. Wenn Sie die Daten beibehalten müssen, erstellen Sie einen Service, anstatt den vorhandenen Service umzubenennen.

Um beispielsweise die MariaDB-Version für den Service mysql von Version 10.4 auf 10.3 herunterzustufen, ändern Sie die vorhandene Konfiguration service-id und type.

services.yaml

code language-yaml
`mysql: type: mysql:10.4 disk: 5120`

Neue services.yaml

code language-yaml
`mysql2: type: mysql:10.3 disk: 5120`

Aktualisieren Sie die Beziehungen in der .magento.app.yaml.

.magento.app.yaml Originalkonfiguration

code language-yaml
`relationships: database: "mysql:mysql"`

Aktualisierte .magento.app.yaml

code language-yaml
`relationships: database: "mysql2:mysql"`

Code-Änderungen hinzufügen, übertragen und per Push übertragen.

Herunterstufen eines Services durch Erstellen eines Services

Fügen Sie der services.yaml-Datei für Ihr Projekt eine Service-Definition mit der heruntergestuften Versionsspezifikation hinzu. Siehe mysql2 im folgenden Beispiel:

services.yaml

code language-yaml
`mysql: type: mysql:10.4 disk: 5120 mysql2: type: mysql:10.3 disk: 5120`

Um den neuen Service zu verwenden, ändern Sie die Beziehungskonfiguration in der .magento.app.yaml.

.magento.app.yaml Originalkonfiguration

code language-yaml
`relationships: database: "mysql:mysql"`

Neue .magento.app.yaml

code language-yaml
`relationships: database: "mysql2:mysql"`

Code-Änderungen hinzufügen, übertragen und per Push übertragen.

recommendation-more-help

commerce-on-cloud-help-cloud-guide