VPS per una Node.js API: elenco di distribuzione e dimensionamento

Iniziare con l'applicazione runtime e le sue dipendenze

A VPS per un Node.js API ha bisogno di un ambiente compatibile e di un proprietario di amministrazione. Registrare i requisiti di runtime, pacchetto lockfile, dipendenze native, database e lavoratori. Scegliere un supporto di rilascio Active LTS o Manutenzione LTS compatibile con il progetto, quindi verificare l'eseguibile utilizzato dal processo distribuito.

Decidi se API viene eseguito direttamente su Linux o in un contenitore. Una scelta di distribuzione non installa l'applicazione o il database Node.js. La preparazione Docker è una scelta iniziale dell'ambiente; il codice di applicazione, la compatibilità di runtime e il lavoro API devono ancora essere implementati e verificati dopo la consegna.

Confronta ambienti Linux VPS per il tuo API

Definire la supervisione del processo, l'avvio e l'arresto

Avviare API in un terminale interattivo SSH non è un ciclo di vita di produzione completo. Scegli un supervisore: ad esempio, sistemato per una distribuzione diretta o il tempo di esecuzione del contenitore per i container. Registra l'eseguibile, la directory di lavoro, l'account di servizio e la sorgente di configurazione. Verifica l'avvio senza il tuo ambiente di shell interattivo.

Testare un guasto di processo controllato e un riavvio pianificato. Riavviare le regole e la diagnostica in modo che un errore persistente non diventi un ciclo di riavvio inspiegabile. Un processo in esecuzione di nuovo non è la prova che il database è collegato o API è pronto. Provare la fine aggraziata: smettere di accettare il nuovo lavoro, gestire le richieste in-flight in modo appropriato e chiudere le connessioni dell'applicazione prima del timeout di supervisore.

Scorrere il tavolo orizzontalmente se necessario.

Review Docker VPS preparazione per una distribuzione dei container

Scegliere RAM e CPU dal comportamento di richiesta

Misurare la memoria, richiedere la latenza e gli errori in un mix rappresentativo di endpoint API. Includere le dimensioni del carico utile, le chiamate del database concorrenti e qualsiasi lavoro di sfondo che condivide il server. Node.js process.memoryUsage segnala le informazioni RSS e V8 heap; heapUsed da solo non descrive il processo completo, le sue allocazioni native o gli altri servizi in esecuzione su VPS.

Un limite V8 vecchio spazio controlla solo parte dell'uso della memoria e non deve consumare l'intera allocazione host. Più vCPUs anche non fare un callback bloccato in un loop evento eseguito in parallelo. Indagare costosi lavori sincroni, query e concurrency prima di interpretare un punto finale lento come necessità di un server più grande. Se si esegue deliberatamente più processi, misurare la loro memoria combinata e conteggi di connessione.

Applicazione di dimensione, database e memoria dei lavoratori in uno stack Docker

Controllare il pubblico proxy e il limite di applicazione privata

Definire quale componente riceve richieste pubbliche e quale endpoint raggiunge la API internamente. Quando si utilizza un proxy inverso, configurare l'indirizzo di ascolto dell'applicazione, la destinazione proxy e le regole di fiducia deliberatamente. Non assumere clienti inoltrati o intestazioni di schema sono affidabili da ogni fonte. Rivedere i limiti della richiesta-corpo e i timeout su entrambi i lati per i endpoint che effettivamente fornire.

Prova una richiesta autenticata, un errore di validazione previsto, un caricamento più grande se supportato e un'operazione di lunga durata se l'applicazione richiede uno. Controllare il nome host HTTPS e il comportamento del cliente, comprese le regole di origine del browser in base a quanto indicato. Tenere i endpoint di database e gestione al di fuori della rotta pubblica prevista. La lista di controllo Nginx copre l'host e la configurazione dei certificati; questi controlli verificano come si comporta API dietro di esso.

Se Nginx restituisce 502, confrontare il registro di errore a monte con il registro dell'applicazione. Controllare che API sia in esecuzione e in ascolto all'indirizzo e alla porta configurati, quindi testare l'endpoint dal contesto di rete del proxy. In contenitori separati, localhost si riferisce al proprio ambiente di ogni contenitore; l'upstream previsto potrebbe avere bisogno del suo nome di servizio. Indagare quella connessione fallita prima di cambiare il firewall pubblico o scegliere un VPS più grande.

Convalida il routing host Nginx, HTTPS e la distribuzione proxy

Mantenere la configurazione e le credenziali per il processo

Elenca le variabili di ambiente e altre configurazioni che API richiede, con un proprietario documentato per ogni segreto. Node.js può leggere le variabili di avvio tramite process.env, ma la scelta delle variabili di ambiente non fornisce di per sé la crittografia, la rotazione o il controllo di accesso. Tenere il materiale segreto fuori dalla directory del sito pubblico, dal repository sorgente e dalle risposte alle applicazioni.

Eseguire l'applicazione con le autorizzazioni di cui ha bisogno piuttosto che utilizzare i privilegi di amministratore per impostazione predefinita. Verificare che l'account di servizio possa leggere la sua configurazione prevista e scrivere solo i dati richiesti. Ridurre i gettoni e i carichi sensibili dai registri. Tenere l'ispettore debug fuori dal percorso di produzione pubblica e rivedere gli aggiornamenti di dipendenza attraverso il processo di rilascio testato dell'applicazione.

Includere il database, la coda e gli upload in recupero

Determinare se il database e la coda sono locali o esterni e configurare i limiti di connessione intorno al processo scelto e al conteggio dei lavoratori. Rehearse database indisponibilità e una riprova dei lavoratori senza creare azioni di business duplicate. Un endpoint sanitario API che conferma solo un processo in esecuzione potrebbe non dirvi che la dipendenza critica necessaria dagli utenti è disponibile.

Un set di recupero ha bisogno del rilascio dispiegabile, della configurazione richiesta, dei dati del database e di qualsiasi upload o stato di lavoro durevole. Proteggere le credenziali assicurandosi che un operatore autorizzato possa ricostruire il servizio. Test di restauro lontano dalla produzione e identificare il lavoro perso dopo il backup selezionato. Ricreare un processo Node.js o tirare la sua immagine non ripristina i record di applicazione.

Costruire e testare un completo set di recupero applicazioni

Accettare il rilascio utilizzando i veri controlli API

Prima di indirizzare i client a una distribuzione, controllare il dominio, l'autenticazione, le autorizzazioni, gli errori e i flussi di lavoro reali di lettura / scrittura. Verificare l'avvio dopo il riavvio, i registri utilizzabili e un riavvio controllato. Registra il risultato con l'identificatore di rilascio e l'ambiente testato.

Tenere il rollback separato dall'inversione del database. Il ritorno al rilascio dell'applicazione precedente può essere pericoloso dopo un cambiamento dello schema incompatibile o record appena scritti. Pianificare tale decisione con lo sviluppatore di applicazione, quindi rivedere le attuali risorse VPS e quotazione contro il carico di lavoro misurato. Il pagamento e la consegna dei servizi di hosting rimangono separati dall'accettazione del proprio API.

• Il runtime supportato e l'avvio supervisionato corrispondono ai requisiti dell'applicazione.
• Le richieste dei rappresentanti e i lavoratori si adattano all'allocazione delle risorse misurate.
• Sono stati testati routing pubblico, autenticazione e dipendenze private.
• Segreti, recupero dati e la decisione di rollback del database hanno un proprietario.
• Nessuna richiesta di disponibilità di applicazione dipende solo da un processo in esecuzione.