Up(sun) and running mit mehreren Anwendungen

Wir möchten Ihnen mit dieser Schritt-für-Schritt-Anleitung zeigen, wie Sie Ihre Projekte mit mehreren Anwendungen auf Upsun hosten und konfigurieren können . Ziel ist es, Ihrem Team zu ermöglichen, sich mehr auf die Schaffung von unglaublichen Benutzererlebnissen und weniger auf die Verwaltung der Infrastruktur für mehrere Anwendungen zu konzentrieren - sowie ein paar Tipps für die Entwicklung mehrerer Anwendungen auf dem Weg.

Wir werden dies aus der Sicht eines Kunden betrachten, der ein Multi-Applikations-Hosting mit einigen spezifischen Einschränkungen sucht. Diese Einschränkungen sind:

• Ein Backend, das die Komponente API Platform Admin verwendet
• Ein Legacy-Frontend, das eine API und ein Unternehmens-Frontend hostet und mit Symfony 6.2 entwickelt wurde
• Ein mit Gatsby entwickeltes White-Label-Frontend, das die "Legacy"-API nutzt
• Ein Mercure Rocks-Server für Marketingzwecke (Push-Benachrichtigungen)
• Alle Kundenquellen in einem öffentlichen GitHub-Repository

So starten Sie das Hosting Ihres Multi-Applikationsprojekts bei Upsun

Erstellen eines Forks des BigFoot Multi-App Repository

Um die folgenden Schritte in diesem Prozess durchführen zu können, müssen Sie zunächst Ihr eigenes Repository - einen Fork - unter Verwendung eines Upsun-Beispiels erstellen. Folgen Sie dazu einfach den Schritten in diesem Github-Artikel , um einen Fork von unserem BigFoot-Multi-App-Projekt zu Ihrer eigenen Github-Organisation zu erstellen. Dieses Bigfoot-Multi-App-Projekt hat ein Backend mit API Platform, ein Frontend+API mit Symfony, ein White-Label-Frontend mit Gatsby und einen Mercure Rocks-Server.

Nachdem Sie Ihren Fork erstellt haben, klonen Sie ihn lokal und öffnen ihn in Ihrer bevorzugten integrierten Entwicklungsumgebung (IDE).

git clone https://github.com/<IhrOrganisationsname>/upsun_multi-app-example bigfoot-multiapp cd bigfoot-multiapp

Vergessen Sie nicht, den Wert <IhrOrganisationsname> durch Ihre eigene Github-Organisation zu ersetzen.

Konfigurieren Sie Ihr Projekt

Um Ihr Multi-Applikations-Projekt auf Upsun zu hosten, benötigen Sie eine YAML-Konfiguration - config.yaml -in Ihrem Quellcode, um das Verhalten Ihrer Anwendung zu steuern. Diese YAML-Konfigurationsdatei befindet sich in einem .upsun/-Ordner im Stammverzeichnis Ihres Quellcodes, dessen Architektur folgendermaßen aussieht:

bigfoot-multiapp ├── .upsun │ └── config.yaml └── <Projektquellen>

Um Ihr Multi-Applikationsprojekt zu konfigurieren, gibt es ein paar grundlegende Regeln:

1. Das YAML-Format wird für Konfigurationsdateien verwendet.
2. Der Ordner.upsun/, der eine config.yaml-Datei mit Routing, Diensten und Anwendungskonfiguration enthält, die von allen Anwendungen gemeinsam genutzt wird, muss sich im Stammverzeichnis Ihres Projekts befinden.
3. Jede Anwendung befindet sich in einem eigenen Ordner:
   • admin: API Platform Admin Komponente
   • api: BigFoot API und Standard-Frontend
   • gatsby: Gatsby-Frontend
   • Merkur: Mercure Rocks Server

DieYAML-Konfiguration von Upsun befindet sich im Ordner .upsun/ und kann mit dem Befehl upsun project:init automatisch befüllt werden, siehe unten:

├── .upsun │ └── config.yaml └── <Projektquellen>

Dieser Befehl generiert eine .upsun/config.yaml-Datei, die auf Ihrem lokalen Stack basiert und 3 YAML-Schlüssel der obersten Ebene enthält:

• applications: dies enthält die Liste Ihrer Anwendungsdefinition
• services: dies enthält die Liste Ihrer Dienstdefinitionen
• routes: dies enthält die Liste Ihrer Routendefinition

Erstellen der Datei .upsun/config.yaml

