Zunächst eine kleine Theorie. Was ?
Vereinfacht ausgedrückt soll dieses Dokument die Entwicklung von SaaS-Anwendungen vereinfachen und dabei helfen, Entwickler und DevOps-Ingenieure über die Probleme und Praktiken zu informieren, die bei der Entwicklung moderner Anwendungen am häufigsten auftreten.
Das Dokument wurde von den Entwicklern der Heroku-Plattform erstellt.
Die Zwölf-Faktor-App kann auf Anwendungen angewendet werden, die in jeder Programmiersprache geschrieben sind und eine beliebige Kombination von Unterstützungsdiensten (Datenbanken, Nachrichtenwarteschlangen, Caches usw.) verwenden.
Kurz zu den Faktoren, auf denen diese Methodik basiert:
- Codebasis – Eine Codebasis, die in der Versionskontrolle verfolgt wird – mehrere Bereitstellungen
- Abhängigkeiten – Abhängigkeiten explizit deklarieren und isolieren
- Konfiguration – Konfiguration im Runtime speichern
- Unterstützungsdienste – Betrachten Sie Unterstützungsdienste als Plug-in-Ressourcen
- Erstellen, veröffentlichen, ausführen – Trennen Sie die Montage- und Ausführungsschritte strikt
- Prozesse – Führen Sie die Anwendung als einen oder mehrere zustandslose Prozesse aus
- Port-Bindung – Dienste über Portbindung exportieren
- Parallelität – Skalieren Sie Ihre Anwendung mithilfe von Prozessen
- Verfügbarkeit – Maximieren Sie die Zuverlässigkeit durch schnelles Hochfahren und sauberes Herunterfahren
- Parität zwischen Anwendungsentwicklung und Betrieb – Halten Sie Ihre Entwicklungs-, Staging- und Produktionsumgebungen so ähnlich wie möglich
- Protokollierung – Zeigen Sie das Protokoll als Ereignisstrom an
- Verwaltungsaufgaben – Führen Sie Verwaltungs-/Verwaltungsaufgaben mithilfe von Ad-hoc-Prozessen durch
Weitere Informationen zu den 12 Faktoren erhalten Sie in den folgenden Quellen:
- - muss gelesen werden
- — offizielle Übersetzung
- - Ein neuer Blick auf die 12 Faktoren mit dem Ziel, sie zu verbessern.
Was ist Blue-Green-Bereitstellung?
Die Blau-Grün-Bereitstellung ist eine Methode zur Bereitstellung einer Anwendung Produktion und zwar so, dass der Endkunde keine Änderungen seinerseits sieht. Mit anderen Worten: Bereitstellung einer Anwendung mit Null Ausfallzeit.
Das klassische BG-Deploy-Schema sieht wie im Bild unten gezeigt aus.
- Zu Beginn gibt es zwei physische Server mit absolut demselben Code, derselben Anwendung und demselben Projekt sowie einen Router (Balancer).
- Der Router leitet alle Anfragen zunächst an einen der Server (grün).
- In dem Moment, in dem Sie es erneut freigeben müssen, wird das gesamte Projekt auf einem anderen Server aktualisiert (blau), die derzeit keine Anfragen bearbeitet.
- Nachdem der Code aktiviert ist blau Wenn der Server vollständig aktualisiert ist, erhält der Router einen Befehl zum Umschalten grün auf blau Server.
- Jetzt sehen alle Clients das Ergebnis des ausgeführten Codes blau Server.
- Für einige Zeit, grün Der Server dient als Sicherungskopie im Falle einer erfolglosen Bereitstellung blau Server und im Falle von Fehlern und Fehlern schaltet der Router den Benutzerfluss zurück grün Server mit der alten stabilen Version und der neue Code wird zur Überarbeitung und zum Testen gesendet.
- Und am Ende des Prozesses wird es auf die gleiche Weise aktualisiert grün Server. Und nach der Aktualisierung schaltet der Router den Anforderungsfluss wieder um grün Server.
Es sieht alles sehr gut aus und auf den ersten Blick sollte es keine Probleme damit geben.
Da wir jedoch in der modernen Welt leben, passt die Option der physischen Schaltung, wie sie im klassischen Schema angegeben ist, nicht zu uns. Notieren Sie die Informationen vorerst, wir werden später darauf zurückkommen.
Schlechter und guter Rat
Haftungsausschluss: Die folgenden Beispiele zeigen die Dienstprogramme/Methoden, die ich verwende. Sie können absolut alle Alternativen mit ähnlichen Funktionen verwenden.
Die meisten Beispiele werden sich auf die eine oder andere Weise mit der Webentwicklung (das ist eine Überraschung) mit PHP und Docker überschneiden.
Die folgenden Absätze bieten eine einfache praktische Beschreibung der Verwendung von Faktoren anhand konkreter Beispiele. Wenn Sie mehr Theorie zu diesem Thema erhalten möchten, folgen Sie den Links oben zur Originalquelle.
1. Codebasis
Verwenden Sie FTP und FileZilla, um Dateien einzeln auf die Server hochzuladen. Speichern Sie den Code nur auf dem Produktionsserver.
Das Projekt sollte immer über eine einzige Codebasis verfügen, d. h. der gesamte Code stammt aus einer einzigen Git Repository. Server (Produktion, Staging, Test1, Test2...) verwenden Code aus Zweigen eines gemeinsamen Repositorys. Auf diese Weise erreichen wir Codekonsistenz.
2. Abhängigkeiten
Laden Sie alle Bibliotheken in Ordnern direkt in das Stammverzeichnis des Projekts herunter. Nehmen Sie Aktualisierungen vor, indem Sie einfach den neuen Code in den Ordner mit der aktuellen Version der Bibliothek übertragen. Installieren Sie alle erforderlichen Dienstprogramme direkt auf dem Hostserver, auf dem 20 weitere Dienste ausgeführt werden.
Ein Projekt sollte immer eine klar verständliche Liste von Abhängigkeiten haben (mit Abhängigkeiten meine ich auch die Umgebung). Alle Abhängigkeiten müssen explizit definiert und isoliert werden.
Nehmen wir als Beispiel Komponieren и Docker.
Komponieren – ein Paketmanager, mit dem Sie Bibliotheken in PHP installieren können. Mit Composer können Sie Versionen streng oder lose angeben und diese explizit definieren. Es können 20 verschiedene Projekte auf dem Server vorhanden sein und jedes verfügt unabhängig voneinander über eine persönliche Liste von Paketen und Bibliotheken.
Docker – ein Dienstprogramm, mit dem Sie die Umgebung definieren und isolieren können, in der die Anwendung ausgeführt wird. Dementsprechend können wir, genau wie bei Composer, aber gründlicher, bestimmen, womit die Anwendung funktioniert. Wählen Sie eine bestimmte PHP-Version aus und installieren Sie nur die Pakete, die für das Funktionieren des Projekts erforderlich sind, ohne zusätzliche Elemente hinzuzufügen. Und das Wichtigste: ohne die Pakete und die Umgebung des Host-Rechners und anderer Projekte zu beeinträchtigen. Das heißt, alle Projekte auf dem Server, die über Docker laufen, können absolut jeden Paketsatz und eine völlig andere Umgebung verwenden.
3. Konfiguration
Speichern Sie Konfigurationen als Konstanten direkt im Code. Separate Konstanten für den Testserver, separate für die Produktion. Binden Sie den Betrieb der Anwendung abhängig von der Umgebung mithilfe von if else-Konstrukten direkt in die Geschäftslogik des Projekts ein.
Konfigurationen - Nur so sollten sich Projekteinsätze unterscheiden. Idealerweise sollten Konfigurationen über Umgebungsvariablen (env vars) übergeben werden.
Das heißt, selbst wenn Sie mehrere Konfigurationsdateien .config.prod .config.local speichern und sie zum Zeitpunkt der Bereitstellung in .config (die Hauptkonfiguration, aus der die Anwendung Daten liest) umbenennen, ist dies nicht der richtige Ansatz, da In diesem Fall stehen die Informationen aus den Konfigurationen allen Anwendungsentwicklern öffentlich zur Verfügung und die Daten vom Produktionsserver werden gefährdet. Alle Konfigurationen müssen direkt im Bereitstellungssystem (CI/CD) gespeichert und für verschiedene Umgebungen mit unterschiedlichen Werten generiert werden, die für eine bestimmte Umgebung zum Zeitpunkt der Bereitstellung erforderlich sind.
4. Dienste Dritter
Seien Sie strikt an die Umgebung gebunden, nutzen Sie in bestimmten Umgebungen unterschiedliche Verbindungen für die gleichen Dienste.
Tatsächlich überschneidet sich dieser Punkt stark mit dem Punkt über Konfigurationen, da ohne diesen Punkt keine normalen Konfigurationsdaten erstellt werden können und im Allgemeinen die Fähigkeit zur Konfiguration auf Null sinkt.
Alle Verbindungen zu externen Diensten wie Warteschlangenservern, Datenbanken und Caching-Diensten müssen sowohl für die lokale Umgebung als auch für die Dritt-/Produktionsumgebung gleich sein. Mit anderen Worten: Durch Ändern der Verbindungszeichenfolge kann ich jederzeit Aufrufe an Basis Nr. 1 durch Basis Nr. 2 ersetzen, ohne den Anwendungscode zu ändern. Oder Sie müssen in Zukunft beispielsweise bei der Skalierung des Dienstes die Verbindung für einen zusätzlichen Cache-Server nicht mehr speziell spezifizieren.
5. Erstellen, veröffentlichen, ausführen
Sie haben nur die endgültige Version des Codes auf dem Server und können die Veröffentlichung nicht rückgängig machen. Es muss kein Speicherplatz aufgefüllt werden. Jeder, der denkt, dass er Code mit einem Fehler in die Produktion freigeben kann, ist ein schlechter Programmierer!
Alle Bereitstellungsphasen müssen voneinander getrennt sein.
Haben Sie die Möglichkeit, einen Rollback durchzuführen. Erstellen Sie Veröffentlichungen mit alten Kopien der Anwendung (bereits zusammengestellt und kampfbereit), die im Schnellzugriff gespeichert sind, damit Sie im Fehlerfall die alte Version wiederherstellen können. Das heißt, bedingt gibt es einen Ordner Releases und Ordner Strom, und nach erfolgreicher Bereitstellung und Zusammenstellung des Ordners Strom verknüpft durch einen symbolischen Link zur darin enthaltenen Neuerscheinung Releases mit dem herkömmlichen Namen der Release-Nummer.
Hier erinnern wir uns an die Blue-Green-Bereitstellung, die es Ihnen nicht nur ermöglicht, zwischen Code, sondern auch zwischen allen Ressourcen und sogar Umgebungen zu wechseln, mit der Möglichkeit, alles zurückzusetzen.
6. Prozesse
Speichern Sie Anwendungsstatusdaten direkt in der Anwendung selbst. Verwenden Sie Sitzungen im RAM der Anwendung selbst. Nutzen Sie so viel Sharing zwischen Drittanbieterdiensten wie möglich. Verlassen Sie sich darauf, dass die Anwendung nur einen Prozess haben kann und keine Skalierung möglich ist.
Speichern Sie Daten in Bezug auf Sitzungen nur in einem Cache, der von Drittanbieterdiensten (Memcached, Redis) gesteuert wird. Selbst wenn also 20 Anwendungsprozesse ausgeführt werden, kann jeder von ihnen, nachdem er auf den Cache zugegriffen hat, mit dem Client weiterarbeiten derselbe Zustand, in dem der Benutzer in einem anderen Prozess mit der Anwendung gearbeitet hat. Mit diesem Ansatz stellt sich heraus, dass unabhängig davon, wie viele Kopien von Drittanbieterdiensten Sie verwenden, alles normal und ohne Probleme beim Zugriff auf Daten funktioniert.
7. Portbindung
Nur der Webserver sollte wissen, wie er mit Diensten von Drittanbietern zusammenarbeitet. Oder noch besser: Installieren Sie Dienste von Drittanbietern direkt auf dem Webserver. Beispielsweise als PHP-Modul in Apache.
Alle Ihre Dienste müssen durch Zugriff auf eine bestimmte Adresse und einen Port (localgost:5432, localhost:3000, nginx:80, php-fpm:9000) füreinander zugänglich sein, d. h. von nginx aus kann ich sowohl auf php-fpm als auch auf zugreifen Postgres und von PHP-FPM bis Postgres und Nginx und tatsächlich kann ich von jedem Dienst aus auf einen anderen Dienst zugreifen. Auf diese Weise ist die Lebensfähigkeit eines Dienstes nicht an die Lebensfähigkeit eines anderen Dienstes gebunden.
8. Parallelität
Arbeiten Sie mit einem Prozess, sonst kommen mehrere Prozesse nicht miteinander klar!
Lassen Sie Raum für Skalierung. Docker Swarm eignet sich hervorragend dafür.
Docker Swarm ist ein Tool zum Erstellen und Verwalten von Container-Clustern sowohl zwischen verschiedenen Maschinen als auch für eine Reihe von Containern auf derselben Maschine.
Mit Swarm kann ich bestimmen, wie viele Ressourcen ich jedem Prozess zuweisen und wie viele Prozesse desselben Dienstes ich starten werde, und der interne Balancer, der Daten auf einem bestimmten Port empfängt, leitet sie automatisch an die Prozesse weiter. Wenn ich also sehe, dass die Auslastung des Servers zugenommen hat, kann ich weitere Prozesse hinzufügen und so die Auslastung bestimmter Prozesse verringern.
9. Verfügbarkeit
Verwenden Sie keine Warteschlangen, um mit Prozessen und Daten zu arbeiten. Das Beenden eines Prozesses sollte sich auf die gesamte Anwendung auswirken. Wenn ein Dienst ausfällt, fällt alles aus.
Jeder Prozess und Dienst kann jederzeit deaktiviert werden, und dies sollte keine Auswirkungen auf andere Dienste haben (das bedeutet natürlich nicht, dass der Dienst für einen anderen Dienst nicht verfügbar ist, sondern dass ein anderer Dienst nach diesem nicht deaktiviert wird). Alle Prozesse müssen ordnungsgemäß beendet werden, damit bei ihrer Beendigung keine Daten beschädigt werden und das System beim nächsten Einschalten ordnungsgemäß funktioniert. То есть даже в случае аварийного завершения, данные не должны пострадать (тут подойдет механизм транзакций, запросы в бд работают только группами, и если хоть один запрос из группы не выполнился или выполнился с ошибкой, то не никакой другой запрос из группы в итоге не выполняется in der Wirklichkeit).
10. Anwendungsentwicklung/Betriebsparität
Produktions-, Staging- und lokale Version der Anwendung müssen unterschiedlich sein. In der Produktion verwenden wir das Yii Lite-Framework und lokal Yii, damit es in der Produktion schneller funktioniert!
In Wirklichkeit sollten alle Bereitstellungen und Arbeiten mit Code in einer nahezu identischen Umgebung erfolgen (wir sprechen hier nicht von physischer Hardware). Außerdem sollte jeder Entwicklungsmitarbeiter in der Lage sein, den Code bei Bedarf in der Produktion bereitzustellen, und nicht eine speziell geschulte Entwicklungsabteilung, die nur dank besonderer Stärke die Anwendung in die Produktion bringen kann.
Auch Docker hilft uns dabei. Wenn alle vorherigen Punkte beachtet werden, führt die Verwendung von Docker dazu, dass der Prozess der Bereitstellung der Umgebung sowohl in der Produktion als auch auf dem lokalen Computer auf die Eingabe von ein oder zwei Befehlen beschränkt ist.
11. Protokolle
Wir schreiben Protokolle in Dateien und Datenbanken! Wir bereinigen keine Dateien und Datenbanken aus Protokollen. Kaufen wir einfach eine Festplatte mit 9000 Peta-Bytes und das ist in Ordnung.
Alle Protokolle sollten als Ereignisstrom betrachtet werden. Die Anwendung selbst sollte nicht an der Protokollverarbeitung beteiligt sein. Protokolle sollten entweder auf stdout ausgegeben oder über ein Protokoll wie udp versendet werden, damit die Arbeit mit Protokollen für die Anwendung keine Probleme bereitet. Graylog ist dafür gut geeignet. Graylog empfängt alle Protokolle über UDP (bei diesem Protokoll muss nicht auf eine Antwort über den erfolgreichen Empfang des Pakets gewartet werden) beeinträchtigt die Anwendung in keiner Weise und befasst sich nur mit der Strukturierung und Verarbeitung von Protokollen. Die Anwendungslogik ändert sich nicht, um mit solchen Ansätzen zu arbeiten.
12. Verwaltungsaufgaben
Um Daten, Datenbanken usw. zu aktualisieren, verwenden Sie einen separat erstellten Endpunkt in der API. Wenn Sie ihn zweimal hintereinander ausführen, wird alles dupliziert. Aber Sie sind nicht dumm, Sie werden nicht zweimal klicken, und wir brauchen keine Migration.
Alle Verwaltungsaufgaben sollten auf Release-Ebene in derselben Umgebung wie der gesamte Code ausgeführt werden. Das heißt, wenn wir die Struktur der Datenbank ändern müssen, tun wir dies nicht manuell, indem wir die Namen der Spalten ändern und mithilfe einiger visueller Datenbankverwaltungstools neue hinzufügen. Für solche Dinge erstellen wir separate Skripte – Migrationen, die überall und in allen Umgebungen auf die gleiche Weise mit einem gemeinsamen und verständlichen Ergebnis ausgeführt werden. Für alle anderen Aufgaben, wie zum Beispiel das Füllen des Projekts mit Daten, sollten ähnliche Methoden verwendet werden.
Beispielimplementierung in PHP, Laravel, Laradock, Docker-Compose
PS: Alle Beispiele wurden unter MacOS erstellt. Die meisten davon sind auch für Linux geeignet. Windows-Benutzer, bitte verzeihen Sie mir, aber ich habe schon lange nicht mehr mit Windows gearbeitet.
Stellen wir uns eine Situation vor, in der auf unserem PC überhaupt keine PHP-Version installiert ist.
Installieren Sie die neuesten Versionen von Docker und Docker-Compose. (dieses finden Sie im Internet)
docker -v &&
docker-compose -v
1. Setzen
git clone https://github.com/Laradock/laradock.git &&
ls
Was Laradock betrifft, muss ich sagen, dass es ein sehr cooles Ding ist, das viele Container und Hilfsdinge enthält. Aufgrund der Redundanz würde ich jedoch nicht empfehlen, Laradock als solches ohne Änderungen in der Produktion zu verwenden. Es ist besser, eigene Container basierend auf Beispielen in Laradock zu erstellen, das wird viel optimierter sein, weil niemand alles gleichzeitig braucht, was da ist.
2. Konfigurieren Sie Laradock für die Ausführung unserer Anwendung.
cd laradock &&
cp env-example .env
2.1. Öffnen Sie das Habr-Verzeichnis (den übergeordneten Ordner, in den Laradock geklont wird) in einem Editor. (In meinem PHPStorm-Fall)
Zu diesem Zeitpunkt geben wir dem Projekt lediglich einen Namen.
2.2. Starten Sie das Arbeitsbereichsbild. (In Ihrem Fall wird die Erstellung der Bilder einige Zeit in Anspruch nehmen.)
Workspace ist ein speziell vorbereitetes Image für die Arbeit mit dem Framework im Auftrag des Entwicklers.
Wir gehen mit in den Container
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3. Laravel installieren
composer create-project --prefer-dist laravel/laravel application
2.4. Nach der Installation prüfen wir, ob das Verzeichnis mit dem Projekt erstellt wurde und töten Compose.
ls
exit
docker-compose down
2.5. Gehen wir zurück zu PHPStorm und legen den richtigen Pfad zu unserer Laravel-Anwendung in der .env-Datei fest.
3. Fügen Sie den gesamten Code zu Git hinzu.
Dazu erstellen wir ein Repository auf Github (oder anderswo). Gehen wir im Terminal in das Habr-Verzeichnis und führen den folgenden Code aus.
echo "# habr-12factor" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin [email protected]:nzulfigarov/habr-12factor.git # здесь будет ссылка на ваш репо
git push -u origin master
git status
Schauen wir mal, ob alles in Ordnung ist.
Der Einfachheit halber empfehle ich die Verwendung einer visuellen Schnittstelle für Git, in meinem Fall ist es das . (Hier ist ein Empfehlungslink)
4. Lasst uns starten!
Stellen Sie vor dem Start sicher, dass an den Ports 80 und 443 nichts hängt.
docker-compose up -d nginx php-fpm
Somit besteht unser Projekt aus 3 separaten Leistungen:
- nginx – Webserver
- php-fpm – PHP zum Empfangen von Anfragen von einem Webserver
- Arbeitsbereich – PHP für Entwickler
Im Moment haben wir erreicht, dass wir eine Anwendung erstellt haben, die 4 von 12 Punkten erfüllt, nämlich:
1. Codebasis – Der gesamte Code befindet sich in einem Repository (kleiner Hinweis: Es könnte richtig sein, Docker innerhalb des Laravel-Projekts hinzuzufügen, aber das ist nicht wichtig).
2. Abhängigkeiten – Alle unsere Abhängigkeiten sind explizit in application/composer.json und in jeder Docker-Datei jedes Containers geschrieben.
3. Unterstützungsdienste — Jeder der Dienste (php-fom, nignx, workspace) lebt sein eigenes Leben und ist von außen verbunden. Wenn Sie mit einem Dienst arbeiten, wird der andere nicht beeinträchtigt.
4. Prozesse — Jeder Dienst ist ein Prozess. Jeder der Dienste verwaltet nicht den internen Status.
5. Port-Bindung
docker ps
Wie wir sehen, läuft jeder Dienst auf einem eigenen Port und ist für alle anderen Dienste zugänglich.
6. Parallelität
Docker ermöglicht es uns, mehrere Prozesse derselben Dienste mit automatischem Lastausgleich zwischen ihnen zu erzeugen.
Stoppen wir die Container und lassen sie durch die Flagge laufen --Skala
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
Wie wir sehen können, wurden Kopien des PHP-FPM-Containers erstellt. An der Arbeit mit diesem Container müssen wir nichts ändern. Wir greifen auch weiterhin auf Port 9000 darauf zu und Docker regelt für uns die Last zwischen Containern.
7. Verfügbarkeit - Jeder Behälter kann getötet werden, ohne den anderen zu beschädigen. Das Stoppen oder Neustarten des Containers hat keinen Einfluss auf den Betrieb der Anwendung bei nachfolgenden Starts. Jeder Container kann auch jederzeit angehoben werden.
8. Parität zwischen Anwendungsentwicklung und Betrieb - Alle unsere Umgebungen sind gleich. Wenn Sie das System auf einem Server in der Produktion ausführen, müssen Sie nichts an Ihren Befehlen ändern. Alles wird auf die gleiche Weise auf Docker basieren.
9. Protokollierung – Alle Protokolle in diesen Containern werden gestreamt und sind in der Docker-Konsole sichtbar. (In diesem Fall ist dies bei anderen selbstgemachten Behältern möglicherweise nicht der Fall, wenn Sie sich nicht darum kümmern.)
docker-compose logs -f
Der Haken ist aber, dass die Standardwerte in PHP und Nginx auch Protokolle in eine Datei schreiben. Um die 12 Faktoren zu erfüllen, ist es notwendig deaktivieren Schreiben von Protokollen in eine Datei in den Konfigurationen jedes Containers separat.
Docker bietet außerdem die Möglichkeit, Protokolle nicht nur an stdout, sondern auch an Dinge wie Graylog zu senden, was ich oben erwähnt habe. Und innerhalb von Graylog können wir die Protokolle nach Belieben verwalten und unsere Anwendung wird dies in keiner Weise bemerken.
10 Verwaltungsaufgaben — Alle Verwaltungsaufgaben werden von Laravel dank des Handwerkstools genau so gelöst, wie es sich die Entwickler der 12-Faktor-Anwendung wünschen.
Als Beispiel werde ich zeigen, wie einige Befehle ausgeführt werden.
Wir gehen in den Container.
docker-compose exec workspace bash
php artisan list
Jetzt können wir jeden Befehl verwenden. (Bitte beachten Sie, dass wir die Datenbank und den Cache nicht konfiguriert haben, sodass die Hälfte der Befehle nicht korrekt ausgeführt werden, da sie für die Arbeit mit dem Cache und der Datenbank konzipiert sind.)
11 Konfigurationen und 12. Erstellen, veröffentlichen, ausführen
Ich wollte diesen Teil dem Blue-Green Deployment widmen, aber er erwies sich als zu umfangreich für diesen Artikel. Darüber werde ich einen separaten Artikel schreiben.
Kurz gesagt basiert das Konzept auf CI/CD-Systemen wie Jenkins и Gitlab-CI. In beiden Fällen können Sie Umgebungsvariablen festlegen, die einer bestimmten Umgebung zugeordnet sind. Dementsprechend ist in dieser Situation Punkt c erfüllt Konfigurationen.
Und der Punkt darüber Erstellen, veröffentlichen, ausführen wird durch eingebaute Funktionen mit dem Namen gelöst Pipeline.
Pipeline ermöglicht es Ihnen, den Bereitstellungsprozess in viele Phasen zu unterteilen und dabei die Phasen Montage, Freigabe und Ausführung hervorzuheben. Auch in Pipeline können Sie Backups erstellen und zwar alles. Dies ist ein Werkzeug mit grenzenlosem Potenzial.
Der Anwendungscode befindet sich unter .
Vergessen Sie nicht, das Submodul zu initialisieren, wenn Sie dieses Repository klonen.
PS: Alle diese Ansätze können mit allen anderen Dienstprogrammen und Programmiersprachen verwendet werden. Die Hauptsache ist, dass sich das Wesentliche nicht unterscheidet.
Source: habr.com