Desde Cipi 5.1

cipi.yml — configuração que acompanha o código.

Um arquivo na raiz do seu repositório descreve o estado que um aplicativo espera no servidor: aliases de domínio, versão PHP e configurações por aplicativo, bancos de dados extras, trabalhadores de fila, o agendador, sua verificação de integridade e seus perfis de backup. Revise-o em uma solicitação pull e envie-o com o solte e deixecipi yml apply reconciliar o servidor com ele.

7 áreasAliases, PHP, php.ini, bancos de dados, trabalhadores, agendador, saúde e backups.
planejar → aplicarNada muda até você olhar para a diferença e dizer sim.
Fechado com falhaCom escopo para um aplicativo, nenhum comando shell em qualquer lugar do esquema.

Configuração do servidor, revisada como código

O estado do servidor geralmente reside em outro lugar: um painel, uma página wiki ou a memória de quem configurou a caixa. Um cipi.yml confirmado próximo ao seu aplicativo Laravel torna esse estado parte do mesmo pull request como o código que depende dele. Uma versão que adiciona uma fila também adiciona seu trabalhador. Um lançamento que precisa de um maior upload_max_filesize carrega isso. Reverta o código e a configuração será revertida de volta com isso.

O arquivo é declarativo: descreve o estado final, não as etapas. Cipi lê o que server possui, compara com o arquivo e mostra a diferença antes de tocar em qualquer coisa.

Os comandos

festa
$ 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 O que isso faz
cipi yml generate Imprime a configuração do aplicativo como está no servidor — aliases, versão PHP e configurações por aplicativo, bancos de dados extras, trabalhadores de fila lidos de Supervisor, o agendador e os perfis de backup que o aplicativo possui — como um arquivo pronto para confirmação.
cipi yml example Um modelo em branco e totalmente comentado. Passe um nome de aplicativo e os bancos de dados de espaço reservado e os perfis ficam dentro do namespace desse aplicativo, então o modelo é validado como está.
cipi yml validate Analisa o arquivo e verifica cada valor no esquema. Não muda nada.
cipi yml plan A diferença: cada alias, trabalhador, banco de dados, configuração e perfil que seriam adicionados, alterados ou removido. Leia isto antes de se inscrever.
cipi yml apply Aplica o plano. Adicionar --yes para scripts e CI.
cipi yml auto Ative ou não a reconciliação automática após cada implantação bem-sucedida. status relata a configuração atual.

O arquivo é pesquisado em current/cipi.yml, então current/cipi.yaml, então shared/cipi.yml - substituir por --file=<path>.

O que o arquivo pode configurar

app.aliases

Domínio apelidos

A lista declarada substitui a atual — um alias que você exclui do arquivo é removido Nginx. Curingas como*.myapp.com são aceitos, para subdomínios multilocatários. O o domínio primário nunca é gerenciado aqui.

Aliases nos documentos →
app.php · app.ini

versão PHP e php.ini

Fixe o aplicativo em PHP 8.3, 8.4 ou 8.5 (já instalado no servidor) e defina substituições por aplicativo — upload_max_filesize, post_max_size, memory_limit e o descanse. Os valores de todo o servidor permanecem com cipi ini set.

php.ini nos documentos →
bancos de dados

Extras bancos de dados

Além daquele criado com o aplicativo: relatórios, análises, o que o lançamento precisar, em MariaDB ou PostgreSQL. As credenciais chegam shared/cipi-databases.env e nunca são respondidos para o repositório. Bancos de dados são criados, nunca descartados.

Bancos de dados nos documentos →
trabalhadores

Trabalhadores de fila e Horizon

Declare cada fila com sua contagem de processos, tentativas e tempo limite, e Supervisor será reconciliado com combinar. Ou definir horizon: true e deixe Horizon possuir as filas.

Trabalhadores nos documentos →
agendar

O Laravel agendador

Uma volta booleana * * * * * artisan schedule:run ativado ou desativado para o aplicativo. Sem crontab edição, nenhuma entrada esquecida no próximo servidor.

Agendador nos documentos →
saúde

Verificação de saúde e reversão

Uma investigação HTTP em um dos domínios do próprio aplicativo, verificada a cada cinco minutos e novamente logo após cada implantação. Opcionalmente, reverta automaticamente uma versão com falha - apenas o link simbólico do código, as migrações não são desfeitas.

Verificações de integridade nos documentos →
backup.profiles

Cópia de segurança perfis

Perfis por aplicativo com escopo, programação, retenção, destinos e criptografia próprios — uma opção barata banco de dados executado a cada 30 minutos, uma cópia criptografada completa para S3 à noite. Os nomes dos perfis têm escopo para o aplicativo.

Backups nos documentos →
referência

Cada chave, documentado

O esquema completo, a ordem de pesquisa, as regras de validação e os ganchos de notificação residem no implantar capítulo da documentação.

Leia a referência →

Um arquivo completo

Você não precisa escrever à mão.cipi yml generate <app> imprime o que o servidor já tem; cometer isso e cipi yml plan relata nada para fazer.

festa
$ 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"
    - "*.myapp.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: ["meu aplicativo", "meuapp_*", "inquilino_*"]
      exclude_tables: ["*.trabalhos", "*.telescópio_*"]
      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

As implantações ignoram o arquivo até que você aceite

Nada acontece na implantação até você executar cipi yml auto <app> on. Com essa opção dada, cada bem sucedido implantar reconciliações - de ambos cipi deploy e o Git webhook. Um lançamento que não traz cipi.yml é um ambiente autônomo silencioso e um arquivo que falha na validação é relatado por e-mail (yml_fail) e nunca aplicado parcialmente. Um sucesso reconciliar fogos yml_apply.

festa
$ 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 que é seguro aceitar em vez do Git

O arquivo chega de um repositório, então qualquer pessoa que possa fazer commit controla seu conteúdo. É fechado com falha por toda parte:

Uma vez yml auto estiver ativado, qualquer pessoa que puder enviar para esse repositório poderá alterar os aliases do aplicativo, PHP configurações, trabalhadores, verificação de integridade e perfis de backup. Esse é o ponto da configuração como código - trate o acesso de gravação ao repositório de acordo.

Perguntas

Tenho que escrever o arquivo à mão?

Não. cipi yml generate <app>imprime a configuração atual do servidor do aplicativo como um pronto para comprometer cipi.ymle cipi yml example imprime um comentário em branco modelo se você preferir começar do zero.

Um commit pode quebrar meu servidor?

O esquema não carrega comandos shell nem caminhos de inclusão, um aplicativo só pode tocar em seus próprios bancos de dados e perfis de backup e um arquivo que falha na validação é rejeitado como um todo, em vez de aplicado na metade. As implantações ignoram o arquivo completamente até você virar cipi yml auto sobre.

O que acontece com as coisas que o arquivo não menciona?

Eles são deixados sozinhos. Somente as seções que você declara são reconciliadas — com uma exceção deliberada: a lista de alias é oficial, portanto, remover um alias do arquivo o remove do servidor.

Funciona com o Git webhook?

Sim. Com cipi yml auto em, ambos cipi deploy e uma implantação acionada por webhook reconciliar após um lançamento bem-sucedido.

Referência cipi.yml completa Instale Cipi