Um Ihr Projekt zu konfigurieren, müssen Sie zunächst eine neue .upsun/config.yaml-Datei mit den folgenden YAML-Schlüsseln der ersten Ebene erstellen:

# .upsun/config.yaml Anwendungen: Dienste: Routen: 

Übertragen Sie dann Ihre neu konfigurierte Datei:

git add .upsun/config.yaml git commit -m "init Upsun configuration" git push

Konfigurieren wir nun unsere vier Anwendungen eine nach der anderen:

Konfigurieren Sie die API-Anwendung

Zuerst müssen wir den Top-Level-Key der Anwendungenmit dem Verhalten unserer Symfony BigFoot-Anwendung namens api konfigurieren.

# .upsun/config.yaml # Vollständige Liste aller verfügbaren Eigenschaften: https://docs.upsun.com/create-apps/app-reference.html applications: # Ein eindeutiger Name für die Anwendung api: # Informationen über den Quellcode der Anwendung und Operationen, die darauf ausgeführt werden können. source: # Der Pfad, in dem sich der Anwendungscode befindet. Standardmäßig ist dies das Verzeichnis der Datei .upsun/config.yaml. Nützlich für Multi-App-Setups. root: api # Die Laufzeit, die die Anwendung verwendet. type: php:8.3 # Die Beziehungen der Anwendung mit Diensten oder anderen Anwendungen. relationships: database: "database:postgresql" # Mounts definieren Verzeichnisse, die nach Abschluss des Builds beschreibbar sind. Wenn als lokale Quelle festgelegt, ist die Eigenschaft disk erforderlich. mounts: "/var/cache": { source: storage, source_path: files/cache } "/var/log": { Quelle: storage, source_path: files/log } "/var/sessions": { Quelle: storage, source_path: files/sessions } "/data": { source: storage, source_path: files/data } # Der Web-Schlüssel konfiguriert den Webserver, der vor Ihrer Anwendung läuft. web: # Jeder Schlüssel in locations ist ein Pfad auf Ihrer Site mit einem führenden /. locations: "/": root: "public" passthru: '/index.php' index: - index.php scripts: true allow: true headers: Access-Control-Allow-Origin: "*" # Variablen zur Steuerung der Umgebung. variables: env: APP_ENV: 'prod' php: assert.active: off #opcache.preload: config/preload.php # Gibt einen Standardsatz von Build-Tasks an, die ausgeführt werden sollen. Flavors sind sprachspezifisch. build: flavor: composer # Installiert globale Abhängigkeiten als Teil des Build-Prozesses. # Hooks erlauben es Ihnen, Ihren Code/Ihre Umgebung anzupassen, während das Projekt die Build- und Deployment-Phasen durchläuft hooks: # Der Build-Hook wird nach jedem Build-Flavor ausgeführt. build: | set -x -e curl -s https://get.symfony.com/cloud/configurator | bash symfony-build # Der Deploy-Hook wird ausgeführt, nachdem der App-Container gestartet wurde, aber bevor er beginnt, Anfragen zu akzeptieren. deploy: | set -x -e symfony-deploy # Geplante Aufgaben für die App. crons: update-sighting: spec: '*/5 * * * *' cmd: './bin/console app:update-sighting-scores' security-check: # Prüfen, dass keine Sicherheitsprobleme für PHP-Pakete gefunden wurden, die in der Produktion eingesetzt werden # Siehe https://github.com/fabpot/local-php-security-checker spec: '50 23 * * *' cmd: if [ "$PLATFORM_ENVIRONMENT_TYPE" = "production" ]; then croncape php-security-checker; fi # Anpassungen an Ihre PHP- oder Lisp-Laufzeit. runtime: extensions: [ ctype, iconv, apcu, mbstring, sodium, xsl, pdo_pgsql ]

Sie haben wahrscheinlich bemerkt, dass unsere Api-Anwendung eine Beziehung zu einem Dienst namens Database hat, siehe die YAML-Konfiguration unten. Das bedeutet, dass wir diesen Dienst Datenbank deklarieren müssen.

applications: api: ... relationships: database: "datenbank:postgresql"

In der gleichen Datei .upsun/config.yaml definieren wir diesen Dienst im YAML-Schlüssel der obersten Ebene services:

