Django Migrate Command

Django
1

Hey folks,

I’m giving Fly a spin to see how it handles Django apps. The setup and deploy went well and the process was nice and straight-forward.

I then went to run the the manage.py migrate command. First off when I ssh into the app python is not available on the PATH.

To get it to work I had to do the following:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/layers/paketo-buildpacks_cpython/cpython/lib
export PYTHONPATH=$PYTHONPATH:/layers/paketo-buildpacks_pip-install/packages/lib/python3.10/site-packages
export PATH=$PATH:/layers/paketo-buildpacks_cpython/cpython/bin

The migration started but then was killed:

# python manage.py migrate
Operations to perform:
  Apply all migrations: admin, api, auth, contenttypes, django_rest_passwordreset, oauth2_provider, sessions, social_django, taggit
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying taggit.0001_initial... OK
  Applying taggit.0002_auto_20150616_2121... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying taggit.0003_taggeditem_add_unique_index... OK
  Applying auth.0001_initial... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying auth.0008_alter_user_username_max_length... OK
  Applying auth.0009_alter_user_last_name_max_length... OK
  Applying auth.0010_alter_group_name_max_length... OK
  Applying auth.0011_update_proxy_permissions... OK
  Applying auth.0012_alter_user_first_name_max_length... OK
  Applying api.0001_initial...Killed

This happened numerous times until eventually all the migrations were applied. Why does the migration get killed? Is there anyway for me to find more info on why this might be happening?

2

My first guess might be out-of-memory given the default size of our VMs.

You can investigate a little further by running fly status --all to see your VMs listed, then you can inspect a particular VM by running fly vm status <id> where the ID comes from that first status command - it should also be the hostname of the VM when you’re SSH’d into it.

If you wind up wanting to investigate adding more memory, we have some documentation here for that: Scaling and Autoscaling · Fly Docs

3

Also, have you tried the release command: App Configuration (fly.toml) · Fly Docs? You might be better off running your migrations during the deployment process.

1 Like
4

Thanks. I haven’t been able to reproduce since, which is a pity, so I haven’t been able to investigate further.

5

I had read about this but I wanted to understand why it was happening in the SSH console first before adding the release command. Thanks for the reply.