deployer

EXT:deployer

Allgemeine Informationen

URL des Repositorys: Auf MaxServ Stash

Autoren:

• Arno Schoon - arno@maxserv.com

Beschreibung

TYPO3 CMS Utilities zur einfachen Bereitstellung einer Instanz, z.B. im DTAP-Kontext. Diese Erweiterung ist ein Nachfolger von EXT:max_ci, aber die Kompatibilität zu alten CMS-Versionen wurde entfernt und wie immer ist dieses Projekt bei weitem nicht vollständig :).

Hinweis für TYPO3 CMS >=6.2.10, <7

Diese Erweiterung verwendet mehrere Bibliotheken, die über Composer geladen werden, um es TYPO3 zu ermöglichen, die Klassen aus den Paketen zu verwenden, in denen der CMS die erzeugten Autoload-Dateien von Composer verwenden muss. Diese Datei sollte sich unter %webRoot%/Packages/Libraries/autoload.php befinden.

Verwendung der Befehlszeile

$ TYPO3_COMPOSER_AUTOLOAD=1 php ./typo3/cli_dispatch.phpsh

Oder in .htaccess

SetEnv TYPO3_COMPOSER_AUTOLOAD 1

Laden der Klasse

Um die Zuverlässigkeit von TYPO3 6.2.x zu verbessern, wurde TYPO3 6.2.10 um den composer Class Loader erweitert. Klassen aller erforderlichen TYPO3-Erweiterungen werden seit dieser Version vom composer Class Loader geladen.

Erweiterte Klassenladeeinstellungen

Es ist möglich, ein beliebiges composer-Paket eines Drittanbieters in Ihrem Root composer.json zu benötigen, aber TYPO3 wird die Klassen dieser Pakete normalerweise nicht zur Verfügung stellen. Allerdings ist es auch seit TYPO3 6.2.10 möglich, Klassen aller composer-Pakete verfügbar zu haben, wenn die Umgebungsvariable TYPO3_COMPOSER_AUTOLOAD in Ihrem Webserver (oder auf der Kommandozeile) gesetzt ist. In diesem Fall können alle Klassen von composer-Paketen automatisch in Ihre TYPO3-Installation geladen werden.

Außerdem können Sie Klassenladeinformationen für Erweiterungen und den Kern in Ihrem Root composer.json angeben, mit dem Vorteil z.B. einer zuverlässigeren Bereitstellung, da der alte Klassenlader nicht mehr im Einsatz ist.

Siehe https://wiki.typo3.org/Composer

Verwendung

Für einen schnellen Überblick über die verfügbaren CLI-Befehle können Sie den Befehl help verwenden

$ php./typo3/cli_dispatch.phpsh extbase Hilfe

Aktivieren/Deaktivieren von Domänendatensätzen in Abhängigkeit vom Umgebungsschlüssel

$ php./typo3/cli_dispatch.phpsh extbase deployer:sysdomain:toggle --environment-key=D

Flush aller Caches, die das interne Caching-Framework verwenden

$ php./typo3/cli_dispatch.phpsh extbase deployer:cachemanager:flushall

Solr-Verbindungen initialisieren (wenn EXT:solr geladen ist)

$ php./typo3/cli_dispatch.phpsh extbase deployer:solr:initializeconnections

Als Bonus können die von dieser Erweiterung bereitgestellten Befehle direkt in den Scheduler von TYPO3 CMS eingefügt werden. So können Sie beispielsweise die Solr-Index-Warteschlange ab und zu initialisieren.

Ausführen mehrerer Befehle in einer bestimmten Reihenfolge

Während das Aussetzen mehrerer unabhängiger Befehle hilfreich sein kann, um bestimmte Aufgaben zu automatisieren, ist es eine gewaltige Aufgabe, jeden Befehl von Hand auszuführen (in der Reihenfolge, die ein System benötigt). Das Hauptziel von EXT:max_ci war es, diesen Teil zu erleichtern, daher ist in diesem Paket ein Skriptbefehl implementiert. Skripte sind nichts anderes als eine Sammlung von Aufgaben/Befehlen, die in einer bestimmten Reihenfolge ausgeführt werden sollen. Jeder Aufgabe in einem Skript kann eine bestimmte Priorität zugewiesen werden, um sicherzustellen, dass die Reihenfolge der Ausführung eingehalten wird.

$ php./typo3/cli_dispatch.phpsh extbase deployer:script:run --script=post-deployed

Skripte können in $GLOBALS [EXTCONF][deployer][Skripte] konfiguriert werden. Jedes Skript kann beliebige Identifikatoren von "Extbase Command Controllers" enthalten. Mit dieser einfachen Schnittstelle können Sie jedem Skript eine bestimmte Aufgabe hinzufügen, so dass eine bestimmte Erweiterung z.B. in das Post-Deployment-Skript eingebunden werden kann, um bestimmte Aktionen auszuführen, die ein CI- oder CD-Rechner nicht kennen/sich Sorgen machen muss.