# .upsun/config.yaml applications: api: ... # Die Dienste des Projekts. # # Jeder aufgelistete Dienst wird bereitgestellt # um Ihr Upsun-Projekt zu betreiben. # Weitere Informationen: https://docs.upsun.com/add-services.html # Vollständige Liste der verfügbaren Dienste: https://docs.upsun.com/add-services.html#available-services services: database: type: postgresql:15

Schließlich müssen wir das Routing für unsere API-Anwendung in der gleichen .upsun/config.yaml-Datei definieren:

# .upsun/config.yaml applications: api: ... services: ... routes: # BigFoot API https://{default}: type: upstream # der erste Teil sollte Ihr Projektname sein upstream: "api:http" id: api

Dann müssen wir die Umgebungsvariablen konfigurieren, die spezifisch für Upsun für die api-Anwendung sind. Bitte erstellen Sie eine api/.environment Datei. Wenn diese Datei vorhanden ist, wird sie in die Umgebung der Anwendung aufgenommen.

# api/.environment export N_PREFIX=$HOME/.n export PATH=$N_PREFIX/bin:$PATH # Dynamisches CORS_ALLOW_ORIGIN für NelmioBundle setzen export CORS_ALLOW_ORIGIN=.*$(echo $PLATFORM_PROJECT)..*.platformsh.site export TRUSTED_HOSTS=.*$(echo $PLATFORM_PROJECT)..*.platformsh.site export TRUSTED_PROXIES=.*$(echo $PLATFORM_PROJECT)..*.platformsh.site # Admin Site Name export API_SITE_NAME="API Platform" export APP_SECRET=$(echo $PLATFORM_PROJECT_ENTROPY) # Mercure Rocks uri export MERCURE_URL=$(echo $PLATFORM_ROUTES | base64 --decode | jq -r 'to_entries[] | select(.value.id == "mercure") | .key'| awk '{print substr($0, 0, length($0))}') export MERCURE_PUBLIC_URL=$(echo $PLATFORM_ROUTES | base64 --decode | jq -r 'to_entries[] | select(.value.id == "mercure") | .key'| awk '{print substr($0, 0, length($0))}') export MERCURE_PUBLISH_URL=$(echo $PLATFORM_ROUTES | base64 --decode | jq -r 'to_entries[] | select(.value.id == "mercure") | .key'| awk '{print substr($0, 0, length($0))}') # Das zum Signieren der JWTs verwendete Geheimnis export MERCURE_JWT_SECRET="!ChangeThisMercureHubJWTSecretKey!"

Anschließend können Sie Ihre Konfigurationsdatei an Ihr Git-Repository übergeben:

git add .upsun/config.yaml api/.environment git commit -m "adding api configuration for Upsun" git push

Konfigurieren Sie die Admin-Anwendung

Zweitens müssen wir den Top-Level-Schlüssel der Anwendung mit dem Verhalten unserer API-Plattform-Admin-Komponente, genannt admin, konfigurieren. Um Ihre Admin-Anwendung zu konfigurieren, fügen Sie den applications.admin Block in Ihre .upsun/config.yaml Datei ein:

# .upsun/config.yaml applications: api: ... # Ein eindeutiger Name für die Anwendung admin: # Informationen über den Quellcode der Anwendung und Operationen, die darauf ausgeführt werden können. source: # Der Pfad, in dem sich der Anwendungscode befindet. Standardmäßig ist dies das Verzeichnis der Datei .upsun/config.yaml. Nützlich für Multi-App-Setups. root: admin # Die Laufzeit, die die Anwendung verwendet. type: nodejs:20 # Wie viele Ressourcen der Anwendung zugewiesen werden sollen. Wenn nicht gesetzt, wird die vordefinierte Runtime-Definition verwendet. # Weitere Informationen finden Sie unter https://docs.upsun.com/manage-resources/adjust-resources.html#advanced-container-profiles container_profile: BALANCED # Mounts definieren Verzeichnisse, die nach Abschluss des Builds beschreibbar sind. Wenn als lokale Quelle gesetzt, ist die Eigenschaft disk erforderlich. mounts: '/.tmp_platformsh': { source: "storage", source_path: "files/tmp_platformsh" } '/build': { source: "storage", source_path: "files/build" } '/.cache': { source: "storage", source_path: "files/.cache" } '/node_modules/.cache': { source: "storage", source_path: "files/node_modules/.cache" } # Der Web-Schlüssel konfiguriert den Webserver, der vor Ihrer Anwendung läuft. web: # Jeder Schlüssel in locations ist ein Pfad auf Ihrer Site mit einem führenden /. locations: "/admin": root: "build" passthru: "/admin/index.html" index: - "index.html" expires: 300s scripts: true allow: false rules: .(css|js|gif|jpe?g|png|ttf|eot|woff2?|otf|html|ico|svg?)$: allow: true ^/admin/robots.txt$: allow: true ^/admin/manifest.json$: allow: true ^/admin/_next: allow: true ^/admin/sitemap: allow: true headers: Access-Control-Allow-Origin: "*" # Variablen, um die Umgebung zu kontrollieren. variables: env: NODE_OPTIONS: '--max-old-space-size=1536' # Spezifiziert einen Standardsatz von Build-Tasks, die ausgeführt werden. Flavors sind sprachspezifisch. build: flavor: none # Hooks erlauben es Ihnen, Ihren Code/Ihre Umgebung anzupassen, während das Projekt die Build- und Deploy-Phasen durchläuft hooks: # Der Build-Hook wird nach jedem Build-Flavor ausgeführt. build: | set -eu corepack yarn install --immutable --force # Der post_deploy-Haken wird ausgeführt, nachdem der App-Container gestartet wurde und nachdem er begonnen hat, Anfragen zu akzeptieren. post_deploy: | corepack yarn build

