Wie implementiere ich Continuous Deployment in Angular-, PHP API- und Ansible-Projekten?

Ich arbeite an einem Angular2-Projekt mit Yii2 (PHP / MySQL) als API-Punkt. Wir müssen die Angular-App in verschiedenen Sprachen für verschiedene Kunden bereitstellen (mithilfe der AOT-Kompilierung aus Angular-CLI).

Was ist der beste Weg, um dies zu erreichen? Ich schaue auf Docker oder Ansible (-container), damit dies funktioniert. Die Beispiele beziehen sich jedoch hauptsächlich auf ein 1: 1-Setup. Aber ich würde ein 1: n brauchen, so etwas wie:

deploy app-de new_costomer prod_server

Wenn eine neue Version der App verfügbar ist, möchte ich außerdem das gesamte Netzwerk mit der neuen App aktualisieren (dies erfordert das Hochladen des kompilierten src / -Ordners AOT und der DB-Migrationsskripte auf der Yii2-Seite).

Im Idealfall würde es so etwas tun wie:

deploy update network-all prod_server

Irgendwelche Ideen?

Zur Verdeutlichung: Ich habe eine Reihe von Kunden, jeder Kunde sollte seinen eigenen Container bekommen (Docker, über Ansible-Container). Es gibt das AOT-kompilierte Angular-Zeug (nur JS) und das PHP-Backend mit MySQL.

Jeder Kunde erhält dieses Setup auf einem Server (also 3 Kunden = 3 Docker-Container mit Angular + PHP + MySQL).

Wir pushen häufig Updates für Angular und PHP (dh der gesamte DIST-Ordner muss hochgeladen werden oder zumindest ein Diff, Migrationsskripte für das PHP / MySQL-Backend müssen ausgeführt werden usw.).

Und das von einem Befehl aus (weil ich natürlich nicht SSH in jedem Container haben möchte, um das alles halb manuell zu erledigen).

Da ich diese Art von Setup noch nie zuvor gemacht habe, möchte ich einige Ideen bekommen, wie dies mit Dingen wie Ansible (oder ähnlichem) erreicht werden kann.

Nehmen wir an, Sie haben das folgende Szenario: Sie haben viele Kunden, aber die meisten verwenden genau dieselbe App, mit Ausnahme einiger Konfigurationsänderungen. Sie möchten, dass jeder Ihrer Kunden so schnell wie möglich die neueste App erhält.

Wenn dies Ihr Szenario ist, versuchen Sie, alles, was zwischen den Apps unterschieden werden muss, zu einer Konfigurationsänderung zu machen. Sie erstellen einen (oder einen Satz) Docker-Container, der jeden Ihrer Kunden basierend auf der angegebenen Konfiguration verarbeiten kann. Bei der Bereitstellung geben Sie dann einfach die richtigen Konfigurationen für diesen Container für jeden Ihrer Kunden an.

Der Vorteil dieses Ansatzes besteht darin, dass bei einem neuen Kunden keine massiven Gemeinkosten anfallen. Sie generieren ihre Konfiguration, erstellen die neuen Server, fügen einige Einträge zu einer Inventardatei hinzu und bei der nächsten Bereitstellung werden sie auch dort angezeigt. Je besser Ihre CD-Pipeline eingerichtet ist, desto mehr können Sie diesen Prozess automatisieren.

Wie würde der Fluss im Allgemeinen aussehen:

1. Sie haben Ihre Anwendungscodebasis, die alle Ihre Kunden bedienen kann
2. Sie erstellen den Docker-Container für Ihre Anwendung (einen für das Frontend, einen für das Backend, möglicherweise einige weitere unterstützende).
3. Sie haben ein Bereitstellungsskript, das eine Konfigurationsdatei verwendet, um zu bestimmen, wo und was bereitgestellt werden soll.
4. Sie führen dieses Bereitstellungsskript aus. Es geht über alle Ihre Kunden und stellt einfach die neueste Version Ihrer App mit der entsprechenden Konfiguration bereit.

Wenn Sie einen neuen Kunden haben, müssen Sie nur die Bereitstellungskonfigurationsdatei ändern. Wenn Sie ansible verwenden, müssen Sie höchstwahrscheinlich Ihr Inventar und Ihre Vars-Datei ändern. Angenommen, Sie haben einen neuen Kunden, der möchte, dass die App unter spanischem Gebietsschema ausgeführt wird und Zugriff auf die Beta-Funktionen hat. Die Konfiguration dieses Kunden würde vielleicht so aussehen:

config.js:

SETTINGS = { locale: 'es', beta: true };

config.php:

define('CUSTOMER_LOCALE','es');
define('CUSTOMER_BETA','true');

Sie stellen dann sicher, dass Ihr Container während der Bereitstellung diese Dateien beim Start bereitstellt.