Instalação¶
O Início rápido leva uma máquina até um canal tocando. Esta página trata do que a instalação realmente faz e de como implantar o Catena em produção: do que a entrega se compõe, onde moram os segredos, como conectar um PostgreSQL externo e quais portas se abrem.
Os pacotes¶
O Catena se instala a partir de dois pacotes — um por papel da máquina:
- catena — a máquina central: a interface do console, a unidade
catena.service, o diretório/etc/catenae uma configuração com a seçãocentral:— exatamente o que transforma a caixa numa instalação central. Instala automaticamente o servidor de streaming exatamente da sua versão, e o PostgreSQL. - catena-streamer — um streamer aderido: o mesmo produto no papel de máquina do cluster, sem console e sem seção
central:. Aderir ao cluster são três linhas em/etc/catena/streamer.env.
Os plugins de codificação chegam como dependência recomendada: o servidor roda sem eles, mas não tem com que codificar.
O pós-instalação do pacote catena provisiona a caixa: cria o papel e o banco catena no PostgreSQL, gera as senhas do banco e do administrador e as grava em /etc/catena/secrets.env (dono root, modo 0600):
DATABASE_URL=postgres://catena:...@127.0.0.1:5432/catena
EDIT_AUTH_PASSWORD=...
A unidade conecta esse arquivo como EnvironmentFile. Atualizações do pacote não rotacionam os segredos — uma vez gravados, sobrevivem a qualquer upgrade.
A instalação pede a chave de licença por conta própria e a escreve em /etc/catena/license.txt (dono root, modo 0600). Deixar a pergunta vazia instala o pacote do mesmo jeito, mas o serviço não vai iniciar — ponha a chave nesse mesmo arquivo (ou passe na variável LICENSE_KEY) e rode systemctl start catena. Para implantações a resposta é pré-carregada com debconf-set-selections — veja Implantação sem interação.
O pacote de produto é dono de toda a superfície da instalação: a unidade catena.service, o diretório de configuração /etc/catena e o diretório de estado /var/lib/catena. O sapsan.service base fica retirado dessa máquina — deve rodar exatamente um processo.
Um PostgreSQL externo¶
O PostgreSQL é o único portador de estado do central, e em produção o lugar dele é um cluster gerenciado com backups, não a mesma máquina. Basta mudar o DATABASE_URL em /etc/catena/secrets.env para o banco externo e reiniciar o serviço: o central aplica o esquema sozinho na partida, não há passos de migração à parte.
As portas¶
O pacote não instala configuração com porta. De fábrica sobe a porta 80 (definida na variável INITIAL_HTTP_PORT) — e é exatamente um valor inicial: age só enquanto nenhuma outra fonte define listeners HTTP. Dali em diante as portas pertencem à config do streamer — editadas do console como em qualquer máquina do cluster. A variável HTTP=<porta> é o contrário — uma sobreposição permanente por cima de tudo.
| Porta | Quem define | Para quê |
|---|---|---|
| HTTP (inicialmente 80) | INITIAL_HTTP_PORT, depois a config do streamer |
O console, a API, a frente de espectadores /streaming, o sync dos streamers |
| RTSP, RTMP (TCP), WebRTC (UDP) | Listeners nas configurações do streamer | Captura e entrega por esses protocolos |
| SRT (UDP) | Um listener por canal: a porta da reprodução SRT | Servir um canal por SRT |
| Entradas UDP | A porta de cada fonte multicast | Recepção MPEG-TS |
Entre máquinas do cluster: todo o tráfego de controle é iniciado pelo streamer — ele precisa de acesso HTTP(S) ao central; na volta, o central só chama o api_url do streamer (proxy de mídia e estatísticas). Espectadores precisam de HTTP(S) até o central e, com redirects, até os endereços públicos dos streamers.
Verificação¶
systemctl status catena
journalctl -u catena -n 50
Depois — entrar no console e o primeiro canal. As causas típicas de não-partida — a licença e um PostgreSQL inacessível — estão no troubleshooting do Início rápido.