Ridimensionamento dei contenitori Docker nel mondo reale

Question

Ho alcune domande di base sul ridimensionamento dei contenitori Docker:

Ho 5 app diverse. Non sono collegati tra loro. Prima di avere contenitori, eseguivo 1 app per VM e li aumentavo e diminuivo singolarmente nel cloud.

Ora con i contenitori ottengo l'isolamento su una VM, quindi ora posso potenzialmente eseguire un host con 5 contenitori docker in cui ogni app è isolata nel proprio contenitore.

Fintantoché dispongo di risorse sufficienti sul mio host, potrò scalare su e giù quei contenitori singolarmente man mano che il mio traffico cresce o si riduce. per esempio. Ho 3 contenitori in esecuzione App 1, ma solo 1 contenitore in esecuzione app 2.

Nelle ore di punta App 3 ottiene un sacco di traffico e ho bisogno di lanciare una seconda serie che gestisce solo contenitori per App 3.

La mia prima domanda è se quanto sopra ha senso in ciò che dico o se ho frainteso qualcosa. La mia seconda domanda è quale tecnologia è attualmente disponibile per fare tutto questo in modo automatico. Ho bisogno di un bilanciatore del carico e di un gruppo di ridimensionamento automatico che sia in grado di eseguire lo scenario sopra descritto senza che io debba intervenire manualmente.

Ho esaminato AWS ECS e non sono abbastanza sicuro se riuscirà a soddisfare i miei bisogni come ho delineato sopra.

Qualcuno sa come ottenere questo risultato oppure esiste un modo migliore di gestire e ridimensionare le mie 5 app che mi mancano?

UPDATE:

via Twitter mi è stato indicato Kubernetes e in particolare la documentazione sul Horizontal Pod Autoscaler.

Potrebbe essere utile anche per gli altri. Aggiornerò questa domanda man mano che imparo di più.

Answer 1

Ci sono diverse opzioni, ma nessuna che conosco lo fa: occorrono 2 cose: scalare gli host in base ai segnali, quindi i contenitori di auto-scala sugli host.

Le seguenti sono le soluzioni da implementare e scala contenitori sugli host (non necessariamente auto -scale però):

kubernetes è uno strumento orchestrazione che permette di programmare e (con l'opzionale autoscaler) per i pod autoscale (gruppi di contenitori) nel cluster. Si assicura che i tuoi contenitori siano in esecuzione da qualche parte se un host fallisce. Google Container Engine (GKE) offre questo come servizio, tuttavia non sono sicuro che abbiano le stesse funzionalità per la scalabilità automatica del numero di VM nel cluster come fa AWS.

Mesos: un po 'simile a Kubernetes ma non dedicato all'esecuzione di contenitori.

Docker Swarm: la soluzione di distribuzione multi-host di Docker consente di controllare molti host come se fossero un singolo host Docker. Non credo che abbia alcun tipo di capacità di "scalabilità automatica" e non credo che si occupi di far sì che i pod siano sempre in esecuzione da qualche parte: in pratica è docker per cluster.

[EDIT] Docker supporta il riavvio contenitori in mancanza con l'opzione restart=always, anche, come di Docker 1.11 Docker Swarm è una modalità in Docker Daemon, e supporta la riprogrammazione contenitori in caso di fallimento del nodo: si riavvia contenitori su un nodo diverso se un nodo non è più disponibile.

Docker 1.11+ sta diventando molto simile a Kubernetes in termini di funzionalità. Ha alcune caratteristiche interessanti (come TLS tra i nodi di default), ma manca ancora cose come IP statici e provisioning dello storage

Nessuna di queste soluzioni scalerà automaticamente il numero di host per te, ma è possibile ridimensionare il numero di contenitori sugli host.

Per gli host di scalabilità automatica, le soluzioni sono specifiche per il provider di servizi cloud, quindi queste sono soluzioni dedicate. La parte fondamentale per te è integrare i due: AWS consente la distribuzione di Kubernetes su CoreOS; Non credo che offrano questo come servizio, quindi è necessario distribuire il proprio cluster CoreOS e Kubernetes.

Ora il mio parere personale (e di assenza)

ho più utilizzato kubernetes su GKE e bare-metal, così come Swarm a circa 6 mesi fa, ed io eseguire un infra con ~ 35 servizi su GKE:

Francamente, GKE con Kubernetes as a Service offre la maggior parte di ciò che desideri, ma non è AWS. Scalare gli host è ancora un po 'complicato e richiederà un po' di lavoro.

Configurare i propri Kubernetes o Mesos su AWS o bare metal è molto fattibile, ma c'è una vera e propria curva di apprendimento: tutto dipende se si sente fortemente di essere su AWS e si è disposti a trascorrere il tempo.

Lo sciame è probabilmente il modo più semplice con cui lavorare, ma più limitato, tuttavia lo script personalizzato può svolgere bene il lavoro principale: utilizzare le API AWS per scalare gli host e Swarm da distribuire. Tuttavia, la garanzia di disponibilità richiederà il monitoraggio e si occuperà di rilanciare i contenitori in caso di guasto di un nodo.

Oltre a questo, ci sono anche container fornitori di hosting che possono fare il lavoro per voi:

• Scalingo è uno so di ma ci sono altri. https://scalingo.com/

• OVH Sail Above ha questo servizio in alpha. https://www.runabove.com/sailabove.xml

Answer 2

Vorrei dare un'occhiata a Tutum (acquisito recentemente da Docker in realtà). Si lega a CI e credo che abbia capacità di scalabilità.

https://www.tutum.co/

Answer 3

UPDATE: supportato dalla AWS ECS con Task Placement Constraints.

1. Il cluster ECS è servito da due gruppi di ridimensionamento automatico (ASG).

2. Nel primo ASG, impostare min, max e desired dimensioni tutte a 1.

   Contrassegna questa istanza con un custom attributeALLOW_ALL_APPS = TRUE. Fai questo nello script dei dati utente.

3. Nel secondo ASG, impostare min e desired dimensioni su 0 e max dimensioni su 1 (presumo che si desidera solo 2 istanze).

   Contrassegna questa istanza con attributo personalizzato ALLOW_ALL_APPS = FALSE. Di nuovo nello script dei dati dell'utente.

4. L'allarme di scala per il secondo ASG sarà determinato dal carico sul primo ASG.

   Se si conoscono i tempi di picco per l'app 3, è possibile eseguirne il prelievo anticipatamente con un'azione di ridimensionamento programmata.

5. Il ridimensionamento per il secondo ASG avviene quando il carico scende a sufficienza, in modo che il primo ASG possa gestirlo da solo.

6. Nel service definitions per le app 1, 2, 4 e 5 i vincoli di posizionamento potrebbero essere limitati per l'esecuzione solo sui nodi in cui ALLOW_ALL_APPS = TRUE.

7. Nella definizione del servizio per l'app 3 non ci sono vincoli di posizionamento.

8. Service auto scaling è configurato per tutte le app in base alle metriche del contenitore o dell'applicazione.