Seit Cipi 5.1

cipi.yml – Konfiguration, die mit dem Code geliefert wird.

Eine Datei im Stammverzeichnis Ihres Repositorys beschreibt den Status, den eine App darauf erwartet Server: Domänenaliase, PHP-Version und Einstellungen pro App, zusätzliche Datenbanken, Warteschlangenarbeiter, die Scheduler, seinen Healthcheck und seine Backup-Profile. Überprüfen Sie es in einem Pull-Request und versenden Sie es mit dem loslassen und lassencipi yml apply den Server damit abgleichen.

7 BereicheAliase, PHP, php.ini, Datenbanken, Worker, Scheduler, Gesundheit und Backups.
planen → anwendenEs ändert sich nichts, bis Sie sich das Diff ansehen und „Ja“ sagen.
Fail-ClosedAuf eine App beschränkt, keine Shell-Befehle im Schema.

Serverkonfiguration, überprüft wie Code

Der Serverstatus befindet sich normalerweise woanders: in einem Panel, einer Wiki-Seite oder in der Erinnerung desjenigen, der die Box eingerichtet hat. A cipi.yml Wird neben Ihrer Laravel-Anwendung festgeschrieben, wird dieser Zustand zum Teil desselben Pulls Anfrage als den Code, der davon abhängt. Eine Version, die eine Warteschlange hinzufügt, fügt auch ihren Worker hinzu. Eine Veröffentlichung, die braucht einen größeren upload_max_filesize trägt es. Führen Sie einen Rollback des Codes durch, und die Konfiguration wird ausgeführt wieder damit.

Die Datei ist deklarativ: Es beschreibt den Endzustand, nicht die Schritte. Cipi liest, was die Server hat, vergleicht es mit der Datei und zeigt Ihnen den Unterschied, bevor Sie etwas anfassen.

Die Befehle

bash
$ cipi yml generate myapp          # this app's current config, as a cipi.yml
$ cipi yml example myapp           # blank commented template, in myapp's namespace
$ cipi yml validate myapp          # parse and check, change nothing
$ cipi yml plan myapp              # show exactly what would change
$ cipi yml apply myapp [--yes]     # apply it
$ cipi yml auto myapp on|off|status  # apply after every successful deploy
Befehl Was es bewirkt
cipi yml generate Druckt die Konfiguration der App wie es auf dem Server steht – Aliase, PHP-Version und pro App-Einstellungen, zusätzliche Datenbanken, Warteschlangenarbeiter, die aus Supervisor zurücklesen, die Scheduler und die Backup-Profile, die die App besitzt – als fertige Datei.
cipi yml example Eine leere, vollständig kommentierte Vorlage. Übergeben Sie einen App-Namen und die Platzhalterdatenbanken und Profile landen im Namespace dieser App, sodass die Vorlage unverändert validiert wird.
cipi yml validate Analysiert die Datei und prüft jeden Wert anhand des Schemas. Ändert nichts.
cipi yml plan Der Unterschied: Jeder Alias, jeder Worker, jede Datenbank, jede Einstellung und jedes Profil, die hinzugefügt würden, wurden geändert oder entfernt. Lesen Sie dies, bevor Sie sich bewerben.
cipi yml apply Wendet den Plan an. Hinzufügen --yes für Skripte und CI.
cipi yml auto Aktivieren oder deaktivieren Sie den automatischen Abgleich nach jeder erfolgreichen Bereitstellung. status meldet die aktuelle Einstellung.

Die Datei wird in nachgeschlagen current/cipi.yml, dann current/cipi.yaml, dann shared/cipi.yml – überschreiben mit --file=<path>.

Was die Datei konfigurieren kann

app.aliases

Domäne Aliase

Die deklarierte Liste ersetzt die aktuelle – ein Alias, den Sie aus der Datei löschen, wird daraus entfernt Nginx. Platzhalter wie z*.myapp.com werden für Multi-Tenant-Subdomains akzeptiert. Die Die primäre Domäne wird hier nie verwaltet.