Wie Sie wahrscheinlich bemerkt haben, sind die applications.admin.web.locations auf /admin definiert. Das bedeutet, dass der Admin unter <defaultUrl>/admin erreichbar ist. Wir müssen die entsprechende Route in der gleichen Datei .upsun/config.yaml im YAML-Schlüssel der obersten Ebene der Routen definieren:

applications: api: ... admin: ... 
services: ... routes: # BigFoot API https://{default}: ... # API Platform Admin component https://{default}/admin: type: upstream # der erste Teil sollte Ihr Projektname sein upstream: "admin:http" id: "admin" cache: cookies: [ '*' ] default_ttl: 0 enabled: true headers: [ Accept, Accept-Language ] ssi: aktiviert: false

Anschließend müssen wir die Upsun-spezifischen Umgebungsvariablen für die Admin-Anwendung konfigurieren, die das vorinstallierte Tool jq nutzt. Bitte erstellen Sie eine admin/.environment Datei.

# admin/.environment export REACT_APP_PUBLIC_URL=$(echo $PLATFORM_ROUTES | base64 --decode | jq -r 'to_entries[] | select(.value.id == "api") | .key')api export PUBLIC_URL=$(echo $PLATFORM_ROUTES | base64 --decode | jq -r 'to_entries[] | select(.value.id == "admin") | .key') # Admin Site Name export REACT_APP_ADMIN_SITE_NAME="Admin API Upsun"

Anschließend können Sie Ihre Konfigurationsdatei in Ihr Git-Repository übertragen:

git add .upsun/config.yaml admin/.environment git commit -m "adding admin configuration for Upsun" git push

Konfigurieren Sie die Gatsby-Anwendung

Drittens müssen wir den Top-Level-Schlüssel der Anwendungen mit dem Verhalten unseres White-Label-Frontends - gatsby -konfigurieren , dasmit dem Gatsby-Stack entwickelt wurde.

# .upsun/config.yaml applications: api: ... admin: ... # Ein eindeutiger Name für die Anwendung gatsby: # Informationen zum Quellcode der Anwendung und zu den Operationen, die darauf ausgeführt werden können. source: # Der Pfad, in dem sich der Anwendungscode befindet. Standardmäßig ist dies das Verzeichnis der Datei .upsun/config.yaml. Nützlich für Multi-App-Setups. root: gatsby # Die Laufzeit, die die Anwendung verwendet. type: 'nodejs:20' # Wie viele Ressourcen der Anwendung zugewiesen werden sollen. Wenn nicht gesetzt, wird die vordefinierte Runtime-Definition verwendet. # Weitere Informationen finden Sie unter https://docs.upsun.com/manage-resources/adjust-resources.html#advanced-container-profiles container_profile: BALANCED # Mounts definieren Verzeichnisse, die nach Abschluss des Builds beschreibbar sind. Wenn als lokale Quelle festgelegt, ist die Eigenschaft disk erforderlich. mounts: '/.cache': { source: "storage", source_path: "cache" } '/.config': { source: "storage", source_path: "config" } '/public': { source: "storage", source_path: "public" } # Der Web-Schlüssel konfiguriert den Webserver, der vor Ihrer Anwendung läuft. web: # Jeder Schlüssel in locations ist ein Pfad auf Ihrer Site mit einem führenden /. locations: '/site': root: 'public' index: [ 'index.html' ] scripts: false allow: true # Variablen zur Steuerung der Umgebung. variables: env: NODE_OPTIONS: --max-old-space-size=1536 # Gibt einen Standardsatz von Build-Tasks an, die ausgeführt werden sollen. Flavors sind sprachspezifisch. build: flavor: none # Installiert globale Abhängigkeiten als Teil des Build-Prozesses. dependencies: nodejs: yarn: "1.22.17" # Hooks ermöglichen es Ihnen, Ihren Code/Ihre Umgebung anzupassen, während das Projekt die Build- und Deployment-Phasen durchläuft hooks: # Der Build-Hook wird nach jeder Build-Variante ausgeführt. build: | set -e yarn --frozen-lockfile # Der post_deploy-Haken wird ausgeführt, nachdem der App-Container gestartet wurde und nachdem er begonnen hat, Anfragen zu akzeptieren. post_deploy: | yarn build --prefix-paths

