Skip to content

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/catena e uma configuração com a seção central: — 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.