Entonces, estoy implementando contenedores django, postgress y nginx a través de docker-compose y tengo un problema que parece que no puedo resolver.
Para resolver el siguiente error en mi aplicación Django, sabía que solo tenía que ejecutar una migración de Django.
docker@postgres ERROR: relation "accounts_myprofile" does not existEn un intento de ejecutar migraciones, probé:
docker-compose run web python manage.py makemigrations docker-compose run web python manage.py migrateque devolvió lo siguiente:
Migrations for 'accounts': accounts/migrations/0001_initial.py: - Create model Entry - Create model MyProfile Running migrations: No migrations to apply.Solo pude migrar con éxito desde el contenedor de Django, ejemplo:
docker exec -i -t 6dc97c6a305c /bin/bash python manage.py makemigrations python manage.py migrateAunque he resuelto el problema, todavía no entiendo por qué ejecutar la migración a través de docker-compose run en realidad no migra nada. Espero que alguien pueda indicarme la dirección correcta en esto.
Además, no sé si se trata de un problema relacionado o no, pero cuando ejecuto esos comandos web de docker-compose run, parecen estar creando nuevos contenedores que no se cerrarán a menos que los detenga manualmente, docker-compose stop no los quita.
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES a7bb3c7106d1 accounts_web "python manage.py che" 4 hours ago Restarting (0) 41 minutes ago 8000/tcp accounts_web_run_62 ee19ca6cdf49 accounts_web "python manage.py mig" 4 hours ago Restarting (0) 43 minutes ago 8000/tcp accounts_web_run_60 2d87ee35de3a accounts_web "python manage.py mak" 4 hours ago Restarting (0) 43 minutes ago 8000/tcp accounts_web_run_59 1c6143c13097 accounts_web "python manage.py mig" 4 hours ago Restarting (1) 44 minutes ago 8000/tcp accounts_web_run_58 6dc97c6a305c b1cb7debb103 "python manage.py run" 3 days ago Up 4 hours 8000/tcp accounts_web_1Nota: Docker-compose stop detendrá correctamente el contenedor en la parte inferior (como debería), pero el otro contenedor creado por docker-compose run web python manage.py migrate deberá detenerse manualmente.
mi ventana acoplable-componer
web: restart: always build: ./web expose: - "8000" links: - postgres:postgres volumes: - /usr/src/app - /usr/src/app/static env_file: .env environment: DEBUG: 'true' command: python manage.py runserver 0.0.0.0:8000 postgres: restart: always image: kartoza/postgis:9.4-2.1 ports: - "5432:5432" volumes: - pgdata:/var/lib/postgresql/data/ Ya te has dado cuenta del problema. Cuando usa docker-compose run , se crea un nuevo contenedor.
Cuando ejecutó el primer comando (makemigrations), se creó un nuevo contenedor, se ejecutó makemigrations y los archivos de migración se escribieron en el sistema de archivos del (nuevo) contenedor.
Cuando ejecutó el segundo comando (migrar), se creó otro contenedor nuevo. La migración corrió, pero no tenía nada que ver. Eso se debe a que los archivos de migración no estaban disponibles: se escribieron en un contenedor diferente al nuevo.
Puedes resolver esto de un par de maneras.
Primero, puede hacer lo que ya hizo, pero use docker-compose exec en lugar de run .
docker-compose exec web python manage.py makemigrations docker-compose exec web python manage.py migrate exec utilizará el contenedor que ya se está ejecutando, en lugar de crear nuevos contenedores.
Otra opción es usar un script de punto de entrada y ejecutar la migración allí, antes de que se inicie el servidor. Este es el camino a seguir si prefiere que las cosas sean más automáticas.
archivo acoplable:
COPY entrypoint.sh /entrypoint.sh RUN chmod +x /entrypoint.shpunto de entrada.sh:
#!/bin/sh python manage.py makemigrations python manage.py migrate exec "$@"docker-compose.yml (en 'web'):
entrypoint: /entrypoint.sh En este escenario, cuando se inicie el contenedor, se ejecutará la secuencia de comandos del punto de entrada, se encargará de la migración y luego se entregará al command (que en este caso es runserver Django).
Como notó, los nuevos contenedores siguen funcionando. Eso normalmente es inesperado, porque anuló el comando con uno que debería salir (en lugar de seguir ejecutándose). Sin embargo, en docker-compose.yml, especificó restart: always . Por lo tanto, ejecutarán los comandos de migración una y otra vez, reiniciando cada vez que salga el comando.
Dan Lowe dio una muy buena respuesta, pero el guión del punto de entrada no funcionaba para mí. El problema es que algunas "migraciones" esperan su entrada, por ejemplo, "sí"/"no".
Puede complementar la respuesta de Dan Lowe con:
python manage.py makemigrations --noinputen vez de
python manage.py makemigrations(Esto funciona al menos para preguntas simples de "sí"/"no")
Este anuncio es un complemento a las respuestas de Dan Lowe y Rexcirus.
Para que funcionara bien durante CodeBuild y Fargate, hice algunos cambios:
archivo de acoplamiento:
COPY ./docker/entrypoint.sh /usr/local/bin/ COPY ./docker/entrypoint.sh /${projectName}/ # backwards compat RUN ln -s usr/local/bin/entrypoint.sh / ENTRYPOINT ["entrypoint.sh"] CMD ["entrypoint.sh"]./docker/punto de entrada.sh
#!/bin/sh python manage.py makemigrations --noinput python manage.py migrate python manage.py runserver 0.0.0.0:8000Ahora todo está funcionando bien.