O Immich deve usar uma rede do anfitrião ou uma rede de ponte?

Para a maioria das implementações do Immich baseadas em Docker, uma bridge definida pelo utilizador é a opção predefinida mais simples; a rede do anfitrião é uma solução direcionada, não uma melhoria de desempenho universal.

O Immich precisa sobretudo de ligações fiáveis entre cliente e servidor, servidor e base de dados, servidor e Redis, servidor e aprendizagem automática, e proxy inverso. Ambos os modos de rede podem fornecê-las. A escolha deve ser feita reproduzindo a falha real ou o requisito de acesso, testando um modo de cada vez e mantendo a configuração mais fácil de observar e recuperar.

Comece pelas ligações de que o Immich realmente precisa

Represente a pilha como ligações, não como contentores: os clientes chegam ao endpoint público ou local do Immich; o proxy chega ao servidor Immich; a aplicação chega ao PostgreSQL e ao Redis; e o servidor chega à aprendizagem automática. Registe quais ligações permanecem dentro do Docker e quais atravessam o limite do anfitrião.

Uma bridge definida pelo utilizador atribui aos contentores o seu próprio espaço de nomes de rede, permitindo simultaneamente que os serviços na mesma rede se resolvam pelo nome do serviço. O resumo sobre modos de rede do Docker é útil para esta distinção: as portas publicadas servem clientes do anfitrião ou externos, enquanto o DNS dos contentores trata do tráfego entre serviços.

Se todas as ligações necessárias já funcionarem numa bridge, a rede do anfitrião não resolveu nenhum problema demonstrado. Mantenha a bridge e documente os nomes dos serviços, as redes e as portas publicadas, para que uma alteração posterior no proxy ou no Compose possa ser comparada com uma topologia conhecida.

Prefira uma bridge definida pelo utilizador quando o isolamento e os nomes de serviço estáveis forem importantes

O modo bridge permite que os serviços do Immich comuniquem numa rede de aplicação explícita, sem expor todas as portas dos contentores no anfitrião. Isto é especialmente útil quando um proxy inverso partilha a rede e pode direcionar-se diretamente para o nome do serviço Immich, reduzindo a dependência de um endereço IP do contentor que pode mudar após a sua recriação.

A análise do laboratório doméstico sobre as vantagens e desvantagens da rede do anfitrião observa que remover o NAT do Docker raramente constitui um ganho de desempenho significativo para o tráfego web normal de um laboratório doméstico. As diferenças mais importantes são o isolamento do espaço de nomes, a publicação de portas e a forma como os serviços se descobrem uns aos outros.

O modo bridge só falha como decisão de arquitetura quando uma ligação necessária não pode ser expressa ou continua pouco fiável depois de corrigidos a rede, o DNS, a firewall e a participação do proxy. Não altere de modo simplesmente porque um cliente comunica “servidor inacessível”; primeiro prove que o pedido está a ser interrompido no limite do Docker.

Utilize a rede do anfitrião apenas para um requisito específico e reproduzível

O modo anfitrião coloca o contentor no espaço de nomes de rede do anfitrião, eliminando a tradução de portas do Docker e dando ao serviço o contexto de rede do anfitrião. Isto pode simplificar determinados casos de descoberta ou encaminhamento invulgares, mas também remove o limite de portas ao nível do contentor e aumenta a probabilidade de conflitos de portas no anfitrião.

Uma comparação atual entre as redes bridge e anfitrião enquadra a escolha em torno do desempenho, isolamento, exposição de serviços e depuração. Aplique essas dimensões à ligação do Immich, em vez de presumir que o modo anfitrião é inerentemente mais fiável.

Se o modo anfitrião corrigir um sintoma, reproduza o teste duas vezes e explique porquê. Por exemplo, confirme que o mesmo nome de anfitrião, conta, proxy e cliente falham na bridge e funcionam no anfitrião, enquanto os registos da aplicação permanecem de resto normais. Se o resultado não puder ser repetido, a alteração do modo pode apenas ter ocultado um problema de DNS ou de estado de rede obsoleto.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Mantenha o proxy inverso numa rota explícita e recuperável

Um proxy inverso deve conseguir chegar ao Immich através de uma definição de upstream estável após o reinício de qualquer contentor. Numa bridge, prefira uma rede definida pelo utilizador partilhada e um upstream baseado no nome do serviço, em vez de um endereço IP do contentor copiado manualmente. No modo anfitrião, aponte o proxy para o endereço e a porta pretendidos do anfitrião, verificando a existência de conflitos.

O padrão de teste entre anfitrião e bridge da ZimaSpace utiliza uma regra condicional análoga: a simplicidade da descoberta pode justificar o modo anfitrião, enquanto o isolamento e a integração explícita com o proxy favorecem uma bridge. O Immich utiliza protocolos diferentes, por isso reutilize o método de decisão, não as suposições específicas de portas do Plex.

Reinicie primeiro apenas o proxy, depois apenas o Immich e, por fim, toda a pilha. Uma arquitetura funcional restaura sempre as mesmas rotas locais e remotas, sem editar endereços IP. Uma topologia que exige reconfiguração manual após a recriação não é suficientemente estável, independentemente de utilizar a rede do anfitrião ou uma bridge.

Escolha o modo que passe o mesmo teste de aceitação com menor risco

Teste o início de sessão web local, a ligação da aplicação móvel, um pequeno carregamento, um carregamento grande, o acesso através do proxy inverso, o estado dos serviços entre si e um reinício completo. Registe a latência e as falhas, mas não dê peso excessivo a pequenas diferenças de débito se ambos os modos continuarem muito abaixo do limite da rede.

Escolha a bridge quando todas as funções passarem e beneficiar de exposição explícita, DNS dos contentores e isolamento. Escolha o modo anfitrião quando uma ligação necessária falhar de forma reproduzível numa bridge corretamente configurada e o modo anfitrião a corrigir sem criar conflitos de portas nem alargar a exposição para além do que aceita.

Se ambos os modos falharem da mesma forma, pare de alternar entre redes. A causa estará provavelmente no DNS, TLS, cabeçalhos do proxy, autenticação, firewall, armazenamento ou na própria aplicação. Preserve o pedido e os registos que falharam, regresse à topologia conhecida mais simples e funcional e diagnostique o limite seguinte.