Il comando di migrazione di Django su Amazon Elastic Beanstalk viene ucciso

Question

Sto usando Amazon Elean Beanstalk e Django 1.8.2. Qui è la mia comandi container,

container_commands: 
    01_wsgipass: 
    command: 'echo "WSGIPassAuthorization On" >> ../wsgi.conf' 
    02_makemigrations: 
    command: "source /opt/python/run/venv/bin/activate && python manage.py makemigrations --merge --noinput" 
    leader_only: true 
    03_migrate: 
    command: "source /opt/python/run/venv/bin/activate && python manage.py migrate --noinput" 
    leader_only: true 

Per alcuni motivi il comando migrate viene ucciso. Tutte le migrazioni funzionano bene anche con un nuovo database nel mio locale. Ma segue è l'errore che appare su eb-activity.log.

Synchronizing apps without migrations: 
    Creating tables... 
    Running deferred SQL... 
    Installing custom SQL... 
    Running migrations: 
    Rendering model states.../bin/sh: line 1: 21228 Killed     python manage.py migrate --noinput 
    (ElasticBeanstalk::ExternalInvocationError) 

Nota: gli stessi comandi del contenitore funzionavano correttamente senza problemi in precedenza su Elastic Beanstalk. Ho provato con --verbose 3 con il comando migrate ma non ho ricevuto altri messaggi di debug.

Qualche soluzione? Grazie in anticipo.

Answer 1

AWS non è compatibile con gli sviluppatori quando si tratta di risoluzione dei problemi con il meccanismo di registrazione scadente.

Come utente avido di AWS che ha recentemente valutato EBS per un progetto Django, sono assolutamente d'accordo con questo per gli stessi motivi. Ho finito per andare con Heroku per questo e ragioni per cui non entrerò, ma penso che il seguente schema sia d'aiuto.

I passaggi per preparare l'ambiente di produzione possono andare in luoghi diversi; non devono accadere nell'ambiente del server Web di destinazione.

Ho finito per estrapolare le mie attività di make/migrate dall'automazione della distribuzione e in attività che si sono verificate poco prima. Le uniche cose che accadono nel mio ambiente di server web di destinazione sono direttamente correlate al codice su quel server.

In altre parole: mi raccomando se si dispone di uno strumento CI per build/test, si esegue il make/migrate e qualsiasi altra preparazione per l'ambiente all'esterno del server Web nella pipeline di distribuzione. Qualcosa di simile:

• codice Checkout
• Test Run (tra cui rendere/migrare sulla base di dati effimeri per testarlo se possibile)
• Put applicazione in modalità di manutenzione (o simili, se necessario) del database
• Snapshot
• Marca/Migrate sulla produzione
• Deploy
• Se Deploy non riesce, rollback DB, rollback app.

Quindi si separano le preoccupazioni dell'automazione per il proprio server delle applicazioni e l'automazione per il resto dell'ambiente di produzione e che l'amministratore può gestirlo. È in grado di gestirli nello stesso posto, ma chiaramente è un po 'goffo per farlo utilizzando le strutture EBS.