Wie Sie wahrscheinlich bemerkt haben, sind die applications.gatsby.web.locations auf /site definiert. Das bedeutet, dass Gatsby unter <defaultUrl>/site erreichbar sein wird und wir müssen die entsprechende Route in der gleichen .upsun/config.yaml-Datei im YAML-Schlüssel der obersten Ebene für Routen definieren:

applications: api: ... admin: ... 
services: ... routes: # BigFoot API https://{default}: ... 
  # API Platform Admin component https://{default}/admin: ... # Gatsby App https://{default}/site: type: upstream # der erste Teil sollte Ihr Projektname sein upstream: "gatsby:http"

Die Gatsby-Anwendung nutzt unsere BigFoot api REST API. Wenn Sie sich den Quellcode von gatsby ansehen, finden Sie in der Datei gatsby/gatsby-config.js die Route zu Ihrer API-App, indem Sie process.env.PLATFORM_ROUTES verwenden, was bedeutet, dass wir keine gatsby/.environment-Datei benötigen, um diese Route zu finden. Anschließend können Sie Ihre Konfigurationsdatei an Ihr Git-Repository übergeben:

git add .upsun/config.yaml git commit -m "adding gatsby configuration for Upsun" git push

Konfigurieren Sie die Mercure-Anwendung

Die von Les Tilleuls erstellte Komponente API Platform Admin kommuniziert mit einem Mercure.rocks-Server - einem GO-Stack, der für die Echtzeit-Push-Kommunikation verwendet wird. Wir müssen den Top-Level-Schlüssel der Anwendung mit dem Verhalten eines eigenständigen Mercure.rocks-Servers mit dem Namen mercure konfigurieren.

# .upsun/config.yaml applications: api: ... admin: ... gatsby: ... # Ein eindeutiger Name für die Anwendung mercure: # Informationen zum Quellcode der Anwendung und zu den Operationen, die darauf ausgeführt werden können. source: # Der Pfad, in dem sich der Anwendungscode befindet. Standardmäßig ist dies das Verzeichnis der Datei .upsun/config.yaml. Nützlich für Multi-App-Setups. root: mercure/.config # Die Laufzeit, die die Anwendung verwendet. type: golang:1.21 # Mounts definieren Verzeichnisse, die beschreibbar sind, nachdem der Build abgeschlossen ist. Wenn als lokale Quelle gesetzt, ist die Eigenschaft disk erforderlich. mounts: "database": { source: "storage", source_path: "database" } "/.local": { source: "storage", source_path: ".local" } "/.config": { source: "storage", source_path: ".config" } # Der Web-Schlüssel konfiguriert den Webserver, der vor Ihrer Anwendung läuft. web: # Befehle werden einmal nach der Bereitstellung ausgeführt, um den Anwendungsprozess zu starten. commands: # Der Befehl zum Starten Ihrer Anwendung. Wenn sie beendet wird, wird sie sofort neu gestartet. start: ./mercure run --config Caddyfile.upsun # Jeder Schlüssel in locations ist ein Pfad auf Ihrer Site mit einem führenden /. locations: /: passthru: true scripts: false allow: true request_buffering: enabled: false headers: Access-Control-Allow-Origin: "*" # Variablen zur Steuerung der Umgebung. variables: env: MERCUREVERSION: 0.14.4 SERVER_NAME: ":8888" MERCURE_TRANSPORT_URL: "bolt:///var/run/mercure.db?size=1000&cleanup_frequency=0.5" MERCURE_EXTRA_DIRECTIVES: | cors_origin * publish_origins * subscriptions demo GLOBAL_OPTIONS: | auto_https off MERCURE_PUBLISHER_JWT_KEY: "!ChangeThisMercureHubJWTSecretKey!" MERCURE_SUBSCRIBER_JWT_KEY: "!ChangeThisMercureHubJWTSecretKey!" # Gibt einen Standardsatz von Build-Aufgaben an, die ausgeführt werden sollen. Flavors sind sprachspezifisch. build: flavor: none # Hooks ermöglichen es Ihnen, Ihren Code/Ihre Umgebung anzupassen, während das Projekt die Build- und Deploy-Phasen durchläuft hooks: # Der Build-Hook wird nach jedem Build-Flavor ausgeführt. build: | # Mercure mit Cache installieren FILE="mercure_${MERCUREVERSION}_Linux_x86_64.tar.gz" if [ ! -f "$PLATFORM_CACHE_DIR/$FILE" ]; then URL="https://github.com/dunglas/mercure/releases/download/v${MERCUREVERSION}/$FILE" wget -O "$PLATFORM_CACHE_DIR/$FILE" $URL else echo "Found $FILE in cache, using cache" fi file $PLATFORM_CACHE_DIR/$FILE tar xvzf $PLATFORM_CACHE_DIR/$FILE

