Putting Django migrate & collectstatic on Build CMD
While trying to solve my odd mem issue when deploying my Django app, I experimented and put migration & collectstatic at the building stage.
This seems to work correctly, solves the mem issue and solve the long restart issue too.
Which is great but I'm not sure of what are the implications of my changes, actually why does the collectstatic works at this stage?
Shouldn't this be working only after docker run and image publishing?
If someone could explain ^^
Here's the full config:
{
"$schema": "https://railway.app/railway.schema.json",
"build": {
"builder": "NIXPACKS",
"buildCommand": "python manage.py migrate && python manage.py collectstatic --noinput",
"watchPatterns": [
"backend/**"
]
},
"deploy": {
"numReplicas": 1,
"startCommand": "gunicorn backend.wsgi",
"healthcheckPath": "/health",
"sleepApplication": true,
"restartPolicyType": "ON_FAILURE",
"restartPolicyMaxRetries": 10
}
}
Solution:Jump to solution
Collect static moves the files from your template directories, asset directories, to your static folder. It is literally a function that moves things, nothing more.
Migrate does exactly that, it uses your database connection and migrates all the schema changes.
Both of these are just plain python functions and can be run at any time. The common thread of them being done at runtime is just how the people that wrote the templates decided to do it. But being that they are just python, as long as they are executing after the requirements.txt file is run and everything is installed, it doesn’t really matter where these commands are run....
9 Replies
Project ID:
d6a04e84-91e3-4e5a-94eb-11dae5cca406d6a04e84-91e3-4e5a-94eb-11dae5cca406
well why do you think this wouldn't work?
I'm still new to the docker stuff and for me the before "docker run" we are not running in the same env as when we run gunicorn.
So collectstatic would copy the file "outside" of the venv, no?
If you have some articles somewhere for me to understand better how all of this work...
migrate only does stuff with the database, and collectstatic only moves some files around, two things that have no issues being run in the build phase
none of this is railway specific, so just go find some articles about how docker works!
Also, then why the "usual" practice I saw on railway is to run:
python manage.py migrate && python manage.py collectstatic --noinput && gunicorn backend.wsgi
=> which causes mem issue from migrate and/or collectstatic
=> which then prevents the use of sleepApp
Instead of:
BuildCmd: python manage.py migrate && python manage.py collectstatic --noinput
StartCmd: gunicorn backend.wsgi
=> which solves all the above ^^?
I know it's not related to railway, don't need to be condescending 😉
I'm sorry you got that impression, I didn't mean to come off like that
Anyway, I thought collecstatic was indeed moving stuff "but" outside the running env, so files wouldn't be found when running the server.
I'll try to understand more about that.
Also, I thought that sharing my solution here would be interesting to other Django user on Railway.
Like the healthCheck solution 😉
Solution
Collect static moves the files from your template directories, asset directories, to your static folder. It is literally a function that moves things, nothing more.
Migrate does exactly that, it uses your database connection and migrates all the schema changes.
Both of these are just plain python functions and can be run at any time. The common thread of them being done at runtime is just how the people that wrote the templates decided to do it. But being that they are just python, as long as they are executing after the requirements.txt file is run and everything is installed, it doesn’t really matter where these commands are run.