Depuis Cipi 5.1

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.

7 zonesAlias, PHP, php.ini, bases de données, Workers, planificateur, santé et sauvegardes.
planifier → postulerRien ne change jusqu'à ce que vous regardiez la différence et disiez oui.
Fermé en cas d'échecLimité à une seule application, aucune commande shell n'importe où dans le schéma.

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

coup
$ 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

app.alias

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.

Alias dans la documentation →
app.php · app.ini

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.

php.ini dans la documentation →
bases de données

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.

Bases de données dans la documentation →
travailleurs

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.

Travailleurs dans la documentation →
calendrier

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.

Planificateur dans la documentation →
santé

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.profils

Sauvegarde 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érence

Chaque 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.

coup
$ cipi yml generate myapp > cipi.yml   # then commit it
$ cipi yml plan myapp                  # reports nothing to do
yaml
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.

coup
$ 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 :

Une fois 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.

Référence complète cipi.yml Installer Cipi