Direkt zum Inhalt

Mit der Einführung von Drupal 8 gab es einige grundlegende Änderungen, die das Deployment deutlich vereinfachen. Dazu gehört beispielsweise die komplette Überarbeitung des Konfigurations-Managements von Drupal: Inhalt und Konfiguration wurden klar voneinander getrennt und es wurde die Möglichkeit geschaffen, Konfiguration in YAML-Dateien abzuspeichern. Die Konfiguration wird zwar noch immer in der Datenbank gecached, durch den dateibasierten Ansatz können Konfigurationsänderungen nun aber einfach exportiert bzw. importiert werden. 

Wenn man eine einheitliche Konfiguration über alle Installationen einer Drupal Webseite hinweg benötigt, funktioniert die Konfigurationsverwaltung von Drupal 8 hervorragend. Man steht jedoch vor einem Problem, wenn man bestimmte Module auf lokalen Installationen anders konfigurieren möchte, als auf dem Live- oder Staging-System und vice versa. Denn unabhängig davon, ob sich die Konfiguration der verschiedenen Installationen voneinander unterscheidet oder nicht, existiert entweder dieselbe oder veränderte Version der Konfiguration in allen vorhandenen Verzeichnissen. Das bedeutet, dass bei jedem Deployment alle Konfigurationsdateien miteinander verglichen werden müssen. Dieser Prozess nimmt Zeit in Anspruch und ist zudem fehleranfälliger. Außerdem existiert dieselbe Datei mehrfach im System.

Die Einführung von “Config Split” bietet nun den Vorteil, dass eine Konfigurationsdatei nur dann ein weiteres Mal im Split abgelegt werden muss, wenn sie sich vom Sync-Verzeichnis unterscheidet. Wenn im derzeit aktiven Split also eine Konfiguration vorhanden ist, hat dieser Vorrang und wird verwendet, ansonsten wird die Konfiguration aus dem sync-Verzeichnis verwendet.

Im Folgenden möchten wir Ihnen eine Anleitung geben, mit der Sie eine saubere Konvertierung von config directories zu Config Split durchführen können. Unser Beispiel enthält drei Ausgangsverzeichnisse: sync, staging und live. 

Ziel ist, dass nach der Konvertierung umgebungsübergreifende Konfiguration im Sync-Verzeichnis gespeichert wird, während umgebungsspezifische Konfigurationen im entsprechenden Split abgelegt werden.

2. Das System vorbereiten

Als aller erstes sollten Sie ihr System auf den neuesten Stand bringen. Stellen Sie also sicher, dass alle vorhandenen Konfigurationsverzeichnisse aktuell sind, dass Datenbank-Updates durchgeführt wurden etc..

2.1 Die settings.local.php 

Ihre settings.local.php sollte wie folgt aussehen:

Da wir config_split im nächsten Schritt installieren und einige Einstellungen vornehmen müssen, sollten alle Split-Konfigurationen erst einmal auskommentiert sein.

2.2 Config Split installieren

Bevor wir mit dem Konvertierungsprozess beginnen, lohnt es sich einige Begriffe zu klären.

Blacklist: In der Blacklist befinden sich Konfigurationselemente, die explizit vom betroffenen Split verwaltet werden. Diese Elemente werden aus dem Sync-Verzeichnis entfernt. Das bedeutet, dass Sie diese Konfiguration in einem oder mehreren Splits speichern können, jedoch nicht im Sync-Verzeichnis.

Greylist: Konfigurationselemente aus der Greylist werden im Gegensatz zur Blacklist nicht aus dem Sync-Verzeichnis entfernt. Wenn eine Konfiguration im derzeit aktiven Split vorhanden ist, hat dieser Vorrang und wird verwendet. Wenn keine Konfiguration im gerade aktiven Split vorhanden ist, wird die Konfiguration aus dem Sync-Verzeichnis verwendet.

Wenn alle nötigen Updates durchgeführt wurden, kann als nächstes config_split installiert und aktiviert werden. 

Anschließend müssen einige Einstellung vorgenommen werden. Die Moduleinstellungen finden Sie unter: Configuration -> Development -> Configuration Split settings.

Klicken Sie auf “Add Configuration Split setting” und nehmen Sie folgende Einstellungen für “live” vor.

  • Ordner: ../config/default/splits/live
  • Status: Nicht aktiv

Achten Sie darauf, dass der Maschinenname des erstellten Splits mit dem Verzeichnis in Ihrem System übereinstimmt.

Wiederholen Sie dasselbe für “staging” und “development”:

  •  ../config/default/splits/staging
  •  ../config/default/splits/dev

