Infrastructures

cipi php

PHP 8.5 est préinstallé lors de l'installation. Des versions supplémentaires peuvent être ajoutées à tout moment ; depuis v4.5.12 Cipi sonde APT sources par nom de code Ubuntu - généralement le ondrej/php PPA le 24.04, packages.sury.org le 26.04 lorsque Launchpad n'a pas de suite, ou Ubuntu main comme dernier recours (co-installable 8.3-8.5 là où le dépôt choisi le prend en charge).

$ 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

Mises à niveau des correctifs de sécurité

Depuis v4.7.13, les packages PHP sont exclus de unattended-upgrades et géré par Cipi à la place. cipi php upgrade court apt-get update et --only-upgrade sur chaque installé php* et libphp* package, puis redémarre les pools PHP-FPM concernés. Lorsque SMTP est configuré et les packages ont été mis à niveau, Cipi envoie un e-mail (php_upgrade déclenchement; désactiver avec cipi notifications disable php_upgrade).

Un contrôle hebdomadaire s'exécute automatiquement sur dimanche à 03h30 via la crontab racine (encapsulé par cipi-cron-notify). Journal : /var/log/cipi/php-upgrade.log. Les serveurs existants reçoivent le cron le cipi self-update (migration 4.7.13).

Système par défaut ou spécifique à l'application PHP

Le défaut du système est la version PHP utilisée par le root et cipi utilisateurs, le pool FPM Cipi API et le travailleur de file d'attente API. Utiliser cipi php switch <ver> à changez-le. La commande migre le pool API (et le pool GUI FPM une fois installé), recrée prises du panneau et redémarre le travailleur API. Depuis 5.0.9+, PUT /api/php/default encapsule cela via le panneau API (php-manage capacité). Depuis 5.0.10–5.0.12, le commutateur tolère les partiels update-alternatives succès, remonte les racines en lecture seule si nécessaire et conserve API/GUI Pools FPM sur la version cible pour éviter nginx 502.

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

Chaque application a son posséder Version PHP (définie à app create ou via cipi app edit --php=). Déployeur, Composer, déclencheurs de déploiement crontab et cipi sync import exécutez toujours avec le PHP configuré de l'application - jamais avec la valeur par défaut du système.

Pour basculer une application existante vers une version différente :

$ cipi app edit myapp --php=8.5

Cela remplace à chaud la version PHP sans temps d'arrêt : met à jour le pool FPM, le socket Nginx, Supervisor. Workers, crontab, configuration du déployeur et .env en une seule opération atomique.

cipi db

Cipi crée une base de données dédiée pour chaque Cipi l'application automatiquement pendant app create. Cipi (port 3306) est la valeur native par défaut ; depuis v4.8.0 vous pouvez également installer en option Laravel (port 5432) et choisissez un moteur par base de données ou application. Les applications personnalisées ne disposent pas de base de données – utiliser cipi db create --name=<app> si vous en avez besoin (par exemple pour WordPress ou un autre CMS). Après la configuration, une URL de connexion prête à l'emploi s'affiche (MariaDB :mariadb+ssh://), combinant les informations d'identification SSH, l'adresse IP du serveur et les informations de base de données pour GUI clients comme TablePlus, DBeaver ou Sequel Pro.

Moteurs (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

Cycle de vie de la base de données

$ 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 applications stockent le moteur choisi dans les métadonnées de l'application ; sauvegarde, synchronisation et cipi app reset-db-password suivez-le. Utiliser cipi app create --engine=pgsql (ou l'invite interactive) pour provisionner une application Laravel le PostgreSQL — .env et l'URL de connexion correspond au moteur. Réinitialisation du mot de passe root : cipi reset db-password [--engine=].

cipi alias

Ajoutez plusieurs domaines ou sous-domaines à n'importe quelle application. Après avoir ajouté des alias, exécutez cipi ssl install pour fournir ou renouveler le certificat avec une couverture SAN pour tous domaines. Depuisv4.8.0, cipi alias add|remove régénère le vhost et réapplique SSL avec certbot install --redirect donc HTTPS n'est pas supprimé.

