La configurazione predefinita per i servizi distribuiti deve essere impostata in base all'utilizzo di produzione?

Question

La configurazione predefinita per i servizi distribuiti deve essere impostata in base all'utilizzo di produzione?

#1 da (1 voti)
#2 da (1 voti)

0

Oggi, io e il mio collega abbiamo avuto opinioni divergenti sull'uso dei valori predefiniti nella configurazione del software. Entrambi abbiamo convenuto che per un software consumer, la configurazione predefinita dovrebbe essere determinata dall'uso più comune e dall'esperienza utente.

Tuttavia, la contesa riguarda l'utilizzo di valori predefiniti per servizi distribuiti di tipo enterprise in cui sono presenti più ambienti di distribuzione (produzione, sviluppo, fase, ecc.). Pensa agli host API, agli endpoint, ai percorsi, alle costanti, ecc. Predefiniti come variabili di configurazione. La mia opinione è che i valori predefiniti dovrebbero essere qualcosa che ha più senso per i clienti di produzione . Tieni presente che questo non include credenziali di autenticazione / sensibili, certificati, ecc., Poiché gli sviluppatori non dovrebbero avere accesso diretto a tali parametri di produzione.

Pro:

Rende più facile il lavoro di TechOps. Si basano sul paradigma convention over configuration . TechOps può concentrarsi rigorosamente sull'infrastruttura e non sulle impostazioni specifiche dell'applicazione.
L'ambiente di uno sviluppatore prova a imitare un ambiente di produzione. Uno sviluppatore sa facilmente quali saranno i valori delle impostazioni specifiche, per la maggior parte (se non tutti) i clienti di produzione. Lui / lei ha bisogno di cercare la fonte e non deve ssh configurazioni del cliente.

Contro:

Molto spesso, l'ambiente dello sviluppatore non è compatibile con la produzione perché non tutti i componenti vengono creati da ogni sviluppatore, né ogni sviluppatore è preoccupato per ogni componente. Diventa responsabilità dello sviluppatore impostare la propria configurazione di conseguenza.
Porta a scrivere un codice difensivo che altrimenti non sarebbe mai necessario per gli scenari di produzione. Ad esempio, nel nostro caso per una configurazione di sviluppo, una connessione HTTP viene ritentata a causa della configurazione predefinita e quindi restituita dopo aver ricevuto un 404. Nella configurazione di produzione, TechOps avrebbe garantito la disponibilità e l'endpoint corretto.

Un giusto compromesso, IMO, consiste nell'impostare diverse configurazioni predefinite per ogni ambiente e utilizzare script per la loro distribuzione. Tuttavia, questo non è il modo in cui il nostro software è progettato al momento.

Nell'età odierna del CICD, (usando la finestra mobile, per esempio) quanto è rilevante il paradigma convenzione sulla configurazione . Quali sono gli approcci preferiti per selezionare tali valori predefiniti?

EDIT: Lettura interessante è Valori predefiniti - sono buoni o cattivi ? che è simile ma mette in dubbio l'esistenza dei valori predefiniti, che non è esattamente la stessa.

EDIT2: per coloro che considerano il downvoting, si prega di considerare di lasciare un commento su cosa dovrebbe essere migliorato o sbagliato nella domanda. Sarà utile per i nuovi arrivati come me su questo SE.

continuous-delivery devops default-values

posta Mukul Gupta 24.07.2018 - 22:07

fonte

2 risposte

Leggi altre domande sui tag continuous-delivery devops default-values

Scala: qual è stata la considerazione del progetto desiderata per l'istanza nulla nell'esempio Avvia e chiude le azioni in cicli while

score 1 · Answer 1

Mi avvicinerei a questo da una posizione basata sul rischio.

Alcune opzioni di sviluppo possono essere dannose o addirittura pericolose se impostate in un ambiente di produzione. Per queste opzioni, l'impostazione predefinita dovrebbe essere quella di impostare le impostazioni di produzione. Queste opzioni sono cose come l'eliminazione laterale delle cache o l'attivazione della modalità di debug.

Al contrario, alcune impostazioni di produzione dovrebbero essere evitate o escluse dagli sviluppatori (specialmente se esiste una divisione tra lo sviluppo e le operazioni). Cose come le credenziali del database di produzione.

It leads to writing defensive code which would otherwise never be needed for production scenarios. For example, in our case for a dev setup, an HTTP connection is retried because of default configuration and then given up after receiving a 404. In production setup, TechOps would have ensured the availability and correct endpoint.

Mentre in un mondo ideale l'endpoint sarebbe al 100%, non c'è alcuna garanzia che sarà nel mondo reale (infatti, è quasi certo che non sarà disponibile ad un certo punto, di volta in volta). Problemi di rete (risoluzione e routing), problemi di alimentazione, problemi hardware, tempi di manutenzione. Potrebbero non accadere spesso, ma accadono. Ad esempio, ho visto roba messa a punto nello sviluppo per avere un timeout molto breve - ma una volta che l'applicazione è fuori produzione, i tempi di risposta sono aumentati enormemente e l'applicazione è caduta.

Quindi - disporre di impostazioni predefinite, sicure, predefinite e documentazione su ciò che deve essere configurato per vari ambienti.

score 1 · Answer 2

Non ci dovrebbero essere configurazioni di default.

L'utilizzo della configurazione di produzione come predefinito è problematico perché

questa configurazione è necessariamente incompleta (ad esempio credenziali)
questa configurazione potrebbe portare accidentalmente agli sviluppatori che accedono alle risorse di produzione
le modifiche alla configurazione di produzione richiederebbero modifiche alla configurazione predefinita

Allo stesso modo, l'utilizzo di una configurazione di sviluppo come predefinita può causare problemi perché

questa configurazione potrebbe essere utilizzata accidentalmente nella produzione

Le configurazioni di default in generale hanno anche il problema che questa configurazione è gestita insieme al tuo codice. All'inizio sembra grandioso, ma in una certa misura config e codice sono ortogonali. Dovrei essere in grado di sperimentare le modifiche di configurazione senza dover eseguire il commit di una nuova versione del codice.

La soluzione non è quella di sbarazzarsi di alcuna configurazione, ma di eliminare una configurazione predefinita: l'esecuzione del sistema implica quindi una scelta consapevole. Idealmente, la configurazione viene fornita attraverso variabili di ambiente o tecniche comparabili. Queste variabili non devono riferirsi a una modalità come "sviluppo" o "produzione", ma contengono i dati di configurazione direttamente (come una stringa di connessione al database) o indicano un file di configurazione.

Lettura consigliata: l'app Twelve-Factor, in particolare le pagine su config , che trattano servizi di supporto come risorse associate e build, release, run . È perfettamente in disaccordo con quel sito Web, ma rappresenta un approccio collaudato.

Si noti che il concetto di "configurazione" a 12 fattori è abbastanza ristretto. La configurazione descrive l'ambiente, non tutte le opzioni modificabili del software. Per esempio. per una tipica app web il server database è config, la directory contenente i template HTML non lo è.

Non ti libererai di alcun tipo di script durante l'implementazione del tuo software. Docker non aiuta o ostacola la configurazione, ma la parte rilevante è che la configurazione dell'ambiente non deve far parte dell'immagine, in modo che tu possa usare la stessa immagine nello sviluppo e nella produzione.