Aliase in den Dokumenten →
app.php · app.ini

PHP-Version und php.ini

Fixieren Sie die App an PHP 8.3, 8.4 oder 8.5 (bereits auf dem Server installiert) und legen Sie Überschreibungen pro App fest – upload_max_filesize, post_max_size, memory_limit und die Ruhe. Serverweite Werte bleiben erhalten cipi ini set.

php.ini in den Dokumenten →
Datenbanken

Extra Datenbanken

Über das mit der App erstellte hinaus: Berichterstellung, Analyse, was auch immer die Version benötigt, auf MariaDB oder PostgreSQL. Anmeldeinformationen landen in shared/cipi-databases.env und werden nie zurückgeschrieben zum Repository. Datenbanken werden erstellt und niemals gelöscht.

Datenbanken in den Dokumenten →
Arbeiter

Warteschlangenarbeiter und Horizon

Deklarieren Sie jede Warteschlange mit ihrer Prozessanzahl, Versuchen und Zeitüberschreitung, und Supervisor wird mit abgeglichen Spiel. Oder einstellen horizon: true und lassen Sie stattdessen Horizon die Warteschlangen besitzen.

Arbeiter in den Dokumenten →
Zeitplan

Die Laravel Planer

Eine boolesche Drehung * * * * * artisan schedule:run für die App ein- oder ausschalten. Keine Crontab Bearbeiten, kein vergessener Eintrag auf dem nächsten Server.

Scheduler in den Dokumenten →
Gesundheit

Gesundheitscheck und Rollback

Eine HTTP-Prüfung auf einer der eigenen Domänen der App, die alle fünf Minuten und unmittelbar danach erneut überprüft wird bei jedem Einsatz. Optional kann ein fehlerhaftes Release automatisch zurückgesetzt werden – nur der Code-Symlink, Migrationen werden nicht rückgängig gemacht.

Gesundheitschecks in den Dokumenten →
backup.profiles

Sicherung Profile

Pro-App-Profile mit eigenem Umfang, Zeitplan, eigener Aufbewahrung, eigenen Zielen und eigener Verschlüsselung – günstig Datenbank wird alle 30 Minuten ausgeführt, eine vollständig verschlüsselte Kopie auf S3 in der Nacht. Profilnamen haben einen Gültigkeitsbereich zur App.

Backups in den Dokumenten →
Referenz

Jeder Schlüssel, dokumentiert

Das vollständige Schema, die Suchreihenfolge, die Validierungsregeln und die Benachrichtigungs-Hooks befinden sich im Deploy-Kapitel der Dokumentation.

Lesen Sie die Referenz →

Eine vollständige Datei

Sie müssen es nicht von Hand schreiben. cipi yml generate <app> druckt, was der Server hat bereits; das begehen und cipi yml plan meldet nichts zu tun.

bash
$ cipi yml generate myapp > cipi.yml   # then commit it
$ cipi yml plan myapp                  # reports nothing to do
yaml
version: 1

app:
  # 8.3, 8.4 or 8.5 — must already be installed (cipi php install 8.5)
  php: "8.5"

  # The declared list replaces the current aliases: one you remove here is
  # removed from the server. The primary domain is not managed here.
  aliases:
    - „www.myapp.com“
    - "*.myapp.com"      # wildcard, for multi-tenant subdomains

  # Per-app php.ini overrides. Server-wide values stay with `cipi ini set`.
  ini:
    upload_max_filesize: 50M
    post_max_size: 60M
    memory_limit: 512M

# Extra databases beyond the one created with the app. Credentials land in
# /home/myapp/shared/cipi-databases.env — never written back to the repo.
databases:
  - name: myapp_reporting
  - name: myapp_analytics
    engine: pgsql          # mariadb (default) or pgsql

workers:
  horizon: false           # true replaces the queue workers below
  queues:
    - queue: default
      processes: 2
    - queue: emails
      processes: 1
      tries: 5
      timeout: 300

