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.
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
$ 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
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.
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.
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.
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.
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.
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.profilesCó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ênciaCada 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.
$ 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" - "*.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.
$ 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:
- Só pode configurar um aplicativo que já existe – nunca crie, renomeie ou exclua um.
- Seus bancos de dados devem ser nomeados
<app>ou<app>_*, e seu backup perfis<app>ou<app>-*. - Seu URL de verificação de integridade deve ser resolvido para um dos domínios do próprio aplicativo — caso contrário, um commit poderia direcionar o sonda do servidor em um endereço interno e leia a resposta dos e-mails de alerta.
- Chaves desconhecidas são erros e nenhum campo contém um comando shell ou um caminho a ser incluído.
- O analisador implementa um subconjunto YAML deliberadamente pequeno e recusa âncoras, aliases, tags, chaves de mesclagem, bloquear escalares e mapeamentos de fluxo imediatamente.
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.