#Docker, collectstatic and migrate best practices

8 messages · Page 1 of 1 (latest)

brazen sandal
#

Hi All 👋
What's the best practice when continuously deploying with docker with regards to collectstatic and migrate?

I have been running both these commands manually once the web container is up, but I'm wondering if there's a better way. Any resources anyone can point me to? 🙂

Thanks!

brazen sandal
#

i want to collectstatic and migrate on startup but only once per new deploy, not every time container is restarted

i can't collectstatic during build phase because the target folder is mounted via a shared volume to nginx as well

i guess i could write a script that does all this by maybe tracking container/git status 🤔

i'm also wondering how to best revert in case of any issues, but currently that's not really an issue.. the app is fairly simple and i have backups

uneven quail
#

I assume that you are just running these on a VPS or similar manually?

manic plover
#

What do you perceive as the harm in running them every time the container is started?

azure bramble
#

I'm with Ben. I just have an entrypoint.sh script that runs on every start-up. It doesn't apply migrations that were already applied, and I seldom restart unless I'm deploying, so I think it's perfectly acceptable to run every time.

carmine gyro
#

I use CMD ./entrypoint.sh because CMD allows you to pass in other arguments such as python manage.py runserver to just start up the server. ENTRYPOINT in docker doesn't allow this.

# entrypoint.sh

python manage.py collectstatic 
python manage.py migrate

if $DEBUG_BOOL -eq 'False'
then
    gunicorn django_server.wsgi --bind=${DJANGO_HOST:-0.0.0.0}:${DJANGO_PORT:-8000}
else
    python manage.py runserver ${DJANGO_HOST:-0.0.0.0}:${DJANGO_PORT:-8000}
fi
brazen sandal
#

hey all, thanks so much for your replies! 🙏

yes it's just VPS

collectstatic takes ~5-10 sec to run so I was wondering if that can have negative consequences, but thinking about it, improving it right now is premature optimisation for sure 😅

thanks again, I'll use the entrypoint script 🙂

azure bramble
#

5-10 seconds to me is acceptable, and I'd just try and do it during lowest traffic periods, but the "industrial" solution would be to use something like kubernetes with staggered / rolling deployments (where you have 2+ copies, build a new image, restart 1-x at a time, but always leave a minimum of y pods running, even if they serve a slightly older version for a few seconds longer). Then you can have zero-downtime deployments.