La storia
immaginare un sistema per gestire le chiamate di telefonia mobile o di accesso ai dati mobili (che è quello che Erlang è stato creato per). Esistono server gateway che gestiscono la sessione utente per la durata della chiamata o la sessione di accesso ai dati (la chiamerò la sessione in futuro). Questi server hanno una rappresentazione in memoria della sessione per tutto il tempo in cui la sessione è attiva (l'utente è connesso).
Ora c'è un altro sistema che calcola quanto addebitare all'utente la chiamata oi dati trasferiti (chiamalo PDF - Policy Decision Function). Entrambi i sistemi sono collegati in modo tale che il server gateway crei una manciata di connessioni TCP in PDF e interrompa le sessioni degli utenti se quelle connessioni TCP non funzionano. Il gateway può gestire alcune centinaia di migliaia di clienti alla volta. Ogni volta che c'è un evento a cui l'utente deve essere addebitato (il prossimo trasferimento di dati, un altro minuto della chiamata), il gateway notifica al PDF il fatto e il PDF sottrae una quantità specifica di denaro dall'account utente. Quando l'account utente è vuoto, PDF notifica al gateway di disconnettere la chiamata (hai esaurito i soldi, è necessario ricaricare).
La tua domanda
Infine parliamo della tua domanda in questo contesto. Vogliamo aggiornare un nodo PDF e il nodo è in esecuzione su Docker. Creiamo una nuova istanza Docker con la nuova versione del software, ma non possiamo chiudere la vecchia versione (ci sono centinaia di migliaia di clienti nel bel mezzo della loro chiamata, non possiamo disconnetterli). Ma abbiamo bisogno di spostare i clienti in qualche modo dal vecchio PDF alla nuova versione. Quindi diciamo al nodo gateway di creare nuove connessioni con il nodo aggiornato anziché il vecchio PDF. I clienti possono essere chiacchieroni e anche alcuni di loro potrebbero avere connessioni dati di lunga durata (scaricando Windows 10 iso), quindi l'intera operazione richiede 2-3 giorni per essere completata. Questo è il tempo necessario per aggiornare una versione del software a un'altra in caso di un bug critico. E ci possono essere dozzine di server come questo, ognuno con centinaia di migliaia di clienti.
E se invece usassimo il gestore di rilascio di Erlang? Creiamo il file relup con la nuova versione del software. Lo testiamo correttamente e lo distribuiamo ai nodi PDF. Ogni nodo viene aggiornato sul posto: lo stato interno dell'applicazione viene convertito, il nodo esegue la nuova versione del software. Ma, soprattutto, la connessione TCP con il server gateway non è stata eliminata. Quindi i clienti continuano felicemente le loro chiamate o stanno scaricando gli iso Windows più recenti mentre stiamo aggiornando il sistema. Tutto è fatto in 10 secondi anziché in 2-3 giorni.
La risposta
Questo è un esempio di un sistema specifico con requisiti specifici. La finestra mobile e Erlang's Release Handling sono tecnologie ortogonali.È possibile utilizzare uno o entrambi, tutto si riduce alle seguenti:
avrete abbastanza risorse per testare i due approcci prevedibile e abbastanza pazienza per insegnare la tua squadra Ops in modo che possano distribuire il sistema utilizzando uno dei due metodi? Cosa succede se l'impianto di test costa milioni di sterline (a causa dell'hardware richiesto) e può utilizzare solo uno di questi due metodi alla volta (perché il ciclo di test richiede giorni)?
L'approccio pragmatico potrebbe essere quello di distribuire i nodi inizialmente utilizzando Docker e quindi aggiornarli con Erlang release handler (se è necessario utilizzare Docker in primo luogo). Oppure, se il tuo sistema non ha bisogno di essere disponibile durante l'aggiornamento (come fa il sistema PDF di esempio), potresti semplicemente optare per la distribuzione di nuove versioni sempre con Docker e dimenticare la gestione delle versioni. Oppure puoi anche affidarti al gestore del rilascio e dimenticare Docker se hai bisogno di aggiornamenti rapidi e affidabili al volo e Docker verrà utilizzato solo per la distribuzione iniziale. Spero che aiuti.
Nonostante il mio commento, credo che questo non sia stato ancora veramente risposto. Credo che si possa scrivere di più sulle diverse strategie di implementazione dell'utilizzo di HCS all'interno di Docker. La mia ipotesi è che Docker o meno non importerebbe finché si mantiene PROD in linea con HEAD, non importa se un nuovo contenitore viene spinto attraverso Docker o Erlang. Ma fai in modo che le cose si sincronizzino! – Aki
Docker non è particolarmente adatto per Erlang - è solo l'unico modo per distribuire tutto ciò che molti negozi più giovani conoscono oggi. Il tipo di problemi che molte persone provano a risolvere con Docker (parallelismo leggero, igiene dell'ambiente di esecuzione, "la rete è l'astrazione", isolamento del processo, sicurezza della memoria, ecc.) Sono i problemi che Erlang già affronta in modo più completo. Gli aggiornamenti di codice caldo richiedono un elevato livello di controllo e conoscenza dei tipi di dati in movimento e dell'ambiente di caricamento di codice/di memorizzazione per il runtime. La finestra mobile impedisce il secondo requisito nel caso normale. – zxq9
@ zxq9: questo mi dà maggiore sicurezza nell'esecuzione di app Phoenix/Elixir al di fuori di Docker, ma HCS ha effettivamente senso in un ambiente DevOps che utilizza CircleCI o TravisCI? Fondamentalmente, Erlang HCS non è ortogonale agli strumenti Docker AND CI? Ciò richiede una nuova valutazione della funzionalità HCS, sappiamo che PaaS spesso non consente ai nodi di interagire l'uno con l'altro nel modo in cui HCS ha bisogno di lavorare bene. Questo dovrebbe essere un post completamente nuovo: le web app di Erlang dovrebbero sacrificare HCS in favore di Docker e CI? – Aki