6

Ho un app Dockerfile/elastic-beanstalk in un repo git che tira un archivio della corrente rilascio dell'applicazione da s3 e lo lancia. Funziona alla grande la prima volta che distribuisco; il contenitore Docker viene creato e l'app si avvia e viene eseguita correttamente. Il problema arriva dopo aver apportato una modifica all'app, caricare nuovamente il tarball su s3 ed eseguire eb deploy.elastico-beanstalk finestra mobile app non aggiornamento su implementazione

$ eb deploy 
INFO: Environment update is starting. 
INFO: Deploying new version to instance(s). 
INFO: Successfully built aws_beanstalk/staging-app 
INFO: Successfully pulled yadayada/blahblah:latest 
INFO: Docker container 06608fa37b2c is running aws_beanstalk/current-app. 
INFO: New application version was deployed to running EC2 instances. 
INFO: Environment update completed successfully. 

Ma l'app non è stata aggiornata su *.elasticbeanstalk.com. Sto indovinando poiché il Dockerfile non è cambiato, la finestra mobile non ricostruisce il contenitore (e tira l'ultimo tarball dell'applicazione). Mi piacerebbe essere in grado di forzare una ricostruzione ma lo strumento eb non sembra avere quell'opzione. Posso forzare una ricostruzione dalla console del sito Web, ma ovviamente non è un vantaggio per l'automazione. Sto confermando ogni modifica a git e speravo che lo eb lo usasse per sapere che una ricostruzione è necessaria ma che non sembra fare alcuna differenza. Sto usando docker/elastico-beanstalk nel modo sbagliato? Idealmente, voglio impegnarmi a git e fare in modo che il beanstalk reinstalli automaticamente l'app.

risposta

0

Mi chiedo se si potrebbe provare a utilizzare l'input dati utente quando si definiscono le istanze in Beanstalk? Qualcosa di simile potrebbe sparare a destra alla fine del boot:

#!/bin/bash 
cd /app/dir/home 
sudo docker pull username/container 
... other things you may need to do ... 

più che si può fare riferimento sugli script di dati utente e gli eseguibili: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html

+0