# Laravel scheduler (* * * * * artisan schedule:run)
schedule: true

# HTTP healthcheck. Probed every 5 minutes and right after every deploy.
# The URL must be one of this app's own domains.
health:
  url: „https://myapp.com/up“
  expect: 200
  # grace: 8                      # seconds before the first probe after a deploy
  # postdeploy: false             # skip the check right after a deploy
  # rollback_on_unhealthy: true   # undo a release that fails the check
  #                               # (the code symlink only — migrations are NOT undone)

# Backup strategy for this app. Profile names must be myapp or myapp-*.
backup:
  profiles:
    # Frequent and cheap: databases only, without the noisy tables.
    - name: myapp-db
      scope: db
      databases: [„meine App“, „meineapp_*“, „mieter_*“]
      exclude_tables: [„*.jobs“, „*.telescope_*“]
      every: 30m           # 5m/10m/15m/20m/30m, 1h..12h, 1d..28d
      keep: 48             # keep the last 48 runs
      destinations: [local]

    # Slower, complete, off-site and encrypted.
    - name: myapp-nightly
      scope: all           # all | files | db
      cron: "0 2 * * *"
      keep_days: 14
      destinations: [s3]
      encrypt: true

Bereitstellungen ignorieren die Datei, bis Sie sich dafür entscheiden

Bei der Bereitstellung passiert nichts, bis Sie es ausführen cipi yml auto <app> on. Mit diesem Opt-in, jeder erfolgreich Die Bereitstellung stimmt ab – von beiden cipi deploy und der Git webhook. Eine Veröffentlichung, die keine trägt cipi.yml ist ein stiller No-Op und eine Datei, die die Validierung nicht besteht wird per E-Mail gemeldet (yml_fail) und nie teilweise angewendet. Ein Erfolg Brände versöhnen yml_apply.

bash
$ cipi yml auto myapp on       # reconcile after every successful deploy
$ cipi yml auto myapp status   # is it on?
$ cipi yml auto myapp off      # back to manual apply

Warum es sicher ist, Git zu akzeptieren

Die Datei kommt aus einem Repository, sodass jeder, der einen Commit durchführen kann, ihren Inhalt kontrolliert. Es ist ausfallsicher durchgehend:

Einmal yml auto aktiviert ist, kann jeder, der in dieses Repository pushen kann, die Aliase der App ändern. PHP Einstellungen, Worker, Healthcheck und Backup-Profile. Das ist der Sinn der Konfiguration als Code – Behandeln Sie den Schreibzugriff auf das Repo entsprechend.

Fragen

Muss ich die Datei von Hand schreiben?

Nein. cipi yml generate <app>druckt die aktuelle Serverkonfiguration der App als bereit, sich zu engagieren cipi.yml, und cipi yml example gibt einen leeren Kommentar aus Vorlage, wenn Sie lieber ganz von vorne beginnen möchten.

Kann ein Commit meinen Server kaputt machen?

Das Schema enthält keine Shell-Befehle und keine Include-Pfade, eine App kann nur auf ihre eigenen Datenbanken zugreifen und Sicherungsprofile und eine Datei, die die Validierung nicht besteht, wird als Ganzes abgelehnt und nicht zur Hälfte angewendet. Bereitstellungen ignorieren die Datei vollständig, bis Sie sie umdrehen cipi yml auto An.

Was passiert mit Dingen, die in der Datei nicht erwähnt werden?

Sie werden allein gelassen. Nur die von Ihnen deklarierten Abschnitte werden abgeglichen – mit einer bewussten Ausnahme: Die Aliasliste ist maßgeblich. Wenn Sie also einen Alias aus der Datei entfernen, wird dieser auch vom Server entfernt.

Funktioniert es mit dem Git webhook?

Ja. Mit cipi yml auto an, beides cipi deploy und eine durch webhook ausgelöste Bereitstellung nach erfolgreicher Veröffentlichung abgleichen.

Vollständige cipi.yml-Referenz Installieren Sie Cipi