Skip to content
Snippets Groups Projects

Add datamodel

Merged Mattia Mancini requested to merge add_datamodel into main

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Klaas Kliffen
    • Resolved by Mattia Mancini

      A bit more general thing. I find the project structure a bit weird. A "normal" Django project has the following layout:

      - <project_folder>
          - __init__.py
          - settings.py
          - wsgi.py
          - etc.
      - <application folder>
          - __init__.py
          - admin.py
          - models.py
          - etc.
      - manage.py
      - Dockerfile
      - requirements.txt
      - README.md
      - gitlab-ci.yml
      - etc.

      I can understand trying to encapsulate all of the Django parts in a single folder, but could we put the docker then in the root (as it is not a part of Django code persé).

      @vermaas is there a specific reasoning behind the structure the way it is?

      Additionally, could we move most of the settings to environment variables? It would be relatively simple to configure some defaults for development and override them for production? This way we would only need a single settings file (only exception I can think of are the database configuration, but this could perhaps be done with a flag and switch between two configurations). One example this would fix are the two wsgi.py files, where wsgi_docker_sdc.py is actually not needed (since it tries to check the env var first).

      Edited by Klaas Kliffen
    • Resolved by Klaas Kliffen

      Additionally, I saw that the favicon was put into the application folder. This is not wrong persé, however it would be better to put into a separate static files folder which can be added by the STATICFILDER_DIRS setting: https://docs.djangoproject.com/en/4.0/howto/static-files/.

      Normally what I would to is actually to use a staged build and let another server (nginx) serve the static files. That means that there are at least two containers required: nginx, serving static files (based on manage.py collectstatic) and the real python container serving the Django application.

      An example of the two docker files would be:

      # Django container
      FROM python:3.10
      
      WORKDIR /opt/
      RUN pip install pipenv
      COPY Pipfile* ./
      RUN pipenv lock -r  > requirements.txt && pip install -r requirements.txt
      COPY src ./
      
      EXPOSE 8000
      CMD ["gunicorn", "--workers", "4", "--bind", "0.0.0.0:8000", "stargazer.wsgi"]
      # Static file server
      FROM python:3.10 as DJANGO_STATIC
      
      WORKDIR /opt/
      RUN pip install pipenv
      COPY Pipfile* ./
      RUN pipenv lock -r  > requirements.txt && pip install -r requirements.txt
      COPY src ./
      RUN python manage.py collectstatic --noinput
      
      FROM nginx:mainline-alpine
      COPY --from=DJANGO_STATIC /opt/static /usr/share/nginx/html/
      EXPOSE 80
  • Mattia Mancini added 4 commits

    added 4 commits

    • 3da4ca0f - Add migration file
    • 52aa1cdd - Simplify test step
    • 96cd09ca - Remove unnecessary client instance in test
    • f6da43f7 - Use appropriate docker version to build

    Compare with previous version

  • Mattia Mancini added 1 commit

    added 1 commit

    Compare with previous version

  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Please register or sign in to reply
    Loading