SQLite DBFile needs to be externalized

[babanomania]

@DartLazer I think below could be our target docker-compose

version: "3.8"
   
services:
  app:
    network_mode: "host"
    build: .
    image: whoishome
    command: python /mysite/manage.py runserver 0.0.0.0:${WHOIH_PORT:-8000}
    environment:
      - DJANGO_TZ=${WHOIH_TZ}
      - DJANGO_DBPATH=/dbstore/db.sqlite3
    restart: always
    volumes:
      - dbstore:/dbstore
    depends_on:
      - migration

  migration:
    build: .
    image: whoishome
    command: bash -c "python manage.py migrate --noinput && python3 manage.py loaddata static_data.json"
    environment:
      - DJANGO_TZ=${WHOIH_TZ}
      - DJANGO_DBPATH=/dbstore/db.sqlite3
    volumes:
      - dbstore:/dbstore 

volumes:
  dbstore:

It has two advantages

• SQL Lite file is away from the main container, we can upgrade the container smoothly without worrying about the db.sqllite3 file
• For new users, we can start with a fresh db, without any sqlite3 comitted into git, below could be our static_data.json file, the installed application will not have any predefined admin user

  [
    {
      "model": "whoishome.scannerconfig",
      "pk": 1,
      "fields": {
        "not_home_treshold": 21,
        "internet_interface": "eth0",
        "arp_string": "arp-scan --interface=",
        "ip_subnet": "192.168.2.",
        "ip_range_start": "1",
        "ip_range_end": "198"
      }
    },
    {
      "model": "whoishome.emailconfig",
      "pk": 1,
      "fields": {
        "email_switch": false,
        "sender_address": "secret@secret.com",
        "your_password": "secret",
        "to_address": "secret@gmail.com",
        "smtp_domain": "smtp.gmail.com",
        "smtp_port": "465",
        "departure_mail_subject": "test",
        "departure_mail_body": "test",
        "arrival_mail_suject": "test",
        "arrival_mail_body": "test"
      }
    },
  ]
  

But the challenge is to make sure, the existing users keep using the same db.sqlite3 file without loosing any data.
We need to copy the existing db.sqlite3 file into a volume, that's it.

cd /path/to/WhoIsHomeUI/
docker container create --name dummy -v whoishomeui_dbstore:/mnt/test hello-world
docker cp mysite/db.sqlite3 dummy:/mnt/test/db.sqlite3
docker rm dummy

where whoishomeui_dbstore is name of the new volume, since the user clones the repo to a directory named WhoIsHomeUI

But we'll have to test this

[DartLazer]

Awesome looking good! I'll have a proper look and comment tomorrow!

[DartLazer]

Good morning @babanomania ,

I've had a look at your code and tested successfully with the following changes!

• I renamed static_data.json to database_preload_.json (I like clear filenames, it tells straight away what it does) and located it in django/whoishome/fixtures as per Django convention
• Accordingly I changed line 21 in docker-compose.yml to read: command: bash -c "python manage.py migrate --noinput && python3 manage.py loaddata database_preload"
• In file django/mysite/settings.py I changed line 83 to: 'NAME': os.environ.get('DJANGO_DBPATH', BASE_DIR / 'db.sqlite3'),
• In the README.MD and CHANGELOG.MD the update instructions should read the following command after upgrading the containers to copy the old database file into the new volume docker-compose run app cp db.sqlite3 /dbstore

Do you want to commit and pull request yourself (since it's mostly your work, for the credits) or you want me to do it?

[DartLazer]

Actually I just rechanged the whole docker file to just use one container:

version: "3.8"

services:
  web:
    network_mode: "host"
    build: .
    command: bash -c "python mysite/manage.py migrate --noinput && python3 mysite/manage.py loaddata database_preload.json && python mysite/manage.py runserver 0.0.0.0:${WHOIH_PORT:-8000}"
    environment:
      - DJANGO_TZ=${WHOIH_TZ}
      - DJANGO_DBPATH=/dbstore/db.sqlite3
    restart: always
    volumes:
      - .:/mysite
      - dbstore:/dbstore


volumes:
  dbstore:

I don't really think running those 2 commands warrants an extra container what do you think? This way the server still autoreloads during dev

[babanomania]

@DartLazer looks good,
I'll create a branch and send a pull request, thanks for checking

[DartLazer]

A better way to preload the database perhaps would have been via a migration (for the next project?) I have done the same now with the discord notifications

[DartLazer]

Implemented in c19bba4