É possível alterar a porta publicada de um contentor sem reconstruir a respetiva base de dados?
Sim, pode alterar a porta publicada de um contentor sem reconstruir a respetiva base de dados, desde que a base de dados permaneça no mesmo armazenamento persistente verificado.
Num NAS doméstico ou anfitrião Docker, a porta visível pertence normalmente ao contentor de aplicação descartável, enquanto os registos, as contas e as definições ficam num volume nomeado, numa montagem de ligação ou num serviço de base de dados separado. Por isso, a alteração segura consiste em preservar a definição da implementação e os caminhos persistentes, alterar apenas a regra de publicação no lado do anfitrião, recriar o serviço de aplicação afetado e, em seguida, verificar todos os proxies, marcadores, callbacks, regras de firewall e verificações de estado que ainda referenciem a porta antiga.
Separe a Porta Publicada no Anfitrião do Listener do Contentor
Registe o mapeamento atual como dois pontos finais distintos antes de o alterar. Em 8080:80, os clientes ligam-se à porta 8080 no anfitrião Docker, enquanto a aplicação continua a escutar na porta 80 dentro do contentor. Alterar o lado esquerdo não altera automaticamente o processo da aplicação nem a ligação à respetiva base de dados.
Um caso de resolução de problemas da comunidade Docker salienta que o mapeamento do anfitrião e o listener interno são separados e que uma nova porta publicada não funcionará quando não houver nada a escutar internamente na porta de destino.
Inspecione as portas publicadas e os sockets de escuta do contentor em execução e, em seguida, teste o ponto final interno a partir de dentro do contentor ou da respetiva rede. Mantenha a porta interna inalterada, exceto se a própria aplicação tiver de mudar. Este primeiro teste evita que uma simples alteração da porta do anfitrião se transforme numa reconfiguração desnecessária da aplicação.
Proteja o Caminho Atual da Base de Dados Antes de Recriar o Serviço
Registe o ficheiro Compose, a etiqueta ou o resumo da imagem, os ficheiros de ambiente, os volumes nomeados, as montagens de ligação, os nomes das redes, os segredos e o nome do anfitrião da base de dados. O objetivo é confirmar que objeto é responsável pelo estado persistente antes de o Docker substituir o contentor da aplicação.
A alteração da publicação da porta exige uma nova configuração do contentor, mas não exige uma nova compilação da imagem nem uma nova base de dados. Uma resposta prática sobre Docker distingue a recriação do contentor da reconstrução da imagem da aplicação quando as definições de portas são alteradas.
Faça uma cópia de segurança ou um instantâneo atual e consistente da base de dados da aplicação quando o serviço for importante e, em seguida, confirme que o caminho da base de dados não se encontra dentro da camada gravável do contentor. Pare se a lista de montagens for ambígua, se o nome do volume tiver mudado ou se a aplicação atual parecer estar a utilizar uma base de dados vazia inesperada.
Altere Apenas o Mapeamento no Lado do Anfitrião e Recrie o Serviço da Aplicação
Edite o serviço da aplicação, alterando um mapeamento como 8080:80 para 8081:80. Mantenha a imagem, a porta interna, os volumes, o URL da base de dados, o nome do serviço, as redes e o mapeamento do utilizador inalterados, salvo se existir outro requisito verificado.
A sintaxe das portas no Compose é interpretada do anfitrião para o contentor, pelo que alterar o lado do anfitrião deixa o processo a escutar na porta interna existente. Um exemplo no fórum Docker explica por que motivo o lado esquerdo é a porta do anfitrião e o lado direito tem de continuar a corresponder ao listener da aplicação.
Recrie apenas o serviço da aplicação com a definição atualizada. Não utilize um comando de stack que remova volumes, não inicialize novamente a base de dados e não adicione --build, exceto se a própria imagem tiver mudado. Após a recriação, inspecione as montagens efetivas e o mapeamento de portas antes de permitir a execução de migrações ou tarefas em segundo plano.
Atualize Todos os Caminhos de Cliente que Dependem da Porta Antiga
Um marcador do navegador é apenas um dos consumidores da porta publicada. Proxies inversos, reencaminhamentos do router, firewalls locais, sondas de monitorização, aplicações móveis, destinos de webhooks, callbacks OAuth, listas de permissões CORS e URLs públicas gerados podem ainda apontar para o ponto final anterior.
Algumas aplicações auto-hospedadas efetuam pedidos para o loopback ou constroem URLs de callback a partir do endereço público configurado. Uma discussão sobre um contentor WordPress mostra como um mapeamento externo alterado pode expor um comportamento de loopback dependente da porta, mesmo quando a base de dados continua saudável.
Pesquise o projeto Compose, a configuração do proxy, os ficheiros de ambiente e as definições da aplicação em busca da porta antiga. Atualize apenas as camadas que utilizam efetivamente o ponto final do anfitrião. Normalmente, os contentores internos devem continuar a utilizar o nome do serviço e a porta interna, em vez da nova porta publicada do anfitrião.
Mantenha a Base de Dados no Seu Caminho Privado do Contentor
Não altere nem publique a porta da base de dados apenas porque a porta do anfitrião da aplicação foi alterada. Uma base de dados utilizada apenas por contentores na mesma stack pode continuar acessível através do nome do serviço e da porta interna, sem qualquer publicação no anfitrião.
Confundir o ponto final público da aplicação com a ligação à base de dados pode criar uma segunda interrupção: a aplicação pode ser configurada para utilizar o endereço do NAS e uma porta do anfitrião, apesar de a base de dados dever permanecer numa rede Docker privada. Essa alteração acrescenta variáveis de firewall, NAT e autenticação sem ajudar o navegador a alcançar o serviço Web.
A partir do contentor da aplicação recriado, resolva o nome do serviço da base de dados, abra a respetiva porta TCP interna, autentique-se e execute uma leitura inofensiva. Se esse caminho não tiver mudado, deixe-o inalterado. Se o teste da base de dados falhar, restaure a definição original da aplicação antes de investigar o problema separado de rede ou credenciais.
Verifique a Nova Porta sem Tocar nos Dados Persistentes
Teste diretamente a nova porta do anfitrião e, em seguida, teste o nome de anfitrião normal ou a rota do proxy inverso. Confirme o início de sessão, a leitura de registos, uma escrita reversível, os carregamentos, as tarefas agendadas, as integrações e um reinício controlado do contentor.
O guia da ZimaSpace sobre alinhar as verificações de estado com os caminhos reais da aplicação é o passo seguinte quando o novo ponto final do navegador funciona, mas o Docker continua a indicar que o serviço não está saudável.
A alteração só estará concluída quando a nova porta publicada sobreviver à recriação e ao reinício, o proxy e os clientes já não utilizarem o ponto final antigo, a aplicação voltar a ligar-se à mesma base de dados persistente e a cópia de segurança da base de dados continuar disponível. Reverta o mapeamento de portas se a aplicação arrancar com um novo estado vazio ou tentar executar uma migração inesperada.
Produtos recomendados
Suporte e Dicas
Mais para Ler
O Plex pode partilhar uma GPU com outro contentor Docker?
O Plex e outro contentor conseguem frequentemente aceder à mesma GPU, mas é necessário testar o suporte dos controladores, o mapeamento de dispositivos, a...
Como saber se um erro do Plex vem do cliente ou do servidor
Reproduza o mesmo item noutro cliente, compare o percurso da sessão e, em seguida, recolha provas do servidor apenas depois de o âmbito lhe...
Como configurar a cache do Plex e o armazenamento temporário de transcodificação
Proteja o estado persistente do Plex enquanto coloca os ficheiros temporários de transcodificação num armazenamento local adequado e, em seguida, verifique a limpeza, o...
