Infrastruktur

cipi php

PHP 8.5 wird beim Setup vorinstalliert. Weitere Versionen können jederzeit hinzugefügt werden; seitdemv4.5.12 Cipi untersucht APT Quellen pro Ubuntu Codenamen – typischerweise die ondrej/php PPA am 24.04. Pakete.sury.org am 26.04, wenn Launchpad keine Suite hat, oder Ubuntu main als letzter Ausweg (koinstallierbar 8.3–8.5, sofern das ausgewählte Repo dies unterstützt).

$ cipi php list              # list installed versions, status, and system default
$ cipi php install 8.4       # install an additional PHP version (8.3–8.5)
$ cipi php switch 8.4        # set system default (root/cipi, API pool)
$ cipi php remove 8.1        # remove a version, incl. legacy (blocks if default or apps use it)
$ cipi php upgrade           # apply security patches to all installed PHP packages

Sicherheitspatch-Upgrades

Seitdem v4.7.13, PHP Pakete sind davon ausgeschlossen unattended-upgrades und stattdessen von Cipi verwaltet. cipi php upgrade läuft apt-get update und --only-upgrade auf jedem installiert php* und libphp*Paket und startet dann die betroffenen PHP-FPM-Pools neu. Wenn SMTP konfiguriert ist und Pakete wurden aktualisiert, Cipi sendet eine E-Mail (php_upgrade auslösen; deaktivieren mit cipi notifications disable php_upgrade).

Eine wöchentliche Prüfung läuft automatisch ab Sonntag um 03:30 Uhr über Root Crontab (umschlossen von cipi-cron-notify). Protokoll: /var/log/cipi/php-upgrade.log. Bestehende Server erhalten die cron weiter cipi self-update (Migration 4.7.13).

Systemstandard vs. App-spezifisch PHP

Die Systemstandard ist die PHP-Version, die von verwendet wird root und cipi Benutzer, der Cipi API FPM-Pool und der API Warteschlangenarbeiter. Benutzen cipi php switch <ver> zu ändere es. Der Befehl migriert den API-Pool (und den GUI FPM-Pool, sofern installiert) und erstellt ihn neu Schalttafelsteckdosen und startet den API Worker neu. Seitdem 5.0.9+, PUT /api/php/default wickelt dies über das Panel API (php-manage Fähigkeit). Seitdem 5.0.10–5.0.12, Schalter toleriert teilweise update-alternativesErfolgreich, mountet schreibgeschützte Roots bei Bedarf erneut und behält API/GUI FPM-Pools auf der Zielversion, um nginx 502 zu vermeiden.

RUHE: GET /api/php, POST /api/php/install, DELETE /api/php/{version}, PUT /api/php/default (API 1.15.0+ / Cipi 5.0.6+). CLI JSON: cipi php list --json (seit 5.0.6).

Jede App hat ihre eigene besitzen PHP-Version (eingestellt auf app create oder über cipi app edit --php=). Deployer, Composer, Crontab-Bereitstellungstrigger und cipi sync import Wird immer mit dem konfigurierten PHP der App ausgeführt – niemals mit dem Systemstandard.

Um eine vorhandene App auf eine andere Version umzustellen:

$ cipi app edit myapp --php=8.5

Dadurch wird die PHP-Version im laufenden Betrieb ohne Ausfallzeit ausgetauscht: Aktualisiert den FPM-Pool, Nginx-Socket, Supervisor Worker, Crontab, Deployer-Konfiguration und .env in einer atomaren Operation.

cipi ini

Seitdem verfügbar v5.1.0. Eine geführte Möglichkeit, PHP-Einstellungen zu ändern, ohne danach suchen zu müssen richtig php.ini. Jede serverweite Änderung erreicht beide SAPIs — PHP-FPM undCLI – was Ihre Webanfragen also sehen, ist auch das, was Warteschlangenarbeiter sehen, artisan und cron sehen.

$ cipi ini list                                # effective values and which layer set them
$ cipi ini list --app=shop                     # as seen by one app
$ cipi ini get memory_limit                    # one setting
$ cipi ini set upload_max_filesize=50M         # server-wide (FPM + CLI)
$ cipi ini set memory_limit=512M --app=shop    # for one app only
$ cipi ini unset memory_limit --app=shop       # fall back to the wider value
$ cipi ini reset [--app=shop]                  # back to Cipi defaults
$ cipi ini keys                                # what can be set, and what cannot

Was es für Sie tut