Für das Routing der Mercure-App verwenden wir eine Subdomain der Standard-URL Ihrer Umgebung (um die Erkennung des Upsun-Routings abzuschließen). Dies bedeutet, dass die Mercure-App unter mercure.<defaultUrl> erreichbar sein wird .

Wir müssen also die entsprechende Route in der gleichen Datei .upsun/config.yaml im YAML-Schlüssel der obersten Ebene der Routen definieren:

applications: api: ... admin: ... 
  gatsby: ... 
  mercure: ... 
services: ... routes: # BigFoot API https://{default}: ... 
  # API Platform Admin component https://{default}/admin: ... # Gatsby App https://{default}/site: ... # Mercure Rocks app https://mercure.{default}: type: upstream # der erste Teil sollte Ihr Projektname sein upstream: "mercure:http" cache: aktiviert: false

Anschließend können Sie Ihre Konfigurationsdatei in Ihr Git-Repository übertragen:

git add .upsun/config.yaml git commit -m "adding mercure configuration for Upsun" git push

Et voilà, Ihr Projekt ist bereit, zu Upsun gepusht zu werden! Sie können sich das Endergebnis einer .upsun/config.yaml-Datei hier als Referenz ansehen.

Ein Upsun-Projekt erstellen

Der nächste Schritt bei der Einrichtung dieses Multi-App-Projekts auf Upsun ist die Erstellung eines Projekts, was über die Konsole einfach zu bewerkstelligen ist. Klicken Sie auf der Startseite der Konsole (alle Projekte) in der oberen rechten Ecke auf die Schaltfläche " Projekt erstellen", wie unten dargestellt:

Wenn Sie noch keine Organisation für das Projekt erstellt haben, werden Sie zunächst aufgefordert, eine solche zu erstellen. Sobald Sie dies getan haben, wählen Sie diese Organisation aus dem Dropdown-Menü aus und wählen Sie dann Sync Your GitHub Repo with Upsun, wie auf dem Bildschirm unten zu sehen:

Wählen Sie dann " Mit GitHub verbinden" aus den angebotenen Optionen, wie hier zu sehen:

Wählen Sie im nächsten Formular Ihre GitHub-Organisation aus der ersten Dropdown-Liste aus, wählen Sie dann Installieren und autorisieren und geben Sie die GitHub-Anmeldedaten ein. Sie müssen Ihre GitHub-Organisation und das zuvor erstellte GitHub-Repository sowie den Produktionszweig auswählen und " Weiter" wählen.

Sie werden dann zu Schritt drei dieser Einrichtung weitergeleitet - wie unten zu sehen -, wo Sie verschiedene Details wie Projektname, Umgebungsname und Region eingeben müssen. Wählen Sie anschließend Projekt erstellen.

