Como fazer self-host do IT Tools em 2026: TLS, deploys stateless e atualizações

Fazer self-host do IT Tools torna-se interessante no primeiro redeploy, não no primeiro docker run. Se o proxy apontar para a porta errada do container ou armazenar em cache um application shell antigo, o Docker ainda poderá reportar um processo perfeitamente saudável. O deploy abaixo é organizado em torno de comportamentos observáveis: carregar a interface, gerar um hash, decodificar um JWT e usar um conversor com a rede do navegador desconectada depois que os assets forem armazenados em cache.

A finalidade do IT Tools é explícita: reunir hashes, conversores, geradores e utilitários para desenvolvedores. Essa descrição indica o que precisa permanecer público, o que deve continuar privado e o que um backup precisa reconstruir.

Separe o IT Tools das dependências

Comece pelo namespace de rede do IT Tools: o listener web usa a porta 80, não uma porta do host copiada de um tutorial para laptop. O build padrão do IT Tools não precisa de banco de dados nem de um serviço de runtime persistente separado. Mantenha o container web substituível e coloque qualquer componente futuro de autenticação, colaboração ou armazenamento atrás de uma boundary documentada separadamente.

Depois que o requisito for atendido, execute o cenário completo — carregue a interface, gere um hash, decodifique um JWT e use um conversor com a rede do navegador desconectada depois que os assets forem armazenados em cache. Registre logs e medições de memória do navegador do cliente, entrega de assets estáticos e ausência de trabalho de banco de dados ou fila no servidor. Essas evidências tornam-se a primeira arquitetura conhecida como funcional e permitem testar mudanças posteriores entre o compute da Dockup e um servidor conectado.

Crie um container substituível do IT Tools

Um comando mínimo é útil quando revela o que a plataforma gerenciará posteriormente.

docker run -d \
  --name it-tools \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  corentinth/it-tools:latest

Aqui, a porta 80 continua privada no host e todos os caminhos necessários estão explícitos. Confirme o requisito local antes da exposição: nenhum banco de dados; apenas um pequeno container web. Verifique a inicialização usando tanto os logs quanto a validação específica da aplicação: carregue a interface, gere um hash, decodifique um JWT e use um conversor com a rede do navegador desconectada depois que os assets forem armazenados em cache. Depois de verificar, fixe a versão da imagem para que uma substituição de rotina não altere o comportamento silenciosamente.

TLS é fácil; URLs geradas, não

A boundary pública do IT Tools deve ser um único hostname canônico, TLS automático e um único destino interno na porta 80. Encaminhe a aplicação web estática por HTTPS para que os clientes retornem a um endereço reconhecido pelo serviço.

Se a transação de aceitação falhar, classifique o primeiro erro. Problemas de DNS, certificado e 502 pertencem ao checklist de validação de TLS. A condição “o proxy aponta para a porta errada do container ou armazena em cache um application shell antigo” pertence ao lado da aplicação, depois que uma requisição tiver chegado ao IT Tools com sucesso.

Volumes são apenas a primeira camada de recuperação

A recuperação do IT Tools stateless é um exercício de reprodutibilidade. Não preserve dados no servidor; mantenha a configuração do deploy; a camada gravável do container não deve conter nada necessário após a substituição.

Use a imagem fixada e a configuração revisada para recriar o IT Tools em um compute vazio. O exercício é aprovado quando um container novo reproduz o mesmo conjunto de ferramentas, pois não há estado de usuário no servidor para recuperar. Siga o fluxo de deploy do Git à produção para o artefato substituível, enquanto qualquer serviço externo opcional mantém um procedimento de backup separado.

Documente o digest exato e a entrada usada na aceitação. Isso permite ao operador distinguir uma regressão da aplicação de um estado ausente e evita anexar um volume meramente simbólico que o IT Tools nunca lê.

Feche o acesso temporário de configuração

A segurança do IT Tools stateless começa pelos controles de supply chain e ingress, não por uma configuração fictícia de conta. Evite presumir que ferramentas no navegador tornam secrets colados seguros em um host não confiável. A boundary pretendida é servir uma imagem upstream confiável e lembrar aos usuários que fazer self-host não torna um navegador comprometido confiável.

Sirva o IT Tools a partir de uma imagem confiável e fixada, adicione autenticação da plataforma se o público for privado e exponha apenas a porta 80 por HTTPS. Defina limites de recursos e requisições em torno da memória do navegador do cliente, da entrega de assets estáticos e da ausência de trabalho de banco de dados ou fila no servidor. Como não existe nenhum secret integrado nesta baseline, mantenha a política de acesso na configuração da rota e teste-a a partir de um cliente não autorizado.

Simule a alteração arriscada do IT Tools