• Es erhöht die Einstellungen, die Ihre Einstellungen stillschweigend begrenzen würden. Einstellung upload_max_filesizeerhöht auch post_max_size und memory_limit wenn sie es sonst begrenzen würden, und Nginx client_max_body_size wird markiert, wenn dies der Fall wäre.
• Es lehnt ab, was nicht so eingestellt werden sollte. Einstellbare Schlüssel sind explizit Whitelist – siehe cipi ini keys. open_basedir, auto_prepend_file, extension und Freunde werden abgelehnt mit Namen, mit der Grund, weil Cipi sie im Rahmen der App-Isolation verwaltet.
• Der Gewinn pro App wird überschrieben. --app=<app> schreibt in diese App FPM-Pool, der der serverweiten Datei überlegen ist – nur für diese App.

Warum dies behoben werden musste

Vor 5.1.0 ist jeder FPM-Pool fest codiert upload_max_filesize, post_max_size und max_execution_time, und Poolwerte übertreffen conf.d – also serverweit php.ini Die Änderung konnte keine einzige App erreichen. Darüber hinaus schrieb Cipi 99-cipi.ini Nur für FPM, so dass die CLI SAPI (Warteschlangenarbeiter, artisan, cron) auf die PHP-Paketvorgaben.

In 5.1.0 übertragen Pools nur das, was wirklich pro App ist (open_basedir, das Fehlerprotokoll, explizite Überschreibungen) und alles andere erben; beide SAPIs bekommen ihre Datei; undMigration 5.1.0füllt die CLI wieder auf99-cipi.ini und schreibt bestehende Pools neu aktualisieren.

cipi db

