cipi.yml - configuración que se envía con el código.
Un archivo en la raíz de su repositorio describe el estado que espera una aplicación en el
servidor: alias de dominio, versión PHP y configuración por aplicación, bases de datos adicionales, trabajadores en cola, el
programador, su verificación de estado y sus perfiles de respaldo. Revíselo en una solicitud de extracción, envíelo con el
soltar y dejarcipi yml apply reconciliar el servidor con él.
Configuración del servidor, revisada como código.
El estado del servidor generalmente reside en otro lugar: un panel, una página wiki o la memoria de quien configuró el cuadro.
un cipi.yml comprometido junto a su aplicación Laravel hace que ese estado sea parte del mismo pull
request como el código que depende de ello. Una versión que agrega una cola también agrega su trabajador. Una liberación que
necesita un mas grande upload_max_filesize lo lleva. Revierte el código y la configuración se revierte.
De vuelta con eso.
El archivo es declarativo: describe el estado final, no los pasos. Cipi lee lo que tiene el servidor, lo compara con el archivo y le muestra la diferencia antes de tocar nada.
los comandos
$ 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
| Comando | que hace |
|---|---|
cipi yml generate |
Imprime la configuración de la aplicación. tal como está en el servidor — alias, versión PHP y configuraciones por aplicación, bases de datos adicionales, trabajadores de cola que leen de nuevo desde Supervisor, el programador y los perfiles de respaldo que posee la aplicación, como un archivo listo para confirmar. |
cipi yml example |
Una plantilla en blanco y completamente comentada. Pase el nombre de una aplicación y las bases de datos de marcador de posición y Los perfiles aterrizan dentro del espacio de nombres de esa aplicación, por lo que la plantilla se valida tal cual. |
cipi yml validate |
Analiza el archivo y compara cada valor con el esquema. No cambia nada. |
cipi yml plan |
La diferencia: cada alias, trabajador, base de datos, configuración y perfil que se agregaría o cambiaría o eliminado. Lea esto antes de presentar la solicitud. |
cipi yml apply |
Aplica el plan. Añadir --yes para scripts y CI. |
cipi yml auto |
Opte por participar (o no) en la conciliación automática después de cada implementación exitosa.
status informa la configuración actual. |
El archivo se busca en current/cipi.yml, entonces current/cipi.yaml, entonces
shared/cipi.yml — anular con --file=<path>.
Qué puede configurar el archivo
Dominio alias
La lista declarada reemplaza a la actual: un alias que elimine del archivo se eliminará de
Nginx. Comodines como*.myapp.com se aceptan, para subdominios multiinquilino. el
El dominio principal nunca se administra aquí.
versión PHP y php.ini
Ancle la aplicación a PHP 8.3, 8.4 u 8.5 (ya instalada en el servidor) y configure anulaciones por aplicación:
upload_max_filesize, post_max_size, memory_limit y el
descansar. Los valores de todo el servidor se mantienen cipi ini set.
Adicional bases de datos
Más allá del creado con la aplicación: informes, análisis, lo que sea que necesite la versión, en MariaDB o
PostgreSQL. Las credenciales aterrizan en shared/cipi-databases.env y nunca se les responde
al repositorio. Las bases de datos se crean, nunca se eliminan.
Trabajadores de cola y Horizon
Declare cada cola con su recuento de procesos, intentos y tiempo de espera, y Supervisor se concilia con
partido. O establecer horizon: true y dejar que Horizon sea dueño de las colas.
El Laravel planificador
Un giro booleano * * * * * artisan schedule:run activar o desactivar para la aplicación. Sin crontab
edición, ninguna entrada olvidada en el siguiente servidor.
control de salud y revertir
Una sonda HTTP en uno de los dominios propios de la aplicación, verificada cada cinco minutos y nuevamente inmediatamente después cada despliegue. Opcionalmente, revertir automáticamente una versión defectuosa: solo el enlace simbólico del código, las migraciones no se deshacen.
Controles de salud en los documentos → perfiles.de.copia de seguridadCopia de seguridad perfiles
Perfiles por aplicación con su propio alcance, programación, retención, destinos y cifrado: una opción económica La base de datos se ejecuta cada 30 minutos, una copia cifrada completa a S3 por la noche. Los nombres de los perfiles tienen alcance a la aplicación.
Copias de seguridad en los documentos → referenciacada llave, documentado
El esquema completo, el orden de búsqueda, las reglas de validación y los enlaces de notificación se encuentran en el implementar el capítulo de la documentación.
Leer la referencia →un archivo completo
No es necesario que lo escribas a mano. cipi yml generate <app> imprime lo que el servidor
ya lo tiene; comete eso y cipi yml plan no informa nada que hacer.
$ cipi yml generate myapp > cipi.yml # then commit it $ cipi yml plan myapp # reports nothing to do
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.miaplicación.com" - "*.miaplicación.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: ["miaplicación", "miaplicación_*", "inquilino_*"] exclude_tables: ["*.trabajos", "*.telescopio_*"] 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
Las implementaciones ignoran el archivo hasta que usted opte por participar
No sucede nada durante la implementación hasta que ejecutas cipi yml auto <app> on. Con esa aceptación dada,
cada exitoso implementar conciliaciones - de ambos cipi deploy y el git
webhook. Un lanzamiento que no lleva cipi.yml es una operación silenciosa y un archivo que no pasa la validación
se informa por correo electrónico (yml_fail) y nunca aplicado parcialmente. Un exitoso
reconciliar fuegos yml_apply.
$ 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
Por qué es seguro aceptar a través de Git
El archivo llega desde un repositorio, por lo que cualquiera que pueda confirmarlo controla su contenido. Está cerrado a prueba de fallos. a lo largo de:
- Sólo puede configurar una aplicación que ya existe: nunca la crees, la cambies de nombre ni la elimines uno.
- Sus bases de datos deben tener nombre
<app>o<app>_*, y su respaldo perfiles<app>o<app>-*. - Su URL de verificación de estado debe resolverse en uno de los dominios propios de la aplicación; de lo contrario, una confirmación podría apuntar al Prober del servidor en una dirección interna y leer la respuesta de los correos electrónicos de alerta.
- Las claves desconocidas son errores y ningún campo contiene un comando de shell o una ruta para incluir.
- El analizador implementa un subconjunto YAML deliberadamente pequeño y rechaza anclajes, alias, etiquetas, claves de combinación, bloquear escalares y mapeos de flujo directamente.
yml auto está activado, cualquiera que pueda acceder a ese repositorio puede cambiar los alias de la aplicación,
PHP configuración, trabajadores, verificación de estado y perfiles de respaldo. Ese es el objetivo de la configuración como código:
Trate el acceso de escritura al repositorio en consecuencia.Preguntas
¿Tengo que escribir el archivo a mano?
No. cipi yml generate <app>imprime la configuración actual del servidor de la aplicación como un
listo para comprometerse cipi.yml, y cipi yml example imprime un comentario en blanco
plantilla si prefieres empezar desde cero.
¿Puede una confirmación dañar mi servidor?
El esquema no incluye comandos de shell ni rutas de inclusión, una aplicación solo puede tocar sus propias bases de datos y
perfiles de copia de seguridad, y un archivo que no pasa la validación se rechaza en su totalidad en lugar de aplicarse a medias.
Las implementaciones ignoran el archivo por completo hasta que gire cipi yml auto en.
¿Qué pasa con las cosas que el archivo no menciona?
Se quedan solos. Sólo se concilian las secciones que usted declara, con una excepción deliberada: la lista de alias tiene autoridad, por lo que eliminar un alias del archivo lo elimina del servidor.
¿Funciona con Git webhook?
Sí. con cipi yml auto encendido, ambos cipi deploy y un despliegue activado por webhook
reconciliarse después de una liberación exitosa.