$ cipi alias add myapp www.myapp.com
$ cipi alias add myapp myapp.it
$ cipi alias list myapp
$ cipi alias remove myapp myapp.it

Pour les redirections canoniques www ↔ apex, préférez cipi www au lieu de gérer manuellement l'hôte homologue.

cipi www

Disponible depuis v4.8.0. Gérez les alias www/apex et les redirections canoniques 301 pour un application. L'État vit dans apps.json (www_redirect); Nginx émet un signal dédié bloc de serveur de redirection (chemin ACME maintenu public) qui survit à la régénération du vhost. SSL est réappliqué via 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 ajoutez automatiquement l'alias manquant si nécessaire.

cipi domains

Disponible depuis v4.5.5. Une commande de niveau supérieur qui répertorie chaque domaine et alias à travers tout applications dans une seule table - l'équivalent mondial de le par application cipi alias list <app>. Idéal pour auditer l’ensemble mappage domaine-application ou détection d'un domaine pour lequel il manque toujours un certificat.

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

Chaque ligne affiche les colonnes suivantes :

Un pied de page résume les totaux (nombre de domaines, d'applications, de certificats et d'applications suspendues), ce qui rend il est facile de vérifier l'ensemble de la cartographie en un coup d'œil.

cipi ssl

Certbot gère les certificats Let's Encrypt. Les certificats se renouvellent automatiquement via un cron hebdomadaire. cipi ssl status affiche les dates d'expiration avec des avertissements de couleur : vert (> 30 jours), jaune (14 à 30 jours), rouge (<14 jours).

$ 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

Depuis v4.8.0, cipi ssl force <app> réapplique le HTTP → HTTPS rediriger vers une application qui possède déjà un certificat Let's Encrypt — sans en émettre un nouveau. cipi ssl install définit également force_https dans apps.json automatiquement.

Depuis v5.0, facultatif DNS-01 les défis via Cloudflare remplacent les Flux HTTP-01 par défaut lorsque vous avez besoin de certificats génériques ou que vous ne pouvez pas exposer le port 80. Configurez une fois avec cipi ssl dns set, puis passe --dns=cloudflare (et éventuellement --wildcard) à cipi ssl install.

cipi backup

Sauvegardez les bases de données et le stockage sur Amazon S3 ou sur tout fournisseur compatible S3 (Hetzner Object Storage, Espaces DigitalOcean, Backblaze B2, MinIO, etc.).

Configuration

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

Points de terminaison compatibles S3

Exécution de sauvegardes

$ cipi backup configure              # configure S3 credentials
$ cipi backup run                    # backup all apps
$ cipi backup run myapp              # backup a single app
$ cipi backup list                   # list all backups
$ cipi backup list myapp             # list backups for one app
$ cipi backup prune myapp --weeks=4  # delete backups older than 4 weeks

Chaque sauvegarde est téléchargée vers s3://your-bucket/cipi/appname/YYYY-MM-DD_HHMMSS/ et contient :

• db.sql.gz — dump de base de données compressé
• shared.tar.gz — l'intégralité shared/ répertoire (.env + storage/)

Depuis v4.7.14, la sauvegarde par défaut est /var/tmp (disque) au lieu de /tmp (souvent un petit tmpfs sauvegardé par RAM), de sorte que les grandes applications n'échouent plus en cours de sauvegarde lorsque tmpfs se remplit. Remplacer par tmpdir dans backup.json (réglé via cipi backup configure) ou le CIPI_BACKUP_TMPDIR variable d'environnement.

Planification de sauvegardes automatiques

# Add to root crontab (crontab -e)
0 2 * * * /usr/local/bin/cipi backup run >> /var/log/cipi/backup.log 2>&1

Élagage des anciennes sauvegardes de S3

