7

Sto eseguendo un'applicazione elasticbeanstalk, con più ambienti. Questa particolare applicazione ospita contenitori docker che ospitano un servizio web.Distribuire a elasticbeanstalk tramite il comando CLI deploy con Dockerrun.aws.json

Per caricare e distribuire una nuova versione dell'applicazione in uno degli ambienti, posso passare attraverso il client Web e fare clic su "Carica e distribuisci" e dall'opzione file seleziono il mio ultimo file Dockerrun.aws.json , che fa riferimento all'ultima versione del contenitore ospitato privatamente. Il caricamento e la distribuzione funzionano bene e senza problemi.

Per semplificare la distribuzione per me stesso e gli altri, mi piacerebbe poter utilizzare la CLI per caricare e distribuire il file Dockerrun.aws.json. Se utilizzo il comando cli eb deploy senza alcuna configurazione speciale, il normale processo di zippare l'intera applicazione e inviarlo all'host si verifica e fallisce (non si può pensare che sia sufficiente leggere il file Dockerrun.aws.json).

Ho trovato una documentazione tidbit sul controllo di ciò che viene caricato utilizzando il file .elasticbeanstalk/config.yml.

Utilizzando questa sintassi:

deploy: artifact: Dockerrun.aws.json

Il file viene caricato e in realtà distribuisce con successo per il primo lotto di casi, e quindi non riesce sempre a distribuire per la seconda serie di casi.

L'errore fallimento è del sapore: 'contenitore uscito inaspettatamente ...'

Qualcuno può spiegare, o fornire link per l'approccio canonico per utilizzare la CLI per distribuire applicazioni unico contenitore finestra mobile?

risposta

1

Così si scopre che il metodo che ho elencato in giro con la config.yml era corretta. Il motivo per cui stavo vedendo una distribuzione parzialmente riuscita era perché il container docker in esecuzione negli host non veniva fermato da EB.

Penso che quello che stava accadendo era che EB sta inviando qualcosa come

sudo docker kill --signal=SIGTERM $CONTAINER_ID invece del più comune sudo docker stop $CONTAINER_ID

Il contenitore speciali Io correvo non ha risposto alle SIGTERM e quindi sarebbe solo sedersi Là. Quando l'ho provato localmente con SIGKILL, si sarebbe (ovviamente) fermato correttamente, ma SIGTERM da solo non l'avrebbe fermato.

Il problema non era la metodologia di implementazione ma piuttosto confusione nell'output generato da EB e la mia interpretazione errata.

0

Poiché è stato richiesto un collegamento, viene fornito un collegamento inizialmente utilizzato per testare e distribuire la finestra mobile con il comando elasticbeanstalk.

Si prega di vedere se questo ti aiuta così: https://fangpenlin.com/posts/2014/11/25/running-docker-with-aws-elastic-beanstalk/

+0

Buon articolo: molte informazioni utili. Non l'avevo mai visto prima. –

+2

Peccato che il link sia morto. – neverfox

+0

Il link corretto è: https://fangpenlin.com/posts/2014/11/25/running-docker-with-aws-elastic-beanstalk/ –

Problemi correlati