Django AWS Elastic Beanstalk migrate database

Question

Sto distribuendo un progetto Django in AWS usando Elastic Beanstalk e sono bloccato nella migrazione del database.

Dove sono: Sono in grado di distribuire correttamente il mio progetto django e caricare la pagina tramite mysubdomain.elasticbeanstalk.com. La pagina viene caricata senza errori finché non arrivo a una pagina che deve effettuare una chiamata al database. Ho quindi ricevuto un errore come relation "accounts_user" does not exist LINE 1: SELECT COUNT(*) FROM "accounts_user" perché il mio database non è stato migrato.

Quello che ho provato: Ho provato diverse varianti di cose. Fortunatamente ci sono un'abbondanza di post Stackoverflow e un paio di tutorial. Sfortunatamente, sembra che tutti stiano usando una versione diversa e ciò che suggeriscono non si applica al mio progetto.

È abbastanza chiaro per me che ho bisogno di eseguire la migrazione in un file foobar.config all'interno della cartella .ebextensions/. Qui è la base di ciò che voglio fare:

container_commands: 
    01_migrate: 
    command: "python manage.py migrate --noinput" 
    leader_only: true 

Nei registri, vedo che lo script di distribuzione postale ha provato a correre ma non è riuscito. Non ricevo altre informazioni sull'errore, l'unica cosa che vedo è qualcosa come "ERRORE: 01_migrate post script di distribuzione fallito"

Ho scoperto che ho bisogno di attivare l'ambiente virtuale per il comando, il che rende senso. Da asdf provo questo:

container_commands: 
    01_migrate: 
    command: "source /opt/python/run/venv/bin/activate && python rlg/manage.py migrate --noinput" 
    leader_only: true 

Ma non funziona. Infatti, tramite SSH, scopro che non ho nemmeno una cartella/opt/python /, solo/opt/aws/e/opt/elasticbeanstalk /. Tutte le esercitazioni e le domande SO si riferiscono a questa cartella ma non ce l'ho?

VERSIONI: Python 3.4.1, 1.7.7 Django, AWS CLI 3.2.1, Postgres 9.3

Answer 1

I container_commands non vengono eseguiti all'interno del contenitore finestra mobile. Vengono eseguiti direttamente sull'istanza di ec2. Attualmente sto utilizzando docker exec per eseguire la migrazione. Poiché il contenitore docker in questione è afaik, l'ultimo è stato avviato, utilizzo docker ps -a --no-trunc -q | head -n 1 per ottenere l'id del contenitore.

Alla fine il mio setup.config sembra che

container_commands: 
    01syncdb: 
    command: "docker exec `docker ps -a --no-trunc -q | head -n 1` /var/app/bin/python /var/app/manage.py syncdb --noinput &>> /tmp/deploy.log" 
    leader_only: true 
    02migrate: 
    command: "docker exec `docker ps -a --no-trunc -q | head -n 1` /var/app/bin/python /var/app/manage.py migrate --noinput &>> /tmp/deploy.log" 
    leader_only: true 

Spero che risolve il problema pure.

Answer 2

So che questo è un vecchio post ma voglio postare la mia risposta qui perché mi ci è voluto un bel po 'di tempo per capire.

Sebastian tipo di mi ha segnalato nella giusta direzione, ma il problema con questo approccio è eseguito prima della distribuzione (in modo da migrare il vecchio codice)

È inoltre possibile utilizzare il comando files in ebextensions e scrivere un file/opt/elasticbeanstalk/ganci/AppDeploy/post, ma questo verrà eseguito su istanza mai

È possibile combinare queste due cose in:

container_commands: 
    01migrate: 
    command: "mkdir -p /opt/elasticbeanstalk/hooks/appdeploy/post/ && echo -e '#!/bin/bash\ndocker exec `docker ps -a -q | head -n 1` python <path_to_code> migrate' > /opt/elasticbeanstalk/hooks/appdeploy/post/99_migrate.sh && chmod +x /opt/elasticbeanstalk/hooks/appdeploy/post/99_migrate.sh" 
    leader_only: true 

questo creerà uno script di post deploy nella corretta di r e SOLO sul leader.

Questo funziona molto bene per me ma attenzione, le directory ganci sono non-documentato caratteristiche

Answer 3

Aggiornamento informazioni riguardanti la versione più recente Elastic Beanstalk.

Sto usando 64bit Amazon Linux 2016.09 v2.3.3 running Python 3.4.

Il seguente comando funziona per me senza dover attivare lo virtualenv o creare un hook di distribuzione di app post.

container_commands: 
    01_migrate_db: 
    command: "python manage.py db upgrade" <-- insert your migration command here 
    leader_only: true 

Al fine di dimostrare che il container commands eseguirà in una fase di post implementazione, ho fatto un cambiamento ai miei modelli, generato gli script migrazioni aggiornati, schierato la nuova versione e controllato per vedere se il database è stato migrato con successo : Successo!