Auf der nächsten Seite sehen Sie auf der linken Seite weitere Anleitungen zur Einrichtung, während im Hintergrund der Prozess der Projekterstellung abläuft, falls Sie diese benötigen. Auf der rechten Seite können Sie den Prozess der Projekterstellung verfolgen und werden informiert, wenn er abgeschlossen ist, wie auf dem Bildschirm unten zu sehen:

Sobald Ihr Projekt erstellt wurde, wird der GitHub-Integrationsprozess Ihre Anwendung automatisch auf der Grundlage des Quellcodes Ihres GitHub-Repositorys bereitstellen. Warten Sie, bis die Integration die Bereitstellung abgeschlossen hat. Anschließend werden die Informationen zu Ihrer Anwendung angezeigt, die Sie in der folgenden Abbildung sehen können:

Zeit für die Bereitstellung, richtig?

Und einfach so ist es Zeit für die Bereitstellung! Aber warten Sie...

Da Sie im Abschnitt zur Projektkonfiguration dieses Handbuchs bereits sichergestellt haben, dass Ihr Quellcode Upsun-ready ist, wurde Ihr Projekt bei der Projekterstellung automatisch bereitgestellt und Ihre Anwendung ist bereits live, ohne dass eine Bereitstellung erforderlich ist. Überprüfen Sie Ihre neue Projekt-URL am unteren Rand der Konsolenoberfläche.

Als Nächstes greifen Sie auf Ihre Projektkonsole zu, indem Sie unten auf der Einrichtungsseite auf die Schaltfläche " Projekt anzeigen" klicken. Und schon ist Ihr Mehrfachanwendungsprojekt live und Sie können damit herumspielen und viele neue Funktionen hinzufügen!

Legen Sie ein Remote zu Ihrem Upsun-Projekt fest

Um die Interaktion zwischen Ihrem Terminal und Ihrem Upsun-Projekt zu vereinfachen, müssen Sie mit diesem CLI-Befehl eine Remote einrichten:

upsun project:set-remote <projectID>

upsun projekt:liste

Befüllen Sie die Daten

Die Bigfoot-App (API app) enthält Fixtures, die in die Datenbank eingefügt werden können. Um dies zu tun, führen Sie die folgenden Befehle aus:

upsun ssh --app=api "php bin/console d:s:u --dump-sql --force" upsun ssh --app=api "php bin/console d:f:load -e dev"

Betrachten Sie die bereitgestellten Sites

Ihr Projekt mit mehreren Anwendungen ist nun live und Sie sollten es testen. Um eine Ihrer Websites zu öffnen, können Sie entweder die Konsolenschnittstelle nutzen oder den folgenden CLI-Befehl verwenden und dann eine der aufgelisteten Routen auswählen:

upsun umgebung:url

Erstellen einer Staging-Umgebung

Um eine neue Umgebung für unser Projekt zu erstellen, müssen wir einen neuen Git-Zweig erstellen und diesen in das Github-Repository pushen, woraufhin der Github-Integrationsprozess die Umgebung automatisch erstellt. Führen Sie dazu die folgenden Befehle aus:

git checkout -b staging git push --set-upstream origin staging

Denken Sie daran, dass die GitHub-Integration jedes Mal, wenn Sie einen neuen Git-Zweig erstellen und pushen, eine neue inaktive Umgebung innerhalb Ihres Upsun-Projekts erzeugt. Da die Umgebung standardmäßig inaktiv ist, müssen Sie sie wie folgt aktivieren, um sie bereitzustellen:

upsun environment:info type staging upsun environment:activate staging

Erstellen einer Entwicklungsumgebung

Nun ist es an der Zeit, eine neue Entwicklungsumgebung zu erstellen, indem Sie einen neuen Git-Zweig aus der Staging-Umgebung wie folgt erstellen:

git checkout -b dev git push --set-upstream origin dev

Denken Sie daran, dass jedes Mal, wenn Sie einen neuen Git-Zweig erstellen und pushen, die GitHub-Integration eine neue inaktive Umgebung innerhalb Ihres Upsun-Projekts erzeugt. Da die Umgebung standardmäßig inaktiv ist, müssen Sie sie aktivieren, um sie bereitzustellen:

upsun environment:info type development upsun environment:activate dev

Und die Git-Anleitungen hören hier noch nicht auf. Bleiben Sie dran für unseren nächsten Artikel über Git-Submodule, der bald erscheint. Bleiben Sie auf unseren Social Media und Community Kanälen auf dem Laufenden über das Neueste von uns: Dev.to, Reddit, und Discord.