Casi ottimali per l'architettura container-oriented

Question

Casi ottimali per l'architettura container-oriented

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

1

È una pratica in crescita per eseguire applicazioni in ambienti containerizzati che forniscono un'astrazione alle risorse del sistema operativo.

Esistono già dei commenti sull'overhead del contenitore in alcuni casi, non tutte le letture sono critiche, ce ne sono alcune in cui non testano nessun overhead. Ti piace questo articolo riguardante i / o .

Nella mia esperienza, nella maggior parte dei casi, le macchine sono installate con una versione di sistema operativo concreta, quindi vengono fornite solo tramite script.
Spesso, anche le macchine vengono configurate utilizzando un'immagine già configurata di un sistema unix, in cui tutte le librerie e le dipendenze sono ben note.

Avendo una solida configurazione os, i moduli o le app possono essere facilmente mantenuti già usando una vasta serie di gestori di pacchetti, che caricano un insieme di dipendenze usando i file di configurazione ( requirements.txt, package.json, build.manifest, build.sbt )

Diciamo che si può automatizzare la completa creazione di un sistema, di architetture complete di terraform o conf , di memorizzare i sistemi già costruiti nelle immagini e di mantenere aggiornate le applicazioni con git hooks senza bisogno di un livello intermedio per occuparsi di tutto ciò .

Mi chiedo, in quali casi vedi ottimale utilizzare una soluzione containerizzata a livello di applicazione?

design architecture system-architecture

posta Evhz 10.05.2018 - 18:53

fonte

2 risposte

Leggi altre domande sui tag design architecture system-architecture

API HATEOAS e sviluppo front-end Come si utilizza effettivamente la codifica per produrre progetti? [chiuso]

score 3 · Answer 1

L'articolo a cui ti riferisci sta parlando del tempo per eseguire uno script all'interno di un contenitore. Capisco questo per indicare che il contenitore finestra mobile si avvia, lo script viene eseguito e quindi il contenitore si spegne. Il tempo extra in cui è più probabile è semplicemente il tempo extra necessario per creare l'istanza del contenitore; Dubito strongmente che uno script abbia iniziato che impiega molto più tempo per essere eseguito.

L'esecuzione di un container su un sistema operativo aggiunge sicuramente un sovraccarico. Ma se si sta eseguendo un singolo contenitore all'interno di ciascuna istanza VM, non vi è alcun motivo reale per utilizzare i contenitori. Mancherebbe completamente il punto. Uno dei motivi principali per utilizzare i contenitori è ridurre i costi generali. Il modo in cui i contenitori lo consentono è invece di avere, diciamo una macchina "reale" con 12 macchine virtuali ciascuno con il proprio sistema operativo e le proprie librerie, ecc., E si può avere una macchina virtuale con 12 istanze di contenitore. Ciò significa che hai ridotto il numero di copie del SO in esecuzione su quella macchina per 11. È anche possibile eseguire la finestra mobile su bare metal eliminando completamente la VM ( note : ci sono implicazioni sulla sicurezza per fare ciò.)

In termini di casi d'uso ottimali, ci sono molti altri vantaggi per la containerizzazione per molti diversi tipi di applicazioni. Sarebbe più facile nominare le situazioni in cui non è utile come se si stesse eseguendo una singola istanza di un'app o forse molte applicazioni di breve durata come gli script come descritto nell'articolo.

score 2 · Answer 2

I contenitori sono un ulteriore livello di astrazione tra il bare metal e il sistema operativo che l'applicazione vede.

Se hai già un livello di astrazione, (per esempio macchine virtuali o un tempo di esecuzione), è difficile giustificare un contenitore a meno che non ci sia un difetto nell'astrazione esistente.

In una soluzione "ottimale" tutte le macchine virtuali sarebbero perfettamente dimensionate per l'applicazione in esecuzione su di esse, o sarebbero sufficientemente stabili da far funzionare su più applicazioni senza conflitti e gli sviluppatori comprenderanno l'infrastruttura sufficiente per poter programmare le app che si adattano a qualsiasi cosa siano stati eseguiti.

In pratica a volte questo non è il caso. Un contenitore, se funziona correttamente, ti dà un altro out.

Tendo a essere d'accordo con il tuo apparente sentimento. I contenitori non sono abbastanza maturi e altri livelli di astrazione sono molto maturi. Dovrebbe sempre essere possibile, in un caso ottimale, fare a meno dei contenitori