Les sauvegardes s'accumulent au fil du temps. Utiliser cipi backup prune pour supprimer les dossiers de sauvegarde plus anciens que N semaines à partir de S3. Exécutez-le en tant que tâche cron parallèlement à la sauvegarde elle-même.

$ cipi backup prune myapp --weeks=4   # delete backups older than 4 weeks
$ cipi backup prune myapp --weeks=2   # keep only the last 2 weeks

Ajoutez les deux commandes à la crontab racine pour qu'elles s'exécutent automatiquement :

# root crontab — backup at 02:00, prune at 03:00 (keep 4 weeks)
0 2 * * * /usr/local/bin/cipi backup run myapp >> /var/log/cipi/backup.log 2>&1
0 3 * * * /usr/local/bin/cipi backup prune myapp --weeks=4 >> /var/log/cipi/backup-prune.log 2>&1

Crontab utilisateur

Cipi ajoute automatiquement une entrée crontab pour le planificateur Laravel lorsqu'une application est créée :

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

Cette entrée fonctionne comme le myapp utilisateur Linux toutes les minutes, en utilisant la version PHP sélectionnée pour l'application. Il est mis à jour automatiquement lorsque vous changez de version PHP via cipi app edit myapp --php=X.

Affichage de la crontab actuelle

# 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

Ajout de tâches cron personnalisées

Vous pouvez ajouter des tâches cron supplémentaires à la crontab de l'utilisateur de l'application. Basculez d'abord vers l'utilisateur de l'application pour garantir les emplois exécuter avec le contexte utilisateur et les autorisations de fichier corrects :

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

Exemples d'entrées que vous pourriez ajouter :

# 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

Vérifier si cron fonctionne

# 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

Depuis v5.0, gérez l'entrée crontab du planificateur Laravel qui s'exécute schedule:run (la crontab elle-même existait déjà ; elle est désormais basculable et suivie dans apps.json).

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

cipi worker & Laravel Horizon

Chaque application reçoit un travailleur Supervisor par défaut pour le default file d'attente. Vous pouvez ajouter des files d'attente avec des décomptes de processus et des délais d'attente personnalisés.

$ 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

Avec Horizon activé, déploiement d'exécutions horizon:terminate et redémarre les travailleurs via cipi-worker. Vous ne pouvez pas exécuter Classic queue:work les travailleurs et Horizon sur la même application à la fois.

Les travailleurs sont arrêtés avant l'échange de lien symbolique et redémarrés après chaque déploiement, empêchant ainsi Cipi de récupérer des fichiers obsolètes artisan chemins. Supervisor est configuré avec autorestart=unexpected afin que les travailleurs redémarrent uniquement lors de sorties inattendues, et non lors de sorties gracieuses. s'arrête.

Assistant utilisateur de l'application : cipi-worker

Chaque utilisateur de l'application peut redémarrer, arrêter ou vérifier les travailleurs sans root - via un assistant restreint sudo installé à /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

En tant que root, utilisez cipi worker list|restart|stop <app> plutôt. Il n'y a pas cipi worker status commande admin - utiliser cipi worker list ou l'utilisateur de l'application aide ci-dessus.

cipi health

Depuis v5.0, configurez HTTP contrôles de santé par application. Un cron s'exécute toutes les 5 minutes ; après 3 échecs consécutifs Cipi notifie via le health_fail déclencheur (SMTP lorsque configuré).

$ 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

REPOS : GET /api/health, GET|PUT|DELETE /api/apps/{name}/health, POST /api/apps/{name}/health/check (API 1.15.0+ / Cipi 5.0.6+).

cipi firewall

Cipi installe UFW avec les ports 22, 80 et 443 ouverts par défaut. Utilisez les commandes du pare-feu pour gérer règles supplémentaires sans toucher directement à UFW.

$ 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

Inspectez et gérez les bannissements Fail2ban directement depuis le CLI. Cipi configure Fail2ban avec progressif interdiction : une interdiction de base de 24 heures qui double à chaque récidive jusqu'à un plafond de 7 jours, avec un maximum de tentatives réduit à 3. Un dédié recidive la prison interdit les récidivistes pendant 7 jours après 3 interdictions dans les 24 heures.