Exportieren Sie nun die neue config_split Konfiguration indem Sie “drush cex sync -y” ausführen.

3. “Live” Konfiguration erstellen

3.1 live config_split Konfiguration

Hier heißt es alle Module zu bestimmen, die nur auf dem Live-System genutzt werden. 

Dazu vergleichen Sie am besten die Verzeichnisse “sync” und “live”.

core.extension.yml:

  • Kopieren Sie die Module config_split und config_filter aus der core.extension.yml von sync nach live
  • Bestimmen Sie nun alle Module die es für live, aber nicht für sync gibt, und fügen diese in die config_split.config_split.live.yml unter “modules” hinzu
  • Jetzt bestimmen Sie alle Module die es für sync gibt, aber nicht für live und fügen diese in die config_split.config_split.dev.yml unter “modules” hinzu
  • Zur “Greylist” fügen Sie alle Dateien hinzu, die Unterschiede aufweisen

Hier sehen Sie ein Beispiel, wie Ihre config_split.config_split.live.yml aussehen könnte:

3.2 Befüllen des Split-Verzeichnisses “live”

  • Entfernen Sie in Ihrer settings.local.php alle $config_directories außer “sync”.
  • Kopieren Sie die config_split*.yml Dateien in Ihr “live”-Verzeichnis
  • Führen Sie einen Config import aus: drush cim -y
  • Erzwingen Sie nun einen Live-Split indem Sie $config['config_split.config_split.live']['status'] = TRUE;  einkommentieren. Alle anderen Splits bleiben auskommentiert
  • Ändern Sie das Zielverzeichnis der $config_directories[‘sync’] von “sync” zu “live”:

Führen Sie nun folgende Schritte durch: 

  • Erstellen Sie die das “live” Split-Verzeichnis: /config/default/splits/live
  • Führen Sie: cr; drush csex -y aus
  • Verschieben Sie nun alle Dateien, die sich in der Greylist befinden (manuell) vom “live”-Verzeichnis ins Split-Verzeichnis “live”.
  • Das Verzeichnis /config/default/splits/live sollte jetzt mit der "Live"-Konfiguration befüllt sein
  • Ein “cr; drush cim” sollte keine Änderungen aufweisen
  • Jetzt werden alle Splits in der settings.local.php wieder auskommentiert

4. “staging” Konfiguration erstellen

Wiederholen Sie die Punkte von oben, mit der Ausnahme, dass Sie nun "live" durch “staging” ersetzen. 

5. “dev” Konfiguration erstellen

Die Split-Konfiguration "dev" haben Sie in den vorherigen Schritten bereits eingerichtet. 

5.1 Befüllen des Split-Verzeichnisses “dev”

  • Stellen Sie sicher, dass Ihre settings.local.php wie folgt aussieht:
  • Führen Sie ein “cr; drush cim -y” aus
  • Erzwingen Sie nun einen Dev-Split indem Sie $config['config_split.config_split.dev']['status'] = TRUE;  einkommentieren . Alle anderen Splits bleiben auskommentiert
  • Erstellen Sie die das Split-Verzeichnis “dev”: /config/default/splits/dev
  • Führen Sie ein “cr; drush csex -y” aus
  • Das Verzeichnis /config/default/splits/dev sollte jetzt mit der "dev"-Konfiguration befüllt sein
  • Aus der core.extension.yml sollten alle Module, die es nur für dev gibt, automatisch entfernt worden sein
  • Das Ausführen von “cr; drush cim” sollte keinerlei Änderungen aufweisen

6 Konvertierung Abschließen

  • Entfernen Sie nun die Live- and Staging-Verzeichnisse
  • Ihre settings.local.php sollte nun folgendermaßen aussehen:
  • Führen Sie “cr; drush cim -y” aus

Jetzt können Sie die Änderungen deployen, die serverseitigen Einstellungen vornehmen und Config Split in Betrieb nehmen.

7 Fazit & Zusammenfassung

Wie Sie in unserem Beispiel sehen können, sind einige Schritte für die Konvertierung zur Nutzung von config_split nötig. Wir möchten an dieser Stelle aber betonen, dass sich der Aufwand für die Konvertierung lohnt, da Config Split viele Vorteile mit sich bringt. Wenn man die Konvertierung einmal abgeschlossen hat, spart sich das Team in der Arbeit mit verschiedenen Konfigurationen viel Aufwand. Auch eine vollständige Automatisierung des Test-Setups und des Deployments wird dadurch erst ermöglicht.

Sie haben noch eine veraltete Drupal Version? Hier erfahren Sie alles über das Drupal 9 Upgrade