Monitore o comportamento, não apenas o processo: carregue a interface, gere um hash, decodifique um JWT e use um conversor com a rede do navegador desconectada depois que os assets forem armazenados em cache. Os sinais de pressão ao redor são a memória do navegador do cliente, a entrega de assets estáticos e a ausência de trabalho de banco de dados ou fila no servidor. Execute essa verificação depois da inicialização e em uma periodicidade que não possa sobrecarregar o serviço.

Uma atualização só pode ser promovida depois de testar que uma atualização da imagem pode alterar algoritmos ou dependências no client-side; por isso, fixe e verifique o build que processa dados sensíveis. Use um candidato em paralelo, digests fixados e entradas conhecidas; esta base image não tem schema migration para simular. Se o proxy apontar para a porta errada do container ou armazenar em cache um application shell antigo, compare as duas versões antes de alterar o ingress ou adicionar storage.

Registre um deploy do IT Tools conhecido como funcional

Não use o tráfego do primeiro usuário como teste de aceitação do IT Tools. Prepare um estado de exemplo inofensivo e execute a ação completa “carregar a interface, gerar um hash, decodificar um JWT e usar um conversor com a rede do navegador desconectada depois que os assets forem armazenados em cache”. Anote a URL pública exata, o resultado, a referência da imagem e o intervalo de logs associados à execução.

Substitua o container e repita sem recriar dados. Em seguida, faça a recuperação em um host vazio; a condição de recuperação é que um container novo reproduza o mesmo conjunto de ferramentas, pois não há estado de usuário no servidor para recuperar. Observe a memória do navegador do cliente, a entrega de assets estáticos e a ausência de trabalho de banco de dados ou fila no servidor em cada execução e defina um alerta para a degradação da transação, não para métricas de container ocioso.

Uma verificação final deve falhar de propósito: envie uma entrada inofensiva próxima do limite de recurso ou formato associado a esta boundary: o proxy aponta para a porta errada do container ou armazena em cache um application shell antigo. Verifique se a mensagem resultante do IT Tools identifica a boundary relevante, em vez de disparar exclusão de dados ou um restart infinito. Restaure a condição válida e confirme que a mesma transação de exemplo é concluída com sucesso. Mantenha este exercício curto no checklist de release.

Um deploy na Dockup ainda precisa de um teste de aceitação do IT Tools

A Dockup pode fazer deploy da imagem fixada do IT Tools no compute da Dockup ou em um servidor conectado pelo cliente, encaminhar o hostname público para a porta 80 e emitir TLS automaticamente. O container padrão não tem banco de dados da aplicação, portanto a Dockup não deve anexar um volume de dados sem propósito apenas para imitar um template stateful.

Depois do deploy, encaminhe a aplicação web estática por HTTPS. A Dockup deve preservar as configurações de runtime do IT Tools enquanto o operador confirma este requisito local: nenhum banco de dados; apenas um pequeno container web. Execute a verificação de saída conhecida: carregue a interface, gere um hash, decodifique um JWT e use um conversor com a rede do navegador desconectada depois que os assets forem armazenados em cache. Se fontes customizadas, autenticação, colaboração ou configuração forem adicionadas posteriormente, declare esses componentes e seus estados explicitamente, em vez de incorporá-los à web image stateless. Isso mantém o deploy com um clique honesto sobre o que a Dockup gerencia e sobre o que o próprio IT Tools realmente armazena.

Perguntas frequentes

O que o IT Tools precisa para um deploy em produção?

Encaminhe o container do IT Tools na porta 80 por meio de uma única origem HTTPS. O build padrão do IT Tools não precisa de banco de dados nem de um serviço de runtime persistente separado. Não considere o IT Tools pronto até conseguir carregar a interface, gerar um hash, decodificar um JWT e usar um conversor com a rede do navegador desconectada depois que os assets forem armazenados em cache.

Quais dados do IT Tools devem fazer parte de um backup?

A imagem padrão do IT Tools não tem um mount obrigatório de dados da aplicação. Preserve a configuração do deploy e faça backup de qualquer estado conectado separadamente; a recuperação é aprovada quando um container novo reproduz o mesmo conjunto de ferramentas, pois não há estado de usuário no servidor para recuperar.

O IT Tools precisa de HTTPS atrás de um reverse proxy?

Use HTTPS para a origem pública do IT Tools e mantenha a porta 80 na rota interna. Aplique corretamente a configuração do IT Tools: encaminhe a aplicação web estática por HTTPS. Para o IT Tools, o HTTPS protege credenciais ou conteúdo do usuário durante o trânsito e mantém consistente o comportamento do cliente sensível à origem.

Como uma atualização do IT Tools deve ser testada?

Faça o deploy da imagem candidata do IT Tools ao lado da atual e repita a transação de aceitação com uma entrada conhecida. Preste atenção especial, pois uma atualização da imagem pode alterar algoritmos ou dependências no client-side; por isso, fixe e verifique o build que processa dados sensíveis. O container padrão não tem migração de dados, portanto mantenha o digest anterior até que as verificações de saída e compatibilidade sejam aprovadas.