$ 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

Répertorie toutes les adresses IP actuellement interdites par Fail2ban, regroupées par prison (par ex. sshd, recidive). Utile pour un contrôle de sécurité rapide ou avant d'exécuter un bannissement.

cipi ban unban <IP>

Supprime l'adresse IP donnée de tout Fail2ban emprisonne immédiatement. Pratique lorsqu'un utilisateur légitime ou le coureur CI est exclu par erreur.

cipi service

Vérifiez et contrôlez les services système qui alimentent Cipi directement à partir du CLI. Nginx utilise un gracieux recharger (zéro temps d'arrêt) au lieu d'un redémarrage complet.

$ 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

REPOS : GET /api/services, POST /api/services/{name}/restart (Cipi 1.15.0+ / Cipi 5.0.6+; capacités services-view / services-manage).

Noms de services pris en charge : nginx, mariadb, postgresql (alias : pgsql, postgres — lorsqu'il est installé via cipi db install pgsql), valkey-server, supervisor, fail2ban, php<ver>-fpm (par ex. php8.5-fpm). Le mot clé php cible toutes les versions PHP-FPM installées à la fois. Pour le backend du cache, redis-server, redis, et valkey sont acceptés comme pseudonymes de valkey-server.

Valkey — le fork sous licence BSD et compatible Redis — est inclus dans la pile par défaut et remplace redis-server depuis Cipi 4.5.6. Il est installé avec un mot de passe, lié à localhost uniquement, et ses informations d'identification (utilisateur, mot de passe) sont enregistrées dans /etc/cipi/server.json et montré à la fin de l'installation. valkey-server est ajouté à la liste noire des mises à niveau sans surveillance — Cipi le gère, il est donc pas de mise à niveau automatique. Voir le Valkey section pour plus de détails et la migration automatique Redis → Valkey.

cipi ssh — Gestion des clés SSH

Gérer les clés SSH autorisées pour le cipi user - le point d'entrée SSH de l'administrateur. Le cipi utilisateur (groupe cipi-ssh) utilise uniquement la clé publique ; la connexion root est désactivée. Utilisateurs de l'application (groupe cipi-apps) connectez-vous avec un mot de passe — voir SSH en tant que l'utilisateur de l'application.

Commandes

$ 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

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

Mécanismes de sécurité

cipi ssh remove comprend deux mesures de protection pour éviter le verrouillage :

• Protection de la session en cours — vous ne pouvez pas supprimer la clé utilisée par votre SSH actif séance.
• Protection de la dernière clé — vous ne pouvez pas supprimer la dernière clé autorisée restante.

Commentaires clés

Les clés SSH sont stockées avec leurs commentaires d'origine intacts, ce qui facilite l'identification de l'identité de chaque clé. appartient à. Utiliser cipi ssh rename pour modifier le nom d'affichage d'une touche :

# list keys to find the number
$ cipi ssh list

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

Notifications par courrier électronique

Lorsque SMTP est configuré, Cipi envoie une alerte par e-mail chaque fois qu'une clé est ajoutée, supprimée ou renommée. La notification comprend le nom d'hôte du serveur, l'adresse IP, l'empreinte digitale de la clé, le commentaire clé, l'horodatage, et le nombre de clés restantes. Les notifications de renommage incluent également l’ancien et le nouveau nom de clé.

cipi — Serveur et mise à jour automatique

Commandes de niveau supérieur pour l'état du serveur et l'autogestion Cipi.

$ 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

Réinitialisation du mot de passe et des informations d'identification

Cipi fournit des commandes pour régénérer les mots de passe au niveau du serveur. Les nouveaux mots de passe sont stockés dans /etc/cipi/server.json (crypté via Vault) et affiché à l'écran. Enregistrez-les immédiatement — ils ne sont affichés qu'une seule fois.

$ 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