Skip to main content
fireflo-install automatiza o deployment à mão: pacotes, usuário de serviço, diretórios, artefato, configuração, banco, unit do systemd, firewall, e um smoke test no final. Ele instala apenas o gateway. O painel de controle tem seu próprio installer, e em um host novo você roda os dois.

​
Olhe antes de pular

Não muda nada. Reporta se o host tem o que precisa.

​
Ele pergunta primeiro, depois mostra as respostas

install coleta o que precisa, imprime cada decisão que está prestes a tomar, e espera. Nada é escrito até você concordar.
Adicione --yes para pular a confirmação em uma instalação por script, e --dry-run para ver as decisões sem tomá-las.
--dry-run mostra menos do que parece. Ele não pode reportar o que um gerenciador de pacotes puxaria, nem o que uma migration encontraria em um banco ao qual não se conectou. Leia como “as decisões que este script tomaria”, não “tudo o que mudaria neste host”.

​
As duas recusas

install recusa quando um diretório de configuração já existe. Ele não vai gerar um segundo par de tokens operacionais por cima do primeiro — o que deixaria o painel autenticando contra tokens que o gateway não tem mais.Se você tem configuração mas não tem serviço, o verbo é service, não install.
update nunca toca no diretório de configuração. Esse é o contrato que torna as atualizações seguras, e significa que uma chave de configuração nova introduzida por uma release não é adicionada ao seu arquivo — leia as release notes.

​
Escolhendo uma fonte no momento da instalação

--bootstrap popula um banco novo com o mínimo que fará iniciar; --import traz uma configuração de arquivo existente. Veja Choosing a source.

​
A primeira tarifa

Sem isto, o gateway inicia sem pricing. Uma mensagem que não case com nenhuma regra de tarifa é registrada como UNKNOWN, não como grátis — entregue, e cobrada de ninguém.

​
Portas, e uma faixa

Uma faixa deixa o installer escolher a próxima porta de listener livre, que é o que torna várias instâncias em um host práticas. Veja Várias instâncias.

​
Os dois tokens

O installer gera ambos e os escreve no arquivo de ambiente.
Eles precisam ser diferentes. smsg.ops.admin.token não definido, ou igual a smsg.ops.token, desabilita todo verbo de controle e eles respondem 404 — indistinguíveis de um token errado. Veja The operational endpoint.

​
Retenção de logs

--log-retain-days escreve uma regra tmpfiles.d que deleta logs rotacionados, nunca tocando nos quatro ativos. Esta é a única coisa que remove httpapi.log — o Quarkus faz rotate diário e mantém cada arquivo para sempre. Uma instalação manual precisa organizar isso por conta própria.

​
Depois que termina

Checa o artefato, a versão do Java, a porta de mensagens, a porta operacional, e se os dois tokens são genuinamente separados — na ordem que faz da primeira falha a informativa. Termina dizendo se o deployment já pode enviar, que é uma pergunta diferente de se está rodando.
Exit code 4 significa que o deployment está sólido mas os próprios dados não estão — por exemplo, nada está configurado para onde rotear. Esse é o resultado esperado logo após uma instalação --bootstrap, antes de você adicionar um fornecedor.

​
Os outros verbos

Lista completa de opções em fireflo-install.