Infraestructura

cipi php

PHP 8.5 está preinstalado durante la instalación. Se pueden agregar versiones adicionales en cualquier momento; desde v4.5.12 Cipi sondea APT fuentes por Ubuntu nombre en clave (generalmente el ondrej/php PPA el 24.04, paquetes.sury.org el 26.04 cuando Launchpad no tiene suite, o Ubuntu principal como último recurso (coinstalable 8.3–8.5 donde el repositorio elegido lo admita).

$ 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

Actualizaciones de parches de seguridad

desde v4.7.13, los paquetes PHP están excluidos de unattended-upgrades y administrado por Cipi en su lugar. cipi php upgrade corre apt-get update y --only-upgrade en cada instalado php* y libphp* paquete, luego reinicia los grupos PHP-FPM afectados. Cuando SMTP está configurado y Los paquetes se actualizaron, Cipi envía un correo electrónico (php_upgrade desencadenar; desactivar con cipi notifications disable php_upgrade).

Un control semanal se ejecuta automáticamente en Domingo a las 03:30 a través del crontab raíz (envuelto por cipi-cron-notify). Registro: /var/log/cipi/php-upgrade.log. Los servidores existentes reciben el cron el cipi self-update (migración 4.7.13).

Valor predeterminado del sistema versus específico de la aplicación PHP

el valor predeterminado del sistema es la versión PHP utilizada por el root y cipi usuarios, el grupo de FPM Cipi API y el trabajador de cola API. uso cipi php switch <ver> a cambiarlo. El comando migra el grupo API (y el grupo GUI FPM cuando está instalado), recrea enchufes del panel y reinicia el trabajador API. desde 5.0.9+, PUT /api/php/default envuelve esto a través del panel API (php-manage habilidad). desde 5.0.10–5.0.12, el interruptor tolera parcial update-alternatives éxito, vuelve a montar las raíces de solo lectura cuando es necesario y mantiene API/GUI FPM se agrupa en la versión de destino para evitar nginx 502.

DESCANSO: 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 (desde 5.0.6).

Cada aplicación tiene su propio PHP versión (establecida en app create o vía cipi app edit --php=). Implementador, Composer, activadores de implementación de crontab y cipi sync import Ejecútelo siempre con el PHP configurado de la aplicación, nunca con el valor predeterminado del sistema.

Para cambiar una aplicación existente a una versión diferente:

$ cipi app edit myapp --php=8.5

Esto intercambia en caliente la versión PHP sin tiempo de inactividad: actualiza el grupo de FPM, el socket Nginx, Supervisor trabajadores, crontab, configuración del implementador y .env en una operación atómica.

cipi db

Cipi crea una base de datos dedicada para cada Laravel aplicación automáticamente durante app create. MariaDB (puerto 3306) es el valor predeterminado nativo; desde v4.8.0 También puedes instalar opcional. PostgreSQL (puerto 5432) y elija un motor por base de datos o aplicación. Las aplicaciones personalizadas no obtienen una base de datos. usar cipi db create --name=<app> si necesita uno (por ejemplo, para WordPress u otro CMS). Después de la configuración, se muestra una URL de conexión lista para usar (MariaDB:mariadb+ssh://), combinando credenciales SSH, IP del servidor e información de la base de datos para GUI clientes como TablePlus, DBeaver o Sequel Pro.

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

Ciclo de vida de la base de datos

$ 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 aplicaciones almacenan el motor elegido en metadatos de la aplicación; copia de seguridad, sincronización y cipi app reset-db-password síguelo. uso cipi app create --engine=pgsql (o el mensaje interactivo) para aprovisionar una aplicación Laravel en PostgreSQL — .env y la URL de conexión coincide con el motor. Restablecer contraseña raíz: cipi reset db-password [--engine=].

cipi alias

Agregue múltiples dominios o subdominios a cualquier aplicación. Después de agregar alias, ejecute cipi ssl install para aprovisionar o renovar el certificado con cobertura SAN para todos dominios. desdev4.8.0, cipi alias add|remove regenera el vhost y vuelve a aplicar SSL con certbot install --redirect entonces HTTPS no se elimina.

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

Para redirecciones canónicas www ↔ apex, prefiera cipi www en lugar de gestionar el host homólogo manualmente.

cipi www

Disponible desde v4.8.0. Administre alias www/apex y redireccionamientos 301 canónicos para un aplicación. El estado vive en apps.json (www_redirect); Nginx emite un dedicado bloque de servidor de redirección (la ruta ACME se mantiene pública) que sobrevive a la regeneración de vhost. SSL se vuelve a aplicar vía 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 Agregue automáticamente el alias que falta cuando sea necesario.

cipi domains

Disponible desde v4.5.5. Un comando de nivel superior que enumera cada dominio y alias en todos aplicaciones en una sola tabla: la contraparte global de la por aplicación cipi alias list <app>. Ideal para auditar el conjunto mapeo de dominio a aplicación o detección de un dominio al que todavía le falta un certificado.

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

Cada fila muestra las siguientes columnas:

Un pie de página resume los totales (número de dominios, aplicaciones, certificados y aplicaciones suspendidas) que hacen Es fácil auditar todo el mapeo de un vistazo.

cipi ssl

Certbot gestiona Let's Encrypt certificados. Los certificados se renuevan automáticamente mediante un cron semanal. cipi ssl status muestra fechas de vencimiento con advertencias codificadas por colores: verde (>30 días), amarillo (14–30 días), rojo (<14 días).

$ 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

desde v4.8.0, cipi ssl force <app> vuelve a aplicar el HTTP → HTTPS redireccionamiento para una aplicación que ya tiene un certificado Let's Encrypt, sin emitir uno nuevo. cipi ssl install también establece force_https en apps.json automáticamente.

desde v5.0, opcional DNS-01 Los desafíos a través de Cloudflare reemplazan el flujo predeterminado HTTP-01 cuando necesita certificados comodín o no puede exponer el puerto 80. Configure una vez con cipi ssl dns set, luego pasa --dns=cloudflare (y opcionalmente --wildcard) a cipi ssl install.

cipi backup

Realice una copia de seguridad de las bases de datos y el almacenamiento en Amazon S3 o cualquier proveedor compatible con S3 (Hetzner Object Storage, Espacios DigitalOcean, Backblaze B2, MinIO, etc.).

Configuración

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

Puntos finales compatibles con S3

Ejecutando copias de seguridad

$ 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

Cada copia de seguridad se carga en s3://your-bucket/cipi/appname/YYYY-MM-DD_HHMMSS/ y contiene:

• db.sql.gz — volcado de base de datos comprimida
• shared.tar.gz - todo el shared/ directorio (.env + storage/)

desde v4.7.14, la preparación de la copia de seguridad tiene como valor predeterminado /var/tmp (disco) en lugar de /tmp (a menudo un pequeño tmpfs respaldado por RAM), por lo que las aplicaciones grandes ya no fallan a mitad de la copia de seguridad cuando tmpfs se llena. Anular con tmpdir en backup.json (establecido a través de cipi backup configure) o el CIPI_BACKUP_TMPDIR variable de entorno.

Programar copias de seguridad automáticas

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

Eliminación de copias de seguridad antiguas de S3

Las copias de seguridad se acumulan con el tiempo. uso cipi backup prune para eliminar carpetas de respaldo anteriores a N semanas de S3. Ejecútelo como un trabajo cron junto con la copia de seguridad.

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

Agregue ambos comandos al crontab raíz para que se ejecuten automáticamente:

# 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 de usuario

Cipi agrega automáticamente una entrada crontab para el programador Laravel cuando se crea una aplicación:

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

Esta entrada se ejecuta como myapp Usuario de Linux cada minuto, usando la versión PHP seleccionada para la aplicación. Se actualiza automáticamente cuando cambia la versión PHP a través de cipi app edit myapp --php=X.

Ver el crontab actual

# 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

Agregar trabajos cron personalizados

Puede agregar cron trabajos adicionales al crontab del usuario de la aplicación. Cambie primero al usuario de la aplicación para garantizar trabajos ejecutar con el contexto de usuario y permisos de archivo correctos:

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

Entradas de ejemplo que podría agregar:

# 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

Comprobando si cron está funcionando

# 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

desde v5.0, administre la entrada crontab del programador Laravel que se ejecuta schedule:run (el crontab en sí ya existía; ahora se puede alternar y rastrear en apps.json).

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

cipi worker & Laravel Horizon

Cada aplicación obtiene un trabajador Supervisor predeterminado para el default cola. Puedes agregar adicionales colas con recuentos de procesos personalizados y tiempos de espera.

$ 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

con Horizon habilitado, implementar ejecuciones horizon:terminate y se reinicia trabajadores vía cipi-worker. No puedes ejecutar clásico queue:work trabajadores y Horizon en la misma aplicación a la vez.

Los trabajadores se detienen antes del intercambio de enlaces simbólicos y se reinician después de cada implementación, lo que evita Supervisor evite que se vuelva obsoleto artisan caminos. Supervisor está configurado con autorestart=unexpected por lo que los trabajadores sólo se reinician en salidas inesperadas, no en salidas elegantes. se detiene.

Ayudante de usuario de la aplicación: cipi-worker

Cada usuario de la aplicación puede reiniciar, detener o verificar trabajadores sin root, a través de un asistente restringido sudo instalado en /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

Como root, use cipi worker list|restart|stop <app> en cambio. no hay cipi worker status comando de administrador - usar cipi worker list o el usuario de la aplicación ayudante arriba.

cipi health

desde v5.0, configure HTTP comprobaciones de estado por aplicación. Un cron se ejecuta cada 5 minutos; después 3 fallas consecutivas Cipi notifica vía el health_fail disparador (SMTP cuando configurado).

$ 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

DESCANSO: 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 instala UFW con los puertos 22, 80 y 443 abiertos de forma predeterminada. Utilice los comandos del firewall para administrar reglas adicionales sin tocar UFW directamente.

$ 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

Inspeccione y administre las prohibiciones de Fail2ban directamente desde CLI. Cipi configura Fail2ban con progresivo prohibición: una prohibición base de 24 horas que se duplica con cada infracción repetida hasta un límite de 7 días, con un máximo de reintentos reducido a 3. Un dedicado recidive La cárcel prohíbe a los reincidentes durante 7 días después de 3 prohibiciones. dentro de las 24 horas.

$ 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

Enumera todas las IP actualmente prohibidas por Fail2ban, agrupadas por cárcel (p. ej. sshd, recidive). Útil para un control de seguridad rápido o antes de ejecutar una desbanificación.

cipi ban unban <IP>

Elimina la IP proporcionada de todos Fail2ban cárceles a la vez. Útil cuando un usuario legítimo o el corredor de CI queda bloqueado por error.

cipi service

Verifique y controle los servicios del sistema que alimentan Cipi directamente desde CLI. Nginx usa un elegante recarga (tiempo de inactividad cero) en lugar de un reinicio completo.

$ 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

DESCANSO: GET /api/services, POST /api/services/{name}/restart (API 1.15.0+ / Cipi 5.0.6+; habilidades services-view / services-manage).

Nombres de servicios admitidos: nginx, mariadb, postgresql (alias: pgsql, postgres — cuando se instala mediante cipi db install pgsql), valkey-server, supervisor, fail2ban, php<ver>-fpm (por ej. php8.5-fpm). La palabra clave php apunta a todas las versiones PHP-FPM instaladas a la vez. Para el backend de caché, redis-server, redis, y valkey son aceptados como alias de valkey-server.

Valkey, la bifurcación compatible con Redis y con licencia BSD, se incluye en la pila predeterminada y reemplaza redis-server desde Cipi 4.5.6. Se instala con una contraseña, vinculada a localhost únicamente, y sus credenciales (usuario, contraseña) se guardan en /etc/cipi/server.json y se muestra al final de la instalación. valkey-server se agrega a la lista negra de actualizaciones desatendidas: Cipi lo administra, por lo que es no se actualiza automáticamente. Ver el Valkey sección para más detalles y la migración automática Redis → Valkey.

cipi ssh — Gestión de claves SSH

Gestionar las claves SSH autorizadas para el cipi usuario: el punto de entrada SSH del administrador. el cipi usuario (grupo cipi-ssh) utiliza únicamente clave pública; El inicio de sesión raíz está deshabilitado. Usuarios de la aplicación (grupo cipi-apps) conectarse con contraseña — ver SSH como el usuario de la aplicación.

Comandos

$ 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

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

Mecanismos de seguridad

cipi ssh remove incluye dos salvaguardas para evitar el bloqueo:

• Protección de la sesión actual — no puedes eliminar la clave utilizada por tu SSH activo sesión.
• Protección de última clave — No puede eliminar la última clave autorizada restante.

Comentarios clave

Las claves SSH se almacenan con sus comentarios originales intactos, lo que facilita identificar quién es cada clave. pertenece a. uso cipi ssh rename para cambiar el nombre para mostrar de cualquier tecla:

# list keys to find the number
$ cipi ssh list

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

Notificaciones por correo electrónico

Cuando se configura SMTP, Cipi envía una alerta por correo electrónico cada vez que se agrega, elimina o cambia el nombre de una clave. La notificación incluye el nombre de host del servidor, la dirección IP, la huella digital de la clave, el comentario de la clave, la marca de tiempo, y el número de claves restantes. Las notificaciones de cambio de nombre también incluyen el nombre de la clave nueva y antigua.

cipi — Servidor y actualización automática

Comandos de nivel superior para el estado del servidor y la autogestión 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

Restablecimiento de contraseña y credenciales

Cipi proporciona comandos para regenerar contraseñas a nivel de servidor. Las nuevas contraseñas se almacenan en /etc/cipi/server.json (cifrado a través de Vault) y mostrado en la pantalla. Guárdalos inmediatamente — se muestran solo una vez.

$ 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