HTML templates reloading issue (TailwindCSS)

[adrivn]

Hello Nick,

First off, thank you loads for the work you put into this bundle, you have inspired me greatly to dive into Docker and containerization.

• System: W10, running everything under WSL2, so no mounting issues at all.

The issue at hand relates to hot reloading while developing. I find that whenever I modify a *.py file the webapp reloads just fine, showing the changes instantaneously. This is not the case when its an *.html template being modified. The css and js watchers are up and running. I checked the tailwind.config.js file and its pointing to the app folder, recursively and gathering all *.html files, so I don't know where to look now.

Thank you

[nickjj]

Hi,

The HTML files would still be related to Django btw, it would be really interesting if py files worked but html didn't.

Do the CSS and JS watchers show that files were updated when you make a change by notifying you in the terminal? It should say it was rebuilt.

[adrivn]

Do the CSS and JS watchers show that files were updated when you make a change by notifying you in the terminal? It should say it was rebuilt.

No, upon saving/modifying an HTML file it does not show up on the log "Rebuilding... Done in XXXms".

However when I modify a Python file (views.py let's say) it does reload/update, logging this to the console:

[hellodjango-web-1 | [2022-11-04 14:42:05 +0000] [8] [INFO] Worker reloading: /app/src/pages/views.py modified
hellodjango-web-1 | [2022-11-04 14:42:05 +0000] [8] [INFO] Worker exiting (pid: 8)

This is the log upon starting the container:

[+] Running 6/0
⠿ Container hellodjango-css-1 Created 0.0s
⠿ Container hellodjango-js-1 Created 0.0s
⠿ Container hellodjango-redis-1 Created 0.0s
⠿ Container hellodjango-postgres-1 Created 0.0s
⠿ Container hellodjango-worker-1 Created 0.0s
⠿ Container hellodjango-web-1 Created 0.0s
Attaching to hellodjango-css-1, hellodjango-js-1, hellodjango-postgres-1, hellodjango-redis-1, hellodjango-web-1, hellodjango-worker-1
hellodjango-postgres-1 |
hellodjango-postgres-1 | PostgreSQL Database directory appears to contain a database; Skipping initialization
hellodjango-postgres-1 |
hellodjango-postgres-1 | 2022-11-04 14:09:30.598 UTC [1] LOG: starting PostgreSQL 15.0 (Debian 15.0-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
hellodjango-postgres-1 | 2022-11-04 14:09:30.602 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
hellodjango-postgres-1 | 2022-11-04 14:09:30.602 UTC [1] LOG: listening on IPv6 address "::", port 5432
hellodjango-redis-1 | 1:C 04 Nov 2022 14:09:30.615 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
hellodjango-redis-1 | 1:C 04 Nov 2022 14:09:30.615 # Redis version=7.0.5, bits=64, commit=00000000, modified=0, pid=1, just started
hellodjango-redis-1 | 1:C 04 Nov 2022 14:09:30.615 # Warning: no config file specified, using the default config. In order to specify a config file use redis-server /path/to/redis.conf
hellodjango-redis-1 | 1:M 04 Nov 2022 14:09:30.616 * monotonic clock: POSIX clock_gettime
hellodjango-redis-1 | 1:M 04 Nov 2022 14:09:30.625 * Running mode=standalone, port=6379.
hellodjango-redis-1 | 1:M 04 Nov 2022 14:09:30.626 # Server initialized
hellodjango-redis-1 | 1:M 04 Nov 2022 14:09:30.626 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
hellodjango-redis-1 | 1:M 04 Nov 2022 14:09:30.628 * Loading RDB produced by version 7.0.5
hellodjango-redis-1 | 1:M 04 Nov 2022 14:09:30.628 * RDB age 135642 seconds
hellodjango-redis-1 | 1:M 04 Nov 2022 14:09:30.628 * RDB memory usage when created 1.18 Mb
hellodjango-redis-1 | 1:M 04 Nov 2022 14:09:30.628 * Done loading RDB, keys loaded: 1, keys expired: 0.
hellodjango-redis-1 | 1:M 04 Nov 2022 14:09:30.628 * DB loaded from disk: 0.002 seconds
hellodjango-redis-1 | 1:M 04 Nov 2022 14:09:30.628 * Ready to accept connections
hellodjango-postgres-1 | 2022-11-04 14:09:30.631 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
hellodjango-postgres-1 | 2022-11-04 14:09:30.719 UTC [27] LOG: database system was shut down at 2022-11-03 00:28:48 UTC
hellodjango-postgres-1 | 2022-11-04 14:09:30.904 UTC [1] LOG: database system is ready to accept connections
hellodjango-web-1 | [2022-11-04 14:09:34 +0000] [1] [INFO] Starting gunicorn 20.1.0
hellodjango-web-1 | [2022-11-04 14:09:34 +0000] [1] [INFO] Listening at: http://0.0.0.0:8000 (1)
hellodjango-web-1 | [2022-11-04 14:09:34 +0000] [1] [INFO] Using worker: sync
hellodjango-web-1 | [2022-11-04 14:09:34 +0000] [8] [INFO] Booting worker with pid: 8
hellodjango-css-1 |
hellodjango-css-1 | Rebuilding...
hellodjango-css-1 |
hellodjango-css-1 | Done in 622ms.
hellodjango-worker-1 |
hellodjango-worker-1 | -------------- celery@6d7987657838 v5.2.7 (dawn-chorus)
hellodjango-worker-1 | --- ***** -----
hellodjango-worker-1 | -- ******* ---- Linux-5.10.102.1-microsoft-standard-WSL2-x86_64-with-glibc2.31 2022-11-04 14:09:35
hellodjango-worker-1 | - *** --- * ---
hellodjango-worker-1 | - ** ---------- [config]
hellodjango-worker-1 | - ** ---------- .> app: hello:0x7f5fcde6b2d0
hellodjango-worker-1 | - ** ---------- .> transport: redis://redis:6379/0
hellodjango-worker-1 | - ** ---------- .> results: redis://redis:6379/0
hellodjango-worker-1 | - *** --- * --- .> concurrency: 4 (prefork)
hellodjango-worker-1 | -- ******* ---- .> task events: OFF (enable -E to monitor tasks in this worker)
hellodjango-worker-1 | --- ***** -----
hellodjango-worker-1 | -------------- [queues]
hellodjango-worker-1 | .> celery exchange=celery(direct) key=celery
hellodjango-worker-1 |
hellodjango-worker-1 |
hellodjango-worker-1 | [tasks]
hellodjango-worker-1 |
hellodjango-worker-1 |
hellodjango-worker-1 | [2022-11-04 14:09:35,825: INFO/MainProcess] Connected to redis://redis:6379/0
hellodjango-worker-1 | [2022-11-04 14:09:35,831: INFO/MainProcess] mingle: searching for neighbors
hellodjango-worker-1 | [2022-11-04 14:09:36,849: INFO/MainProcess] mingle: all alone
hellodjango-worker-1 | [2022-11-04 14:09:36,884: WARNING/MainProcess] /home/python/.local/lib/python3.11/site-packages/celery/fixups/django.py:203: UserWarning: Using settings.DEBUG leads to a memory
hellodjango-worker-1 | leak, never use this setting in production environments!
hellodjango-worker-1 | warnings.warn('''Using settings.DEBUG leads to a memory
hellodjango-worker-1 |
hellodjango-worker-1 | [2022-11-04 14:09:36,885: INFO/MainProcess] celery@6d7987657838 ready.
hellodjango-postgres-1 | 2022-11-04 14:14:30.750 UTC [25] LOG: checkpoint starting: time
hellodjango-postgres-1 | 2022-11-04 14:14:31.098 UTC [25] LOG: checkpoint complete: wrote 6 buffers
hellodjango-web-1 | [2022-11-04 14:42:06 +0000] [60] [INFO] Booting worker with pid: 60

[nickjj]

No, upon saving/modifying an HTML file it does not show up on the log "Rebuilding... Done in XXXms".

Have you tried visiting the page and reloading? It might not show up in the terminal but it should update.

The CSS looks like it's reloading based on this:

hellodjango-css-1 |
hellodjango-css-1 | Rebuilding...
hellodjango-css-1 |
hellodjango-css-1 | Done in 622ms.

Have you tried doing a hard reload in your browser to clear any cache?

[adrivn]

Have you tried visiting the page and reloading? It might not show up in the terminal but it should update.

I visited and reloaded after each modification and save. Not working.

The CSS looks like it's reloading based on this:

Yes, the worker starts up fine and does the first build just fine, but not subsequent.

Have you tried doing a hard reload in your browser to clear any cache?

Just tried, same result (no HTML/CSS update)

[nickjj]

Is your source code living inside of WSL 2's file system or is it mounted from a drive in Windows?

I would say try putting it inside of WSL 2's file system, not only may it fix this issue but it's also going to be way way faster. This is how I run things too for reference.

[adrivn]

It is living and running from inside the WSL2 system (I read you recommend it in a different closed issue), it doesn't seem to help with the non-reload of the CSS:

[nickjj]

Do you have DEBUG=true, NODE_ENV=development, WEB_RELOAD=true and DOCKER_WEB_VOLUME=.:/app in your .env file?

[adrivn]

Yes. All of those are identical in the .env file. For reference, here are the contents for the .env , docker-compose.yml and tailwind.config.js files

.env

# Default values are optimized for production to avoid having to configure
# much in production.
#
# However it should be easy to get going in development too. If you see an
# uncommented option that means it's either mandatory to set or it's being
# overwritten in development to make your life easier.

# Enable BuildKit by default:
#   https://docs.docker.com/develop/develop-images/build_enhancements
export DOCKER_BUILDKIT=1

# Rather than use the directory name, let's control the name of the project.
export COMPOSE_PROJECT_NAME=hellodjango

# In development we want all services to start but in production you don't
# need the asset watchers to run since assets get built into the image.
#
# You can even choose not to run postgres and redis in prod if you plan to use
# managed cloud services. Everything "just works", even optional depends_on!
#export COMPOSE_PROFILES=postgres,redis,web,worker
export COMPOSE_PROFILES=postgres,redis,assets,web,worker

# In development avoid writing out bytecode to __pycache__ directories.
#PYTHONDONTWRITEBYTECODE=
export PYTHONDONTWRITEBYTECODE=true

# You should generate a random string of 50+ characters for this value in prod.
# You can generate a secure secret by running: ./run secret
export SECRET_KEY=insecure_key_for_dev

# This should never be set to true in production but it should be enabled in dev.
#export DEBUG=false
export DEBUG=true

# Which Node environment is running? This should be "development" or "production".
#export NODE_ENV=production
export NODE_ENV=development

# A comma separated list of allowed hosts. In production this should be your
# domain name, such as "example.com,www.example.com" or ".example.com" to
# support both example.com and all sub-domains for your domain.
#
# This is being overwritten in development to support multiple Docker dev
# environments where you might be connecting over a local network IP address
# instead of localhost. You should not use "*" in production.
#export ALLOWED_HOSTS=".localhost,127.0.0.1,[::1]"
export ALLOWED_HOSTS="*"

# The bind port for gunicorn.
#
# Be warned that if you change this value you'll need to change 8000 in both
# your Dockerfile and in a few spots in docker-compose.yml due to the nature of
# how this value can be set (Docker Compose doesn't support nested ENV vars).
#export PORT=8000

# How many workers and threads should your app use? WEB_CONCURRENCY defaults
# to the server's CPU count * 2. That is a good starting point. In development
# it's a good idea to use 1 to avoid race conditions when debugging.
#export WEB_CONCURRENCY=
export WEB_CONCURRENCY=1
#export PYTHON_MAX_THREADS=1

# Do you want code reloading to work with the gunicorn app server?
#export WEB_RELOAD=false
export WEB_RELOAD=true

# You'll always want to set POSTGRES_USER and POSTGRES_PASSWORD since the
# postgres Docker image uses them for its default database user and password.
export POSTGRES_USER=hello
export POSTGRES_PASSWORD=password
#export POSTGRES_DB=hello
#export POSTGRES_HOST=postgres
#export POSTGRES_PORT=5432

# Connection string to Redis. This will be used for the cache back-end and for
# Celery. You can always split up your Redis servers later if needed.
#export REDIS_URL=redis://redis:6379/0

# You can choose between DEBUG, INFO, WARNING, ERROR, CRITICAL or FATAL.
# DEBUG tends to get noisy but it could be useful for troubleshooting.
#export CELERY_LOG_LEVEL=info

# Should Docker restart your containers if they go down in unexpected ways?
#export DOCKER_RESTART_POLICY=unless-stopped
export DOCKER_RESTART_POLICY=no

# What health check test command do you want to run? In development, having it
# curl your web server will result in a lot of log spam, so setting it to
# /bin/true is an easy way to make the health check do basically nothing.
#export DOCKER_WEB_HEALTHCHECK_TEST=curl localhost:8000/up
export DOCKER_WEB_HEALTHCHECK_TEST=/bin/true

# What ip:port should be published back to the Docker host for the app server?
# If you're using Docker Toolbox or a custom VM you can't use 127.0.0.1. This
# is being overwritten in dev to be compatible with more dev environments.
#
# If you have a port conflict because something else is using 8000 then you
# can either stop that process or change 8000 to be something else.
#
# Use the default in production to avoid having gunicorn directly accessible to
# the internet without assistance from a cloud based firewall.
#export DOCKER_WEB_PORT_FORWARD=127.0.0.1:8000
export DOCKER_WEB_PORT_FORWARD=8000

# What volume path should be used? In dev we want to volume mount everything
# so that we can develop our code without rebuilding our Docker images.
#export DOCKER_WEB_VOLUME=./public_collected:/app/public_collected
export DOCKER_WEB_VOLUME=.:/app

# What CPU and memory constraints will be added to your services? When left at
# 0, they will happily use as much as needed.
#export DOCKER_POSTGRES_CPUS=0
#export DOCKER_POSTGRES_MEMORY=0
#export DOCKER_REDIS_CPUS=0
#export DOCKER_REDIS_MEMORY=0
#export DOCKER_WEB_CPUS=0
#export DOCKER_WEB_MEMORY=0
#export DOCKER_WORKER_CPUS=0
#export DOCKER_WORKER_MEMORY=0

docker-compose.yml

x-app: &default-app
  build:
    context: "."
    target: "app"
    args:
      - "UID=${UID:-1000}"
      - "GID=${GID:-1000}"
      - "DEBUG=${DEBUG:-false}"
      - "NODE_ENV=${NODE_ENV:-production}"
  depends_on:
    - "postgres"
    - "redis"
  env_file:
    - ".env"
  restart: "${DOCKER_RESTART_POLICY:-unless-stopped}"
  stop_grace_period: "3s"
  tty: true
  volumes:
    - "${DOCKER_WEB_VOLUME:-./public_collected:/app/public_collected}"

x-assets: &default-assets
  build:
    context: "."
    target: "assets"
    args:
      - "UID=${UID:-1000}"
      - "GID=${GID:-1000}"
      - "NODE_ENV=${NODE_ENV:-production}"
  env_file:
    - ".env"
  profiles: ["assets"]
  restart: "${DOCKER_RESTART_POLICY:-unless-stopped}"
  stop_grace_period: "0"
  tty: true
  volumes:
    - ".:/app"

services:
  postgres:
    deploy:
      resources:
        limits:
          cpus: "${DOCKER_POSTGRES_CPUS:-0}"
          memory: "${DOCKER_POSTGRES_MEMORY:-0}"
    environment:
      POSTGRES_USER: "${POSTGRES_USER}"
      POSTGRES_PASSWORD: "${POSTGRES_PASSWORD}"
      # POSTGRES_DB: "${POSTGRES_DB}"
    image: "postgres:15.0-bullseye"
    profiles: ["postgres"]
    restart: "${DOCKER_RESTART_POLICY:-unless-stopped}"
    stop_grace_period: "3s"
    volumes:
      - "postgres:/var/lib/postgresql/data"

  redis:
    deploy:
      resources:
        limits:
          cpus: "${DOCKER_REDIS_CPUS:-0}"
          memory: "${DOCKER_REDIS_MEMORY:-0}"
    image: "redis:7.0.5-bullseye"
    profiles: ["redis"]
    restart: "${DOCKER_RESTART_POLICY:-unless-stopped}"
    stop_grace_period: "3s"
    volumes:
      - "redis:/data"

  web:
    <<: *default-app
    deploy:
      resources:
        limits:
          cpus: "${DOCKER_WEB_CPUS:-0}"
          memory: "${DOCKER_WEB_MEMORY:-0}"
    healthcheck:
      test: "${DOCKER_WEB_HEALTHCHECK_TEST:-curl localhost:8000/up}"
      interval: "60s"
      timeout: "3s"
      start_period: "5s"
      retries: 3
    ports:
      - "${DOCKER_WEB_PORT_FORWARD:-127.0.0.1:8000}:${PORT:-8000}"
    profiles: ["web"]

  worker:
    <<: *default-app
    command: celery -A config worker -l "${CELERY_LOG_LEVEL:-info}"
    entrypoint: []
    deploy:
      resources:
        limits:
          cpus: "${DOCKER_WORKER_CPUS:-0}"
          memory: "${DOCKER_WORKER_MEMORY:-0}"
    profiles: ["worker"]

  js:
    <<: *default-assets
    command: "../run yarn:build:js"

  css:
    <<: *default-assets
    command: "../run yarn:build:css"

volumes:
  postgres: {}
  redis: {}

tailwind.config.js

module.exports = {
  content: [
    '/app/assets/js/**/*.js',
    '/app/assets/css/**/*.css',
    '/app/src/**/*.html'
  ],
}

Also, within the run file, the build:css function reads as this:

function yarn:build:css {
  # Build CSS assets, this is meant to be run from within the assets container
  local args=()

  if [ "${NODE_ENV:-}" == "production" ]; then
    args=(--minify)
  else
    args=(--watch)
  fi

  mkdir -p ../public/css
  DEBUG=0 tailwindcss --postcss -i css/app.css -o ../public/css/app.css "${args[@]}"
}

[nickjj]

This is a tricky one to debug because my set up is nearly the same as you. I also use WSL 2 with Windows 10 and the files are within WSL 2's file system and everything is working. I also haven't seen this pop up for anyone else yet.

I don't think this will make a difference but can you sudo apt-get install inotify-tools? I don't have this package installed but I'd be interested to see if it works. You can also try adding this packages to the list of apt packages in the Dockerfile for both the Node and Python base images and rebuild things, then try again.

[adrivn]

I installed inotify-tools and set up a watch over the public folder (where the static files are deposited and the CSS output file goes, but no change is detected after I change css classes on the HTML files.

BUT if I modify the app/public/css/app.css file (alleged output file), the changes show up instantaneously on both Django (upon refresh) and the inotify watcher

The issue therefore seems to be on the watch of HTML files. IDK if there are issues with the paths, maybe..

[nickjj]

Do you have the same issue with https://github.com/nickjj/docker-flask-example? It has the same set up as this Django app but for Flask. It also uses Gunicorn too. This could help reduce the problem down if it happens to work with the Flask example app.

[adrivn]

I just tried it and yes, it has the same issue. Might have something to do w/ caching/gunicorn?

[nickjj]

We can double check that with https://github.com/nickjj/docker-rails-example if you're up for it, which is the same example app but with Rails. It doesn't use Gunicorn.

[adrivn]

I spin up the rails container and sadly, the CSS watch does not work either.

I went back and within the css container terminal I ran yarn build:css --watch (simultaneously to the one already running), which worked at first run but then subsequent updates did not work.

At this point I think it might have something to do with my system.

Edit: yea I thought so. I'm editing in Vim inside the WSL though, not using windows programs to edit.
microsoft/WSL#4739

[nickjj]

That issue you linked is when you volume mount in files from /mnt/c or any drive from Windows. You mentioned your files exist inside of WSL 2's file system which would be different. This would be independent of your editor btw.

You could still open files in WSL 2 with VSCode, Sublime Text or any other editor that's installed on Windows.