Dieses Paket enthält ein integriertes Post-Deployment-Skript, aber Sie können beliebige Skripte von jedem Ort in TYPO3 CMS erstellen, erweitern Sie einfach das Konfigurationsarray. Unten ist ein kleines Beispiel für die Konfiguration, die für das gebündelte Post-Deployment-Skript verwendet wird, Sie sollten einen genaueren Blick in ext_localconf.php im Stammverzeichnis dieser Erweiterung werfen.

$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['deployer']['scripts']['post-deploy'][]] = array(
    Priorität' => 40,
    Befehl' =>'deployer:solr:initializeconnections'
);

$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['deployer']['scripts']['post-deploy'][]] = array(
    Priorität' => 90,
    Befehl' =>'deployer:sysdomain:toggle',
    Argumente' => array(
        environmentKey' => 'P' =>'P'
    )
);

Wie Sie sehen können, kann ein Array mit Standardargumenten aus der Konfiguration gesetzt werden. Vor der Ausführung eines Skripts werden jedoch alle Parameter des CLI-Aufrufs "outside" zu den Argumenten für den Befehl hinzugefügt. Das bedeutet, dass Sie die Standardargumente überschreiben können, indem Sie die Option einfach an den Skript-Aufruf übergeben.

$ php./typo3/cli_dispatch.phpsh extbase deployer:script:run --script=post-deploy --environment-key=D

Das obige Beispiel führt das Post-Deployment-Skript aus, aber anstatt environmentKey=P zu verwenden, wird die Option --environment-key dazu führen, dass environmentKey=D verwendet wird.

Generierung von LocalConfiguration.php basierend auf ApplicationContext

Unmittelbar nach der Bereitstellung der TYPO3-Anwendung muss die instanzenspezifische Konfiguration in LocalConfiguration.php hinzugefügt werden, damit TYPO3 ausgeführt werden kann. Spezifische Informationen wie Datenbank-Anmeldeinformationen (die sich wahrscheinlich von Instanz zu Instanz unterscheiden) können zu einem Fehler in Ihrer LocalConfiguration.php oder AdditionalConfiguration.php führen (z.B. bei Verwendung von case/switch).

Um zu verhindern, dass instanzspezifische Konfiguration Ihr Repository überlastet, wird ein CLI-Befehl zu deployer hinzugefügt, um eine LocalConfiguration.php zu erzeugen, die auf dem Inhalt mehrerer YAML-Dateien im Verzeichnis Configuration/ im Stammverzeichnis Ihres Projekts basiert.

$ php./Web/typo3conf/ext/deployer/Scripts/CliDispatch.php deployer:localconfiguration:build

Um das Bootstrapping von TYPO3 in diesem Low-Level-Kontext zu ermöglichen (LocalConfiguration.php ist an dieser Stelle nicht verfügbar), verwenden wir einen benutzerdefinierten CLI-Einstiegspunkt, der den Dispatch-Code von EXT:typo3_console verwendet.

HINWEIS: Das Bootstrapping könnte fehlschlagen, wenn Spuren einer alten LocalConfiguration.php vorhanden sind, also stellen Sie sicher, dass diese Datei empfohlen wird.

Caches.yaml, Database.yaml und Generic.yaml

Vorerst kann die in die genannten Container getrennte Konfiguration dem Konfigurationsverzeichnis hinzugefügt werden.

Caches.yaml kann verwendet werden, um ein bestimmtes Cache-Backend für die Caching-Konfiguration in TYPO3 zu konfigurieren

# Caches.yaml
-
  backend: TYPO3\CMS\Core\Cache\Backend\RedisBackend\RedisBackend
  optionen:
    datenbank: 1
  name: cache_hash

Database.yaml kann verwendet werden, um die Anmeldeinformationen zu konfigurieren, die für die Verbindung zum Datenbankserver erforderlich sind

# Database.yaml
verbindung:
  gastgeber: localhost
  benutzername: %Datenbank_Benutzername%%
  passwort: %Datenbank_Passwort%
  datenbank: %database_name%% Datenbank

Generic.yaml kann verwendet werden, um eine bestimmte Konfiguration für TYPO3 festzulegen, wie z.B. die Datei-/Ordnerrechte bei Verwendung des Datei-Moduls im BE

# Generic.yaml
developer_ips:
  - 127.0.0.1
  - ::1
date_time:
  zeitzone: Europa/Amsterdam
