Riesci a ottenere zero tempi di inattività con magento2?


15

Se hai un nuovo modulo e devi eseguirlo setup:upgrade, non vedo un modo in cui non puoi avere tempi di inattività pari a zero. Sarà sempre in calo di 10-20 secondi perché è necessario aggiornare il database. Oppure mi sfugge qualcosa?

Anche se si sta eseguendo la distribuzione in una cartella diversa e quando tutti i file vengono generati si collega simbolicamente l'ambiente live a questa cartella, è comunque necessario occuparsi del database.

Risposte:


2

Mi chiedo in quale ambiente stai lavorando in cui 10-20 secondi, o anche pochi minuti, di tempi di inattività sarebbero un rompicapo. Naturalmente, questo non è l'ideale, ma devo immaginare che è un prezzo piuttosto piccolo da pagare, soprattutto se si distribuisce durante le ore non di punta.

Documentazione per sviluppatori M2: distribuire Magento alla produzione . Al momento della stesura di questo documento, i documenti sono scarsi e si collegano a un problema GitHub esterno per la discussione. Tuttavia, quei documenti ufficiali sono un buon posto da tenere d'occhio.

Il mio team sta studiando utilizzando Capistrano per distribuire M2. Non abbiamo ancora deciso un processo finale, ma una semplice ricerca su Google ("capistrano magento 2") mostra che un certo numero di persone sta sperimentando lo stesso.

Infine ci sono vari schemi come la distribuzione blu-verde che cercano anche di ridurre al minimo i tempi di fermo. Il blu-verde in particolare è come avere un server di gestione temporanea, ma nel momento critico aggiorni il DNS per puntare dal blu al verde, trasformando il verde in live e il blu in "staging". Per la distribuzione successiva, il blu diventa di nuovo attivo. In questo modo i tempi di inattività sono teoricamente pari a zero e le modifiche avvengono con la stessa rapidità con cui si propagano le modifiche al DNS.


grazie per i link utili. Il DNS non si propaga mai abbastanza velocemente secondo me. Attaccherei alle cartelle dei collegamenti simbolici. Le distribuzioni durante le ore non di punta sono rischiose. L'ora non di punta sarebbe essenzialmente molto presto la mattina o molto tardi la sera. Se sei una piccola azienda potresti non avere abbastanza personale per questo.
Claudiu Creanga,

1
Non capisco davvero come blu-verde possa funzionare qui senza richiedere che avvenga ogni tipo di sincronizzazione del database, il che sembra rischioso. Il problema è che l'installazione del modulo richiede l'esecuzione di aggiornamenti db.
Rich S

@RichS Per quanto riguarda il software, la sincronizzazione non è un problema. Ma sì, può essere complicato evitare di perdere ordini o altri dati dei clienti - vedi la fonte che ho collegato. Si consiglia di utilizzare effettivamente lo stesso db. Ancora una volta, tornando alla premessa della domanda, quando 10 minuti di downtime saranno davvero un problema? Vorrei prima cercare una soluzione non tecnica, come la distribuzione alle 2 del mattino, prima di introdurre inutili complessità.
nshiff,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.