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

7

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.

Axtho
quelle
Es ist nicht sehr klar, wonach Sie fragen. Es klingt so, als ob Ihr allgemeines Problem die Internationalisierung ist. Dies ist normalerweise ein Problem beim Anwendungsdesign und kein Bereitstellungsproblem. Sie könnten verschiedene Sprachen als separate Container bereitstellen, aber ich bin mir nicht sicher, ob dies die einfachste oder effizienteste Lösung wäre.
Dave Swersky
2
Sieht aus wie eine kopierte Frage von einer anderen Site, einschließlich der SE-Links und -Symbole rund um die Frage. Korrigieren Sie die Formatierung und machen Sie diese Frage klar, um sie zu verstehen und zu beantworten.
Evgeny
1
Hey @Evgeny, ja, es wurde von meinem Beitrag auf Stackexchange kopiert, wo jemand dies kommentierte und mir sagte, ich solle es hier übernehmen. Daher die Vervielfältigung. Ich habe das Problem oben aktualisiert.
Axtho
@axtho Von Cross-Posting wird im Allgemeinen abgeraten. Sie sollten den Post entweder auf dieser Site oder auf Stack Overflow haben, nicht auf beiden. Das ist wahrscheinlich der Grund, warum Ihre Frage nicht sehr gut aufgenommen wurde.
Aurora0001
Besser bei der Bearbeitung, geben Sie nicht "Bearbeiten" an, wenn Sie die Revision betrachten. Wir können wissen, was hinzugefügt wurde, und in der Überprüfungswarteschlange werden die Änderungen hervorgehoben. Abstimmung zur Wiedereröffnung
Tensibai

Antworten:

7

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.

SztupY
quelle
Vielen Dank. Das ist hauptsächlich das, was ich brauche und ein guter Ausgangspunkt. Aus Neugier: Warum würden Sie einem Kunden viele Docker-Bilder vorschlagen?
Axtho
@axtho nicht obligatorisch, obwohl es normalerweise eine gute Praxis ist, jedes Unternehmen (Frontend, Backend, Datenbank usw.) in einen separaten Container zu trennen, damit sie unabhängig voneinander bereitgestellt und skaliert werden können
SztupY