cipi.yml - configuration fournie avec le code.
Un fichier à la racine de votre référentiel décrit l'état attendu par une application sur le
serveur : alias de domaine, version PHP et paramètres par application, bases de données supplémentaires, gestionnaires de file d'attente, le
planificateur, son bilan de santé et ses profils de sauvegarde. Examinez-le dans une pull request, envoyez-le avec le
relâchez et laissezcipi yml apply réconcilier le serveur avec lui.
Configuration du serveur, revue comme le code
L'état du serveur réside généralement ailleurs : un panneau, une page wiki ou la mémoire de celui qui a configuré la boîte.
Un cipi.yml validé à côté de votre application Laravel fait que cet état fait partie du même pull
request comme code qui en dépend. Une version qui ajoute une file d'attente ajoute également son travailleur. Une sortie qui
a besoin d'un plus grand upload_max_filesize le porte. Annulez le code et la configuration est lancée
reviens avec ça.
Le fichier est déclaratif: il décrit l'état final, pas les étapes. Cipi lit ce que le le serveur l'a, le compare avec le fichier et vous montre la différence avant de toucher quoi que ce soit.
Les commandes
$ 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
| Commande | Ce que ça fait |
|---|---|
cipi yml generate |
Imprime la configuration de l'application tel qu'il est sur le serveur — alias, version PHP et les paramètres par application, les bases de données supplémentaires, les files d'attente relus à partir de Supervisor, le planificateur et les profils de sauvegarde que possède l'application - sous forme de fichier prêt à être validé. |
cipi yml example |
Un modèle vierge entièrement commenté. Transmettez un nom d'application et les bases de données d'espace réservé et les profils atterrissent dans l'espace de noms de cette application, le modèle est donc validé tel quel. |
cipi yml validate |
Analyse le fichier et vérifie chaque valeur par rapport au schéma. Cela ne change rien. |
cipi yml plan |
La différence : chaque alias, travailleur, base de données, paramètre et profil qui serait ajouté, modifié ou supprimé. Lisez ceci avant de postuler. |
cipi yml apply |
Applique le plan. Ajouter --yes pour les scripts et CI. |
cipi yml auto |
Activez ou désactivez le rapprochement automatique après chaque déploiement réussi.
status rapporte le réglage actuel. |
Le fichier est recherché dans current/cipi.yml, alors current/cipi.yaml, alors
shared/cipi.yml — remplacer par --file=<path>.
Ce que le fichier peut configurer
Domaine pseudonymes
La liste déclarée remplace la liste actuelle — un alias que vous supprimez du fichier est supprimé de
Nginx. Caractères génériques tels que*.myapp.com sont acceptés, pour les sous-domaines multi-locataires. Le
le domaine principal n'est jamais géré ici.
version PHP et php.ini
Épinglez l'application sur PHP 8.3, 8.4 ou 8.5 (déjà installée sur le serveur) et définissez des remplacements par application :
upload_max_filesize, post_max_size, memory_limit et le
repos. Les valeurs à l'échelle du serveur restent les mêmes cipi ini set.
Supplémentaire bases de données
Au-delà de celui créé avec l'application : reporting, analytique, quels que soient les besoins de la release, en MariaDB ou
PostgreSQL. Les informations d’identification arrivent shared/cipi-databases.env et ne sont jamais réécrits
au référentiel. Les bases de données sont créées, jamais supprimées.
Travailleurs de file d'attente et Horizon
Déclarez chaque file d'attente avec son nombre de processus, ses tentatives et son délai d'attente, et Supervisor est réconcilié avec
correspondre. Ou définir horizon: true et laissez Horizon posséder les files d'attente à la place.
Le Laravel planificateur
Un tour booléen * * * * * artisan schedule:run activé ou désactivé pour l'application. Pas de crontab
édition, aucune entrée oubliée sur le serveur suivant.
Bilan de santé et restauration
Une sonde HTTP sur l'un des domaines propres de l'application, vérifiée toutes les cinq minutes et à nouveau juste après chaque déploiement. Facultativement, annulez automatiquement une version défaillante - le lien symbolique du code uniquement, les migrations ne se défont pas.
Bilans de santé dans la documentation → sauvegarde.profilsSauvegarde profils
Profils par application avec leur propre portée, calendrier, conservation, destinations et cryptage : un système bon marché base de données exécutée toutes les 30 minutes, une copie cryptée complète à S3 la nuit. Les noms de profil sont limités à l'application.
Sauvegardes dans la documentation → référenceChaque clé, documenté
Le schéma complet, l'ordre de recherche, les règles de validation et les hooks de notification se trouvent dans le chapitre déployer de la documentation.
Lire la référence →Un dossier complet
Vous n'êtes pas obligé de l'écrire à la main. cipi yml generate <app> imprime ce que le serveur
l'a déjà fait ; commettre cela et cipi yml plan rapporte rien à faire.
$ 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.myapp.com" - "*.monapp.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: ["monapplication", "monapplication_*", "locataire_*"] exclude_tables: ["*.emplois", "*.télescope_*"] 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
Les déploiements ignorent le fichier jusqu'à ce que vous vous y inscriviez
Rien ne se passe lors du déploiement jusqu'à ce que vous exécutiez cipi yml auto <app> on. Avec cet opt-in donné,
chaque réussi déployer des rapprochements - des deux cipi deploy et le connard
webhook. Une version qui ne porte aucun cipi.yml est une opération silencieuse et un fichier qui échoue à la validation
est signalé par email (yml_fail) et jamais partiellement appliqué. Un succès
réconcilier les incendies 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
Pourquoi il est prudent d'accepter via Git
Le fichier provient d'un référentiel, donc toute personne pouvant valider contrôle son contenu. Il est fermé en panne partout :
- Cela ne peut que configurer une application qui existe déjà – ne jamais créer, renommer ou supprimer un.
- Ses bases de données doivent être nommées
<app>ou<app>_*, et sa sauvegarde profils<app>ou<app>-*. - Son URL de contrôle de santé doit correspondre à l'un des domaines propres à l'application. Dans le cas contraire, une validation pourrait viser le sondeur du serveur à une adresse interne et relisez la réponse dans les e-mails d'alerte.
- Les clés inconnues sont des erreurs et aucun champ ne contient de commande shell ou de chemin à inclure.
- L'analyseur implémente un sous-ensemble YAML délibérément petit et refuse les ancres, les alias, les balises, les clés de fusion, bloquer les scalaires et les mappages de flux.
yml auto est activé, toute personne pouvant accéder à ce référentiel peut modifier les alias de l'application,
PHP paramètres, travailleurs, bilan de santé et profils de sauvegarde. C'est le point de la configuration en tant que code -
traitez l'accès en écriture au dépôt en conséquence.Questions
Dois-je écrire le fichier à la main ?
Non. cipi yml generate <app>imprime la configuration actuelle du serveur de l'application sous forme de
prêt à s'engager cipi.yml, et cipi yml example imprime un blanc commenté
modèle si vous préférez repartir de zéro.
Un commit peut-il casser mon serveur ?
Le schéma ne contient aucune commande shell ni aucun chemin d'inclusion, une application ne peut toucher que ses propres bases de données et
profils de sauvegarde, et un fichier qui échoue à la validation est rejeté dans son ensemble plutôt que appliqué à moitié.
Les déploiements ignorent complètement le fichier jusqu'à ce que vous activiez cipi yml auto sur.
Qu’arrive-t-il aux choses que le dossier ne mentionne pas ?
Ils sont laissés seuls. Seules les sections que vous déclarez sont rapprochées — à une exception délibérée : la liste des alias fait autorité, donc la suppression d'un alias du fichier le supprime du serveur.
Est-ce que ça marche avec Git webhook ?
Oui. Avec cipi yml auto sur, les deux cipi deploy et un déploiement déclenché par webhook
se réconcilier après une sortie réussie.