Perché un alias di rete Compose smette di essere risolto dopo la ricreazione dello stack con un nuovo nome di progetto?
Un alias di Compose può smettere di essere risolto dopo una ricreazione, quando il servizio entra in una rete con ambito di progetto diverso o l’alias non è più associato a quella rete.
Gli alias Docker hanno un ambito di rete e non sono nomi globali. Ricreare uno stack in una nuova directory, con un nome di progetto esplicito, un nome di stack Portainer o un nuovo progetto Compose può creare una nuova rete predefinita mentre un’altra app rimane su quella precedente. Il servizio può essere integro e raggiungibile tramite la porta pubblicata, ma il suo alias interno non funziona perché il chiamante e la destinazione non condividono più la stessa rete oppure perché un proxy inverso ha selezionato un’associazione diversa.
Confronta i nomi del progetto Compose precedente e attuale
Annota il nome del progetto precedente e di quello attuale, la directory di lavoro, il nome dello stack, i nomi delle reti e le etichette dei container. Confronta il servizio chiamante e quello di destinazione dopo la ricreazione.
Docker Compose usa il nome del progetto per raggruppare e denominare le risorse. La precedenza del nome del progetto spiega perché cambiare la directory o il nome della distribuzione può creare una nuova rete invece di riutilizzare quella del progetto precedente.
Se il chiamante rimane associato a oldproject_default mentre la destinazione entra in newproject_default, l’alias precedente non dispone di un ambito DNS condiviso.
Verifica l’alias sulla rete condivisa esatta
Ispeziona entrambi i container ed elenca ogni rete associata, endpoint, indirizzo IPv4 o IPv6 e alias. Verifica il DNS dall’interno del container chiamante.
La specifica Compose definisce gli alias come nomi con ambito di rete, quindi un alias dichiarato sotto una rete non esiste automaticamente su un’altra associazione.
Sposta la dichiarazione dell’alias sulla rete effettivamente condivisa dai servizi. Non usare container_name come sostituto di un rilevamento dei servizi definito intenzionalmente.
Controlla i nomi delle reti esterne e la sostituzione dei valori durante la distribuzione
Confronta la chiave logica della rete Compose con il relativo name esterno esplicito. Controlla la sostituzione delle variabili d’ambiente e le variabili dello stack usate durante la distribuzione.
Portainer documenta che gli stack possono usare reti Docker esistenti, che devono essere selezionate in modo coerente quando stack distribuiti indipendentemente devono risolversi a vicenda.
Una rete esterna impedisce le modifiche al prefisso del progetto solo quando ogni stack fa riferimento allo stesso nome di rete effettivo. Un errore di battitura può creare o selezionare una rete diversa senza modificare la porta pubblicata del servizio.
Conferma che il chiamante utilizzi il DNS Docker anziché un indirizzo memorizzato nella cache
Esegui una nuova ricerca dal chiamante, controlla la configurazione del resolver e, quando necessario, riavvia soltanto il processo che memorizza nella cache il DNS. Confronta la risoluzione del nome con una ricerca diretta tramite il nome del servizio.
Il modello dei namespace di rete Linux isola le risorse di rete, motivo per cui il corretto funzionamento del DNS sull’host non dimostra che il container chiamante condivida la rete Docker della destinazione.
Non aggiungere l’indirizzo IP attuale del container di destinazione a /etc/hosts. I container ricreati possono ricevere un indirizzo diverso, lasciando un’altra dipendenza obsoleta.
Controlla quale rete utilizza il proxy inverso
Ispeziona le associazioni di rete del proxy e dell’applicazione, le etichette del provider e la rete selezionata per il routing verso il backend. Verifica l’alias dal container del proxy.
Il provider Docker di Traefik consente di specificare la rete Docker utilizzata per le connessioni al backend.
Se il proxy è associato a più reti, la selezione automatica può cambiare dopo la ricreazione. Imposta esplicitamente la rete condivisa prevista e mantieni stabile il suo nome effettivo.
Rimuovi gli endpoint obsoleti senza eliminare la rete sbagliata
Elenca i container connessi alle reti precedente e nuova. Identifica gli endpoint orfani, i container arrestati e i servizi attivi che dipendono ancora dalla rete del progetto precedente.
La guida di Red Hat sul networking dei container descrive l’associazione dei container a reti definite dall’utente come parte dello stato del runtime dei container, non del contenuto dei file dell’applicazione.
Rimuovi una rete precedente solo dopo aver dimostrato che nessuno stack attivo la utilizza. Eliminare entrambe le reti e ricreare tutto contemporaneamente distrugge gli indizi che mostrano quale associazione fosse errata.
Ricrea un solo servizio e verifica il DNS da ogni chiamante
Uniforma il nome del progetto o della rete esterna, ricrea soltanto il servizio interessato e verifica il nome del servizio e l’alias da ogni container dipendente.
L’articolo di ZimaSpace sulle dipendenze del runtime dei container fornisce la regola correlata: un test di connettività eseguito sull’host non convalida il namespace e il percorso di rilevamento dei servizi del container.
Il problema è risolto quando l’alias viene risolto nell’endpoint attuale da ogni chiamante previsto dopo la ricreazione dello stack e il riavvio, senza indirizzi IP codificati.
Domande frequenti
Gli alias delle reti Docker sono globali?
No. Un alias esiste solo sulla rete in cui è configurato ed è utile esclusivamente ai container che condividono quella rete.
La modifica del nome della cartella Compose può interrompere il DNS?
Sì. La cartella può influire sul nome predefinito del progetto, che a sua volta influisce sui nomi delle reti generate, a meno che il nome del progetto o della rete esterna non sia fissato.
Devo usare container_name per mantenere stabile il DNS?
In genere no. Nomi dei servizi stabili e reti condivise esplicite preservano la scalabilità di Compose ed evitano conflitti tra nomi globali.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Guida all’archiviazione delle registrazioni TV in diretta per capacità, conservazione e pulizia
Misura le registrazioni reali, riserva margine, combina i limiti di età e capacità e dimostra che il programma idoneo più vecchio viene rimosso prima...
Procedura di recupero dei metadati multimediali domestici dopo il ripristino di un database
Proteggi lo stato ripristinato, verifica l'identità e i percorsi dei media, quindi correggi le copertine o le corrispondenze mancanti in una libreria pilota prima...
Checklist di compatibilità del client Jellyfin per audio, video e sottotitoli
Testa file rappresentativi una variabile alla volta e registra Direct Play, remux, conversione audio, transcodifica video o errore per ogni client.