Sembra che il beanstalk non supporti i dati utente, almeno secondo [questo] (http://stackoverflow.com/questions/8412231/how-do-i-pass-userdata-to-a-beanstalk -instance-with-cloudformation) e [this] (https://forums.aws.amazon.com/thread.jspa?threadID=81687). –

5

Il problema con l'utilizzo di Docker per C'è che esso doesn Si comportano come uno script in quanto non verrà ricostruito a meno che le modifiche di Dockerfile non vengano modificate. Quindi devi inserire tutte le cose che devono essere ricostruite ogni volta in uno script wrapper di avvio piuttosto che nello Dockerfile. Così ho spostato la parte che scarica il tarball dell'applicazione in uno script che installa Dockerfile nel contenitore. Quindi, all'avvio del contenitore, il tarball viene scaricato e scompattato e solo in tal caso può iniziare l'applicazione reale. Funziona e il re-deploy ora funziona come previsto. È un po 'esagerato nel debugare il processo e mi porta a pensare che l'uso di Docker con EB per CI sia un po' un trucco.

+1

Ho esattamente lo stesso problema. Ridistribuisci la mia app Web ma non è aggiornata. Puoi fornire più precisione su come lo risolvi? Per il momento il mio Dockerfile chiama lo script .sh che esegue il mio server web –

0

probabilmente si dovrebbe read this first per ottenere una migliore comprensione di ciò che stiamo per avere il nostro sito locale nel nostro repository git locale e how to push it fino a ElasticBeanstalk per rendere il sito live.

Trova o crea una cartella nella radice del nostro sito chiamata . Elasticbeanstalk.
All'interno di tale cartella faremo due file:

configurazione

[global] 
ApplicationName=YourApplicationNameFromAWSConsole 
AwsCredentialFile=.elasticbeanstalk/aws_credentials 
DevToolsEndpoint=git.elasticbeanstalk.us-east-1.amazonaws.com 
EnvironmentName=EnvironmentNameFromAWSConsole 
Region=us-east-1 

aws_credentials

[global] 
AWSAccessKeyId=AKIAxxxxxxxxxxxxxxxxxxxxx 
AWSSecretKey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

Invece di eb deploy uso git aws.push per aggiungere e impegnarsi di tutto per ElasticBeanstalk

git add *.* 
git commit -m "Adding AWS Configs" 
git aws.push 
0

TLDR: Si può utilizzare ContainerDirectory senza un HostDirectory o potrebbe essere necessario aggiornare il 03build.sh di costruire con il --no-cache = true bandiera.

Dopo un miliardo di ore più tardi, ho finalmente risolto questo problema con il mio caso d'uso. Sto usando CodePommeline per eseguire CodeCommit, CodeBuild ed Elastic Beanstalk per creare una soluzione di integrazione/consegna continua continua in AWS con docker. Il problema che mi sono imbattuto in CodeBuild è stato la creazione e la pubblicazione di nuove immagini della finestra mobile in AWS ECR (registro contenitore EC2) e EBS stava correttamente tirando giù la nuova immagine, ma l'immagine della finestra mobile non veniva mai aggiornata sul server.

Dopo aver esaminato l'intero processo di come EBS costruisce l'immagine della finestra mobile (c'è un articolo davvero eccezionale here, part 1 e here part 2 che fornisce una panoramica), ho scoperto il problema.

Per aggiungere all'articolo, c'è un processo in 3 fasi in EBS sulle istanze EC2 che vengono avviate per la distribuzione di immagini di finestra mobile.

  1. pre
  2. enact
  3. postale

Questo processo a 3 stadi è una sequenza di file bash che vengono eseguiti che si trovano in /opt/elasticbeanstalk/hooks/appdeploy/.

La pre-fase di contenere i seguenti script di shell:

  1. 00clean_dir.sh - Pulisce directory in cui verrà scaricato fonte, rimuove i contenitori docker e le immagini (ad esempio di pulizia)
  2. 01unzip.sh - Download fonte da S3 e decomprime si
  3. 02loopback-check.sh - verifica non si dispone di impostazione finestra mobile loopback impostato
  4. 03build.sh - Questo è dove la magia accade in cui EC2 sarà costruire la vostra immagine finestra mobile dal Dockerfile o Dockerrun. aws.json. Dopo molti test, mi sono reso conto che questo script di build stava creando la mia immagine aggiornata, ma ho modificato questo script per includere anche il flag --no-cache sulla finestra mobile.

La fase di messa in scena è dove il problema di memorizzazione nella cache era effettivamente in corso. La fase Enact è composto da:

  1. 00run.sh - questo è dove run finestra mobile viene eseguita contro l'immagine che è stato generato nella fase di pre sulla base di variabili d'ambiente e le impostazioni nel vostro Dockerrun.aws.json.Questo è ciò che stava causando il problema di memorizzazione nella cache per me.
  2. 01flip.sh - Converte da AWS-messa in scena al corrente-app e un sacco di altre cose

Quando avrei eseguire corsa finestra mobile dall'immagine che è stato generato in fase di Pre, 03build.sh, lo farei guarda le mie modifiche aggiornate Tuttavia, quando eseguivo lo script della shell 00run.sh, apparivano le vecchie modifiche. Dopo aver esaminato il comando di marcia finestra mobile, che stava eseguendo

`Docker command: docker run -d -v null:/usr/share/nginx/html/ -v /var/log/eb-docker/containers/eb-current-app:/var/log/nginx ca491178d076` 

Il -v null:/usr/share/nginx/html/ è ciò che è stato rompendola e causando non aggiornare. Ciò era dovuto al fatto che il mio file Dockerrun.aws.json aveva

"Volumes": [ 
    { 
     "ContainerDirectory": "/usr/share/nginx/html/" 
    } 
    ], 

senza una posizione host di riferimento. Di conseguenza, eventuali modifiche future apportate non sono state aggiornate.

Per la mia soluzione, ho appena rimosso l'array "Volumes" poiché tutti i miei file sono contenuti nell'immagine della finestra mobile che carico in ECR. Nota: Potrebbe essere necessario aggiungere anche il --no-cache allo 03build.sh.

Problemi correlati