Corrige boot: storage.yml versionado e bin/docker-boot via bash

This commit is contained in:
2026-08-27 17:16:17 -03:00
parent ad1a071e4b
commit 5a438d9812
3 changed files with 34 additions and 2 deletions

View File

@@ -48,4 +48,5 @@ EXPOSE 3000
# O boot real (migrations, cron, servidor) mora em bin/docker-boot — ver os
# comentários lá. CMD aqui é só o fallback de quem roda a imagem sem o compose.
CMD ["bin/docker-boot"]
# (via `bash` — ver o motivo no docker-compose.yml)
CMD ["bash", "bin/docker-boot"]

26
config/storage.yml Normal file
View File

@@ -0,0 +1,26 @@
# Serviços de armazenamento do Active Storage.
#
# POR QUE ESTE ARQUIVO É VERSIONADO (e por que o boot morre sem ele):
# `config/application.rb` faz `require "rails/all"`, então o engine do Active
# Storage SEMPRE carrega, e os dois `config/environments/*.rb` definem
# `active_storage.service = :local`. Com um serviço definido, o Rails exige este
# arquivo durante o `initialize!` e derruba o servidor com:
# Couldn't find Active Storage configuration in /app/config/storage.yml
#
# Ele nunca esteve no git — existia criado à mão em cada servidor. Em 27/08/2026
# a pasta do deploy foi recriada e o arquivo se perdeu junto com o `.env`,
# derrubando o boot depois das migrations. Não há segredo nenhum aqui (só
# caminhos de disco), então o lugar dele é no repositório.
#
# ⚠️ Se um dia o app deixar de usar Active Storage, o certo é remover as linhas
# `active_storage.service` dos environments — não apagar este arquivo.
test:
service: Disk
root: <%= Rails.root.join("tmp/storage") %>
# A pasta `storage/` já existe no repo (com `.keep`); o CONTEÚDO é ignorado pelo
# git (`.gitignore`: `/storage/*`), como deve ser.
local:
service: Disk
root: <%= Rails.root.join("storage") %>

View File

@@ -28,7 +28,12 @@ services:
# Todo o boot (migrations, cron, Puma) mora em bin/docker-boot, com o
# motivo de cada passo comentado lá. Ficava aqui como uma linha só de
# `bash -c`, ilegível e impossível de depurar quando um passo falhava.
command: ["bin/docker-boot"]
#
# `bash` explícito de propósito, em vez de chamar o script direto: a pasta
# do projeto vive num share do NAS e o BIT DE EXECUÇÃO se perde ao copiar
# por SMB/File Station. Sem isto, o deploy morreria com um
# "permission denied" que não tem nada a ver com o script.
command: ["bash", "bin/docker-boot"]
# `unless-stopped`: sobe sozinho depois de queda do processo, de reboot do
# servidor e de `docker compose up`, e SÓ fica parado se alguém der