file_system_permissions:
  create_group: www-data
  file_create_mask: "0664"
  folder_create_mask: "0775"

Zusätzlich kann error_handling für einen bestimmten Kontext überschrieben werden

# Development/Generic.yaml
error_handling:
  db_debug: true
  deprecation_log: true
  display_errors: true

Mail.yaml ist eine optionale Datei, um den Transport ausgehender E-Mails für eine bestimmte Umgebung zu ändern

smtp: true
transport:
  benutzername: {$username}
  passwort: {$password}
  server: mail.example.com
  verschlüsseln: tls

Oder im Entwicklungskontext können Sie Roh-E-Mails in einer einfachen Protokolldatei speichern

mbox: true
datei: /var/log/mbox/typo3.log

Bündel-Konfigurationsoption in Settings.yaml

Die Konfiguration der Datenbank-Anmeldeinformationen und des Cache-Backends kann auch aus einer einzigen Datei erfolgen. Die verschiedenen Abschnitte dieser Datei folgen den gleichen Format- und Validierungsregeln wie die oben genannten.

# Settings.yaml
datenbank:
  verbindung:
    gastgeber: localhost
    benutzername: %Datenbank_Benutzername%%
    passwort: %Datenbank_Passwort%
    datenbank: %database_name%% Datenbank
caches:
  -
    backend: TYPO3\CMS\Core\Cache\Backend\RedisBackend\RedisBackend
    optionen:
      datenbank: 1
    name: cache_hash

Laden der Konfiguration für einen bestimmten Kontext

Standardmäßig bootet TYPO3 über einen Production-Kontext, dieser Kontext kann über die Umgebungsvariable TYPO3_CONTEXT geändert werden. Offizielle TYPO3-Dokumente.

Dies wird auch beim Laden der Konfiguration aus dem Projektstamm verwendet. Bei der Ausführung im Produktionskontext werden die Ordner Configuration and Configuration/Production nach unterstützten YAML-Dateien durchsucht.

Wenn eine Instanz als Entwicklungsrechner konfiguriert werden soll, verwenden Sie TYPO3_CONTEXT=Development, um Konfiguration und Konfiguration/Entwicklung zu laden.

$ export TYPO3_CONTEXT=Entwicklung && php./Web/typo3conf/ext/deployer/Scripts/CliDispatch.php deployer:localconfiguration:build

Ein Anwendungskontext kann auch einen beliebigen Subkontext enthalten, z.B. Produktion/Staging.

$ export TYPO3_CONTEXT=Produktion/Staging && php./Web/typo3conf/ext/deployer/Scripts/CliDispatch.php deployer:localconfiguration:build

Beim Erstellen einer Konfigurationsdatei werden YAML-Dateien aus Configuration, Configuration/Production und Configuration/Production/Production/Staging geladen und zusammengeführt.

RollBack

Nach einem erfolgreichen Build und Deployment möchten Sie möglicherweise die Ressourcen, die nicht unter der Source Control stehen, für die Verteilung auf anderen Plattformen exportieren. Um dies zu erreichen, stellen wir die folgenden Aktionen zur Verfügung:

Datenbank-Dump erstellen

$ php typo3/cli_dispatch.phpsh extbase deployer:databasedump:create --build=v1

• Führt ein Shell-Skript aus, das die TYPO3-Datenbankkonfiguration in Verbindung mit mysqldump verwendet, um ein Tarball-Artefakt zu erstellen, das .sql-Dateien für jede einzelne Tabelle in der Datenbank enthält, außer für Cache-Tabellen.
• Platziert das Artefakt in /tmp/deployer/dumps/%%%DATABASENAME%%%-build%%BAMBOO_BUILD%%.tar.gz

Datenbank-Dump importieren

Nachdem eine Datenbank mit dem vorherigen Befehl gelöscht wurde, kann Bamboo das Artefakt sammeln und an andere Server verteilen. Danach können Sie mit diesem Befehl diesen Speicherauszug in die aktuelle Datenbank importieren.

$ php typo3/cli_dispatch.phpsh extbase deployer:databasedump:import --artifact=fully-qualified-path-to-file

• Importiert den im Parameter --artifact angegebenen Speicherauszug in die aktuelle Datenbank
• Entfernt die Datei nach Abschluss des Imports, um den Server sauber zu halten.

Nach der RollBack-Bereinigung

Das Hinterlassen von Speicherauszügen und anderen Bereitstellungsdateien auf dem Server kann potenziell gefährlich sein, also stellen Sie sicher, dass Sie nachher aufräumen, wenn Bamboo fertig ist.

$ php typo3/cli_dispatch.phpsh extbase deployer:databasedump:clear

• Bereinigt alle zuvor erstellten Datenbank-Dumps und möglichen .sql-Reste.