Cipi erstellt für jeden eine eigene Datenbank Laravel App automatisch während app create. MariaDB (Hafen 3306) ist die native Standardeinstellung; seitdem v4.8.0 Sie können es auch optional installieren PostgreSQL (Hafen 5432) und wählen Sie eine Engine pro Datenbank oder App aus. Benutzerdefinierte Apps erhalten keine Datenbank – verwenden cipi db create --name=<app> wenn Sie eines benötigen (z. B. für WordPress oder ein anderes). CMS). Nach der Einrichtung wird eine gebrauchsfertige Verbindungs-URL angezeigt (MariaDB: mariadb+ssh://), kombiniert SSH-Anmeldeinformationen, Server-IP und Datenbankinformationen für GUI Clients wie TablePlus, DBeaver oder Sequel Pro.

Motoren (v4.8.0+)

$ cipi db install pgsql              # install optional PostgreSQL
$ cipi db uninstall pgsql|mariadb    # remove a non-default engine (destroys data)
$ cipi db default mariadb|pgsql      # server-wide default when --engine is omitted
$ cipi db engines                    # installed engines, ports, and default

Database lifecycle

$ cipi db create                              # interactive
$ cipi db create --name=analytics             # non-interactive (default engine)
$ cipi db create --name=analytics --engine=pgsql
$ cipi db list [--engine=mariadb|pgsql]       # list databases with sizes
$ cipi db backup myapp [--engine=…]
$ cipi db restore myapp backup.sql.gz [--engine=…]
$ cipi db password myapp [--engine=…]         # regenerate password
$ cipi db delete analytics [--engine=…]

Laravel Apps speichern die ausgewählte Engine in App-Metadaten; Sichern, synchronisieren und cipi app reset-db-password Folge ihm. Benutzen cipi app create --engine=pgsql (oder die interaktive Eingabeaufforderung), um eine Laravel-App bereitzustellen auf PostgreSQL — .env und die Verbindungs-URL stimmen mit der Engine überein. Zurücksetzen des Root-Passworts: cipi reset db-password [--engine=].

cipi alias

Fügen Sie jeder App mehrere Domänen oder Subdomänen hinzu. Führen Sie nach dem Hinzufügen von Aliasen Folgendes aus: cipi ssl install das Zertifikat mit SAN-Abdeckung für alle bereitzustellen oder zu erneuern Domänen. Seitdem v4.8.0, cipi alias add|remove regeneriert den vhost und wendet SSL erneut an certbot install --redirect sodass HTTPS nicht wegfällt.

$ cipi alias add myapp www.myapp.com
$ cipi alias add myapp myapp.it
$ cipi alias add myapp '*.myapp.com'   # wildcard (v5.1.0+) — quote it
$ cipi alias list myapp
$ cipi alias remove myapp myapp.it

Seitdem v5.1.0, Platzhalter-Aliase wie z.B *.example.com werden akzeptiert – Nginx entspricht einem Platzhalter server_name nativ, und mandantenfähige Apps benötigen es. Zitieren Sie das Muster, damit die Shell es nicht erweitert, und stellen Sie das Zertifikat aus cipi ssl install myapp --dns=cloudflare --wildcard: HTTP-01 kann a nicht validieren Platzhalter.

Für kanonische Weiterleitungen www ↔ Apex bevorzugen Sie cipi www anstatt den Gegenhost manuell zu verwalten.

cipi www

Seitdem verfügbar v4.8.0. Verwalten Sie www/apex-Aliase und kanonische 301-Weiterleitungen für eine App. Staat lebt in apps.json (www_redirect); Nginx gibt ein dediziertes Signal aus Umleitungsserverblock (ACME-Pfad bleibt öffentlich), der die vhost-Neugenerierung übersteht. SSL wird erneut angewendet über certbot install --redirect.

$ cipi www add myapp              # add counterpart host (www ↔ apex)
$ cipi www force-to-root myapp    # 301 www.domain → domain
$ cipi www force-from-root myapp  # 301 domain → www.domain
$ cipi www clear myapp            # clear redirect state
$ cipi www status myapp           # inspect redirect state

force-to-root / force-from-root Fügen Sie den fehlenden Alias ​​bei Bedarf automatisch hinzu.

cipi domains

Seitdem verfügbar v4.5.5. Ein Befehl der obersten Ebene, der auflistet jeder Domain und Alias übergreifend alle Apps in einer einzigen Tabelle – das globale Gegenstück zu die Pro-App cipi alias list <app>. Ideal für die Prüfung des Ganzen Domain-zu-App-Mapping oder Erkennen einer Domain, der noch ein Zertifikat fehlt.

$ cipi domains   # list all domains and aliases across every app

Jede Zeile zeigt die folgenden Spalten:

In einer Fußzeile werden die Gesamtzahlen (Anzahl der Domänen, Apps, Zertifikate und gesperrten Apps) zusammengefasst Es ist einfach, die gesamte Zuordnung auf einen Blick zu überprüfen.

cipi ssl

Certbot verwaltet Let's Encrypt Zertifikate. Zertifikate erneuern sich automatisch wöchentlich um cron.cipi ssl status Zeigt Ablaufdaten mit farbcodierten Warnhinweisen an: grün (>30 Tage), gelb (14–30 Tage), rot (<14 Tage).

$ cipi ssl install myapp   # provision / renew — includes all aliases (SAN)
$ cipi ssl force myapp     # re-apply HTTP→HTTPS redirect (no new issuance)
$ cipi ssl renew            # force renewal of all certificates
$ cipi ssl status           # show all certs with expiry dates

# DNS-01 via Cloudflare (v5.0+) — wildcard certs
$ cipi ssl dns set --provider=cloudflare --token=YOUR_CF_TOKEN
$ cipi ssl install myapp --dns=cloudflare
$ cipi ssl install myapp --dns=cloudflare --wildcard

Seitdem v4.8.0, cipi ssl force <app> wendet erneut HTTP → HTTPS an Weiterleitung für eine App, die bereits über ein Let's Encrypt-Zertifikat verfügt – ohne ein neues auszustellen. cipi ssl install setzt auch force_https in apps.json automatisch.

Seitdem v5.0, optional DNS-01 Herausforderungen über Cloudflare ersetzen die Standardfluss HTTP-01, wenn Sie Wildcard-Zertifikate benötigen oder Port 80 nicht verfügbar machen können. Einmal konfigurieren mit cipi ssl dns set, then pass --dns=cloudflare (und optional --wildcard) zu cipi ssl install.

cipi nginx default-server

Seitdem verfügbar v5.1.0. Behauptet, was auch immer:80 / :443 hat keinen Standardserver und schließt nicht übereinstimmende Anfragen mit einer leeren Antwort (444).

$ cipi nginx default-server status
$ cipi nginx default-server on
$ cipi nginx default-server off

Cipi hatte immer einen Standardserver aktiviert :80, aber nie an :443. Ein HTTPS Anfrage mit einem Unbekannten Host fiel daher zu dem durch, den vhost Nginx hatte zuerst geladen – für eine Multi-Tenant-App mit Platzhalter, direkt in einen Mandanten-Resolver, der nicht analysieren kann es.

Es ist bei Neuinstallationen aktiviert und Migration 5.1.0 behauptet es auf bestehenden Servern wo es nichts anderes schon gibt. Wenn ein anderer vhost rechtmäßig Eigentümer des Standardservers ist, wird der Befehl sagt es und ändert nichts.

cipi backup

Sichern Sie Anwendungsdateien und Datenbanken auf einer lokalen Festplatte, auf Amazon S3 oder einem anderen S3-kompatiblen Speicher Anbieter (Cloudflare R2, Hetzner Object Storage, DigitalOcean Spaces, Backblaze B2, Scaleway, MinIO, …).

Seitdem v5.1.0 Backups werden gesteuert von Profile statt einer hartcodierter nächtlicher Job. Ein Profil beantwortet vier Fragen: was es dauert, wie oft es läuft, wo es geht und wie lange es bleibt erhalten – und die Profile sind unabhängig, so dass eine 30-minütige reine Datenbankkopie auf der Festplatte problemlos aufbewahrt wird neben einer verschlüsselten nächtlichen Vollkopie am S3.

1 – Ziele

cipi backup configure speichert die S3 Anmeldeinformationen, die von jedem Profil gemeinsam genutzt werden. Seitdem v5.1.0 Du kannst den Eimer verlassen leer für ausschließlich lokale Backups, die darunter landen/var/backups/cipi.

$ cipi backup configure
# → AWS Access Key ID
# → AWS Secret Access Key
# → Bucket name        (leave empty for local-only backups)
# → Region
# → Endpoint URL       (leave empty for AWS; required for other providers)

$ cipi backup status                 # destinations, profiles, last run, overdue

S3-kompatible Endpunkte

2 – Sicherungsprofile

Erstellen Sie einmal ein Profil. es läuft dann nach seinem eigenen Zeitplan. Zwei typische:

# Every 30 minutes — databases only, kept on the server, last 48 runs
$ cipi backup profile add hourly-db --scope=db \
      --databases='shop,mieter_*' --exclude-tables='*.jobs,*.telescope_*' \
      --every=30m --keep=48 --dest=local

# Every night at 02:00 — files + databases, encrypted to S3, kept 14 days
$ cipi backup profile add nightly --scope=all \
      --cron='0 2 * * *' --keep-days=14 --dest=s3 --encrypt

$ cipi backup profile list                 # all profiles
$ cipi backup profile show nightly         # one profile in detail
$ cipi backup profile edit nightly --keep-days=30
$ cipi backup profile disable hourly-db    # pause it without deleting it
$ cipi backup profile enable hourly-db
$ cipi backup profile remove hourly-db     # deletes the profile, keeps its archives

Flaggen für profile add / profile edit

3 – Verschlüsselung

Mit --encrypt Das Archiv ist mit verschlüsselt AES-256 auf dem Server, bevor es hochgeladen wird, sodass der Bucket-Operator niemals lesbare Daten enthält. Das Manifest bleibt lesbar sodass ein Lauf noch erkennbar ist.

$ cipi backup key show      # print the key — store it off-server
$ cipi backup key rotate    # new key for future runs

4 – Ausführen, Überprüfen und Wiederherstellen

$ cipi backup run                          # run every enabled profile now
$ cipi backup run --profile=nightly        # run one profile now
$ cipi backup run --dry-run                # show what it would take, take nothing
$ cipi backup list [--profile=nightly]     # runs held on each destination
$ cipi backup verify                       # does the newest run of each profile open?
$ cipi backup verify --deep                # same, downloading from S3 to check
$ cipi backup prune [--profile=nightly]    # apply retention now
$ cipi backup fetch nightly 2026-09-02_020000   # download and decrypt one run

Seitdem v5.1.0 Diese Befehle sagen Ihnen die Wahrheit, anstatt Sie zu beruhigen:

• Jedes Archiv ist vor dem Versand einer Integritätsprüfung unterzogen. Eine Müllkippe, die durch einen vollen unterbrochen wurde Da es sich bei der Festplatte immer noch um eine nicht leere Datei handelt, wurde sie von der alten Größenprüfung bestanden. Jetzt ist ein beschädigtes Archiv verworfen und gemeldet, anstatt stillschweigend ein gutes Backup zu ersetzen.
• cipi backup fetch Meldet keinen Erfolg mehr für ein Präfix, das keine Objekte enthält, also a Ein falsch eingegebener Zeitstempel ist eher ein Fehler als ein leeres Verzeichnis.
• cipi backup verify sagt deutlich, dass es nichts zu überprüfen gibt, wenn kein Lauf ausgeführt wurde noch passiert, statt „bestanden“.
• tar Warnungen – „Datei hat sich geändert, während wir sie gelesen haben“, konstant beim Schreiben einer Live-App Protokolle – ein einwandfrei funktionierendes Archiv schlägt nicht mehr fehl. Es zählt nur der Exit-Code 2 und höher.
• A deaktiviert Das Profil wird tatsächlich nicht mehr ausgeführt, und Encrypted ist korrekt angezeigt.

Zum Wiederherstellen holen Sie sich den Lauf und führen die Teile zurück:

$ cipi backup fetch nightly 2026-09-02_020000 --dest=/root/restore
$ cipi db restore myapp /root/restore/databases/mariadb/myapp.sql.gz
$ tar -tzf /root/restore/apps/myapp/files.tar.gz

5 — Storage layout

Anwendungsdateien und Datenbanken werden gespeichert separat, mit einem Manifest pro Lauf – also Die Erstellung eines Nur-Datenbank-Profils kostet nichts, und eine Datenbank kann wiederhergestellt werden, ohne dass ein entpackt werden muss App.

<root>/<profile>/<YYYY-MM-DD_HHMMSS>/
├── manifest.json
├── apps/
│   └── myapp/
│       ├── files.tar.gz
│       └── meta.json
└── databases/
    └── mariadb/
        └── myapp.sql.gz

# local  → /var/backups/cipi/<profile>/<timestamp>/
# s3     → s3://<bucket>/cipi/<profile>/<timestamp>/

Backup staging defaults to /var/tmp (Festplatte) statt /tmp (oft ein kleiner RAM-gestützte tmpfs), sodass große Apps nicht während der Sicherung fehlschlagen, wenn tmpfs voll ist. Überschreiben mit tmpdir in backup.json (eingestellt über cipi backup configure) oder die CIPI_BACKUP_TMPDIR Umgebungsvariable.

6 – Zeitplan und Staleness Watchdog

Sie schreiben nicht mehr cron Zeilen von Hand. cipi backup configure und jede Profiländerung a umschreiben markierter Block in Roots Crontab; alles außerhalb dieses Blocks bleibt übrig allein, und handgeschriebene Zeilen vor Version 5.1 werden bei der Migration absorbiert.

Ein stündlicher Wachhund erhöht die backup_stale Benachrichtigung, wenn ein Profil nicht erfolgreich war innerhalb des doppelten eigenen Intervalls – denn ein Backup, das stillschweigend nicht mehr läuft, ist schlimmer als nein Backup überhaupt: Es sieht immer noch konfiguriert aus. Ein neu erstelltes Profil wird nicht als überfällig gemeldet bevor der erste geplante Lauf hätte stattfinden können.

Legacy-Beschneidung

cipi backup prune <app> --weeks=N Arbeitet weiterhin gegen das Layout vor 5.1 (s3://<bucket>/cipi/<app>/<timestamp>/ plus Pre-Deployment-Dumps in /var/log/cipi/backups), also vorhandene Archive und jede handschriftliche cron-Zeile noch beschneiden. Neue Profile verwenden --keep, --keep-days oder --keep-weeks stattdessen.

Benutzer-Crontab

Cipi fügt beim Erstellen einer App automatisch einen Crontab-Eintrag für den Laravel-Planer hinzu:

# installed automatically by cipi app create
* * * * * /usr/bin/php8.5 /home/myapp/current/artisan schedule:run >> /dev/null 2>&1

Dieser Eintrag läuft als myapp Linux-Benutzer jede Minute mit der ausgewählten PHP-Version die App. Es wird automatisch aktualisiert, wenn Sie die Version PHP über ändern cipi app edit myapp --php=X.

Anzeigen der aktuellen Crontab

# as root — view the app user's crontab
$ crontab -u myapp -l

# or after switching to the app user
$ su - myapp
myapp@server:~$ crontab -l

Hinzufügen benutzerdefinierter cron-Jobs

Sie können der Crontab des App-Benutzers zusätzliche cron-Jobs hinzufügen. Wechseln Sie zuerst zum App-Benutzer, um Jobs sicherzustellen Mit dem richtigen Benutzerkontext und den richtigen Dateiberechtigungen ausführen:

$ su - myapp
myapp@server:~$ crontab -e

Beispieleinträge, die Sie hinzufügen könnten:

# existing Laravel scheduler (do not remove)
* * * * * /usr/bin/php8.5 /home/myapp/current/artisan schedule:run >> /dev/null 2>&1

# nightly database backup at 2 AM
0 2 * * * /usr/local/bin/cipi db backup myapp >> /home/myapp/logs/backup.log 2>&1

# custom script every 15 minutes
*/15 * * * * /home/myapp/current/scripts/sync.sh >> /home/myapp/logs/sync.log 2>&1

Überprüfen, ob cron funktioniert

# check system cron log
$ grep CRON /var/log/syslog | grep myapp | tail -20

# check Laravel scheduler execution
$ cipi app artisan myapp schedule:list

cipi schedule

Seitdem v5.0, verwalten Sie den Laravel Scheduler-Crontab-Eintrag, der ausgeführt wirdschedule:run (Die Crontab selbst existierte bereits; sie ist jetzt umschaltbar und kann nachverfolgt werden apps.json).

$ cipi schedule on myapp
$ cipi schedule off myapp
$ cipi schedule status myapp

cipi worker & Laravel Horizon

Jede App erhält einen Standard-Worker für Supervisor default Warteschlange. Sie können weitere hinzufügen Warteschlangen mit benutzerdefinierten Prozesszahlen und Zeitüberschreitungen.

$ cipi worker add myapp --queue=emails --processes=3
$ cipi worker add myapp --queue=exports --processes=1 --timeout=7200
$ cipi worker list myapp
$ cipi worker edit myapp --queue=default --processes=3
$ cipi worker remove myapp emails
$ cipi worker restart myapp   # restart all workers for the app
$ cipi worker stop myapp      # stop all workers for the app (used during deploys)

# Laravel Horizon (v5.0+) — mutually exclusive with queue:work workers
$ cipi worker horizon enable myapp
$ cipi worker horizon status myapp
$ cipi worker horizon disable myapp

Mit Horizon aktiviert, die Bereitstellung wird ausgeführthorizon:terminate und startet neu Arbeiter über cipi-worker. Sie können nicht klassisch laufen queue:work Arbeiter und Horizon in derselben App auf einmal.

Warteschlangenarbeiter können auch im Repository der App deklariert werden – siehe cipi.yml.

Worker werden vor dem Symlink-Austausch gestoppt und nach jedem Deployment neu gestartet, um dies zu verhindern Supervisor von der Abholung abgestanden artisan Wege. Supervisor ist mit konfiguriert autorestart=unexpected Daher werden Worker nur bei unerwarteten Exits neu gestartet, nicht bei ordnungsgemäßen Exits stoppt.

App-Benutzerhelfer: cipi-worker

Jeder App-Benutzer kann Worker ohne Root neu starten, stoppen oder überprüfen – über einen eingeschränkten sudo-Helper installiert bei /usr/local/bin/cipi-worker:

# run as the app user (SSH or sudo su - myapp)
$ sudo cipi-worker status myapp
$ sudo cipi-worker stop myapp      # used by Deployer before symlink swap
$ sudo cipi-worker restart myapp

As root, use cipi worker list|restart|stop <app> stattdessen. Es gibt keine cipi worker status Admin-Befehl – verwenden cipi worker list oder der App-Benutzer Helfer oben.

cipi health

Seitdem v5.0, konfigurieren Sie HTTP Healthchecks pro App. Cipi schaut sich dann die App in zwei Hälften an auf unterschiedliche Weise, denn „Ist die Website online?“ und „Hat der Push, den ich gerade gemacht habe, die Produktion unterbrochen?“ sind nicht die gleiche Frage.

$ cipi health set myapp --url=https://myapp.com/up --expect=200
$ cipi health check myapp
$ cipi health list
$ cipi health unset myapp

# Structured output (v5.0.6+) — panel API / scripts
$ cipi health list --json
$ cipi health check myapp --json

Überprüfung nach der Bereitstellung (v5.1.0+)

Sobald eine App über eine Healthcheck-URL verfügt, wird die gerade live geschaltete Version direkt im Anschluss überprüft bereitstellen – von cipi deploy und vom Git webhook gleichermaßen. Die Sonde wartet eine kurze Wartezeit Zeitraum (8 Sekunden für Octane Apps, 3 sonst oder was auch immer). --grace=N sagt) und versucht es fünfmal erneut, also ein Eine App, die einen Moment braucht, um hochzufahren, wird nicht als defekt gemeldet.

Das Urteil ändert nie den Exit-Code der Bereitstellung – die Veröffentlichung ist so oder so live –, sondern die Warnung sagt es und gibt Ihnen den Rollback-Befehl. Die Erfolgs-E-Mail wird gesendet danach Überprüfung, Daher kann niemals eine erfolgreiche Bereitstellung angekündigt werden, während die Site 500 zurückgibt.

$ cipi health postdeploy myapp             # run the post-deploy verification now
$ cipi health set myapp --grace=15         # give the release longer to warm up (max 120)
$ cipi health set myapp --no-postdeploy    # turn the post-deploy check off for this app

Automatisches Rollback einer fehlerhaften Version (Opt-in)

Cipi kann eine Veröffentlichung rückgängig machen, wenn die Gesundheitsprüfung nach der Bereitstellung fehlschlägt: die current Symlink Wechselt zurück zur vorherigen Version, die App wird erneut überprüft und eins E-Mail beschreibt die gesamte Sequenz – was veröffentlicht wurde, was es beantwortete, worauf es zurückgesetzt wurde und ob das das Problem behoben hat.

$ cipi health set myapp --rollback-on-unhealthy   # permanent, per app
$ cipi deploy myapp --rollback-on-unhealthy       # just this deploy

Vier Ergebnisse werden deutlich berichtet: erholt; aber immer noch zurückgerollt ungesund (Die Ursache liegt also wahrscheinlich nicht im Code); der Rollback selbst gescheitert (die schlechte Veröffentlichung ist noch live); und Es gibt keine frühere Veröffentlichung zurückkehren.

RUHE: GET /api/health, GET|PUT|DELETE /api/apps/{name}/health, POST /api/apps/{name}/health/check (API 1.15.0+ / Cipi 5.0.6+). Eine App kann ihren Gesundheitscheck auch in ihrem Repository deklarieren – siehe cipi.yml.

cipi firewall

Cipi installiert UFW mit standardmäßig geöffneten Ports 22, 80 und 443. Verwenden Sie zur Verwaltung die Firewall-Befehle zusätzliche Regeln, ohne UFW direkt zu berühren.

$ cipi firewall allow 3306                  # open a port
$ cipi firewall allow 3306 --from=10.0.0.5  # allow from specific IP
$ cipi firewall allow 3306 --from=10.0.0.0/24 # allow from subnet
$ cipi firewall deny 8080                   # block a port
$ cipi firewall list                        # show all rules

cipi ban

Überprüfen und verwalten Sie Fail2ban-Verbote direkt vom CLI aus. Cipi konfiguriert Fail2ban mit Progressive Sperre: eine 24-Stunden-Grundsperre, die sich bei jedem wiederholten Vergehen verdoppelt, bis zu einer Höchstdauer von 7 Tagen, mit maximaler Wiederholungsversuche auf 3 reduziert. Ein dedizierter recidive Nach drei Sperren werden Wiederholungstäter für sieben Tage ins Gefängnis gesperrt innerhalb von 24 Stunden.

$ cipi ban list                        # list all banned IPs, grouped by jail
$ cipi ban unban 203.0.113.42           # unban a specific IP from all jails

cipi ban list

Listet alle derzeit von Fail2ban gesperrten IP-Adressen auf, gruppiert nach Gefängnis (z. B. sshd, recidive). Nützlich für eine schnelle Sicherheitsüberprüfung oder vor der Durchführung einer Aufhebung des Banns.

cipi ban unban <IP>

Entfernt die angegebene IP von alle Fail2ban-Gefängnisse auf einmal. Praktisch, wenn Sie ein legitimer Benutzer sind oder der CI-Läufer wird versehentlich ausgesperrt.

cipi service

Überprüfen und steuern Sie die Systemdienste, die Cipi direkt vom CLI aus versorgen. Nginx verwendet eine anmutige Neuladen (keine Ausfallzeit) anstelle eines vollständigen Neustarts.

$ cipi service list                    # status of all services
$ cipi service list nginx              # status of a specific service
$ cipi service restart                 # restart all services
$ cipi service restart nginx           # graceful reload (zero downtime)
$ cipi service restart php             # restart all PHP-FPM versions
$ cipi service start fail2ban
$ cipi service stop supervisor         # asks for confirmation

# Structured output (v5.0.6+) — panel API
$ cipi service list --json

RUHE: GET /api/services, POST /api/services/{name}/restart (API 1.15.0+ / Cipi 5.0.6+; Fähigkeiten services-view / services-manage).

Unterstützte Dienstnamen: nginx, mariadb, postgresql (Aliasnamen: pgsql, postgres — bei Installation über cipi db install pgsql), valkey-server, supervisor, fail2ban, php<ver>-fpm (z.B. php8.5-fpm). Das Schlüsselwort php zielt auf alle installierten PHP-FPM-Versionen gleichzeitig ab. Für das Cache-Backend: redis-server, redis, und valkey werden als Aliase von akzeptiert valkey-server.

Valkey – der BSD-lizenzierte, Redis-kompatible Fork – ist im Standard-Stack enthalten und ersetzt ihn redis-server seit Cipi 4.5.6. Es wird mit einem Passwort installiert, an das gebunden ist localhost nur und seine Anmeldeinformationen (Benutzer, Passwort) werden darin gespeichert /etc/cipi/server.json und am Ende der Installation angezeigt. valkey-server wird zur Blacklist für unbeaufsichtigte Upgrades hinzugefügt – Cipi verwaltet es, also ist es nicht automatisch aktualisiert. Siehe dieValkey Weitere Informationen finden Sie im Abschnitt und die automatische Redis → Valkey-Migration.

cipi ssh – SSH-Schlüsselverwaltung

Verwalten Sie die autorisierten SSH-Schlüssel für cipi user – der Administrator-SSH-Einstiegspunkt. Die cipi user (group cipi-ssh) verwendet nur den öffentlichen Schlüssel; Root-Login ist deaktiviert. App-Benutzer (Gruppe cipi-apps) Mit Passwort verbinden – sieheSSH als der App-Benutzer.

Befehle

$ cipi ssh list                 # list all authorized keys with fingerprint, comment, and current-session marker
$ cipi ssh add [key]             # add a new SSH public key (validates format, prevents duplicates)
$ cipi ssh remove [n]            # remove a key by number
$ cipi ssh rename [n] [name]     # change the display name / comment of a key

# Structured output (v5.0.6+) — panel API
$ cipi ssh list --json

RUHE: GET|POST /api/ssh/keys, DELETE /api/ssh/keys/{n} (API 1.15.0+ / Cipi 5.0.6+).

Sicherheitsmechanismen

cipi ssh remove enthält zwei Sicherheitsmaßnahmen zur Verhinderung einer Aussperrung:

• Schutz der aktuellen Sitzung – Sie können den von Ihrem aktiven SSH verwendeten Schlüssel nicht entfernen Sitzung.
• Last-key protection — Sie können den letzten verbleibenden autorisierten Schlüssel nicht entfernen.

Wichtige Kommentare

SSH-Schlüssel werden mit intakten Originalkommentaren gespeichert, sodass sich die einzelnen Schlüssel leicht identifizieren lassen gehört dazu. Benutzen cipi ssh rename So ändern Sie den Anzeigenamen einer beliebigen Taste:

# list keys to find the number
$ cipi ssh list

# rename key #2
$ cipi ssh rename 2 "john-macbook"

E-Mail-Benachrichtigungen

Wenn SMTP konfiguriert ist, sendet Cipi jedes Mal eine E-Mail-Benachrichtigung, wenn ein Schlüssel hinzugefügt, entfernt oder umbenannt wird. Die Benachrichtigung umfasst den Server-Hostnamen, die IP-Adresse, den Schlüsselfingerabdruck, den Schlüsselkommentar, den Zeitstempel, und verbleibende Schlüsselanzahl. Umbenennungsbenachrichtigungen enthalten auch den alten und neuen Schlüsselnamen.

cipi – Server- und Selbstaktualisierung

Befehle der obersten Ebene für den Serverstatus und die Cipi-Selbstverwaltung.

$ cipi status              # CPU, RAM, disk, services, PHP versions, apps
$ cipi version             # show installed Cipi version
$ cipi self-update         # update Cipi to the latest version
$ cipi self-update --check # check for updates without installing

Zurücksetzen von Passwort und Anmeldeinformationen

Cipi bietet Befehle zum Neugenerieren von Passwörtern auf Serverebene. Neue Passwörter werden in gespeichert /etc/cipi/server.json (über Vault verschlüsselt) und auf dem Bildschirm angezeigt. Speichern Sie sie sofort — Sie werden nur einmal angezeigt.

$ cipi reset root-password              # regenerate the root Linux user SSH password
$ cipi reset db-password [--engine=…]   # regenerate root password (default or chosen engine)
$ cipi reset valkey-password           # regenerate the Valkey password and restart the service