fix: Resolve docker-dev build failures for arm64 and macOS

[3Sangeetha3]

Fixes #640

This PR addresses multiple issues that were causing the make docker-dev command to fail for users on arm64 (Apple Silicon) machines.

1. Fixes Puppeteer/Chromium Build Failure

• Problem: The build failed during yarn install because puppeteer could not find a pre-built arm64 Linux binary for Chromium.
• Solution: This PR adds a RUN apt-get update && apt-get install -y chromium step to the Dockerfile-dev to install the required binary before yarn install is run.

2. Fixes Missing Python 'venv' Error

• Problem: The build failed a second time because the make install-deps-python command checks for a ./venv directory that hadn't been created.
• Solution: Added python3 -m venv venv to the Dockerfile to create the virtual environment before the make command is called.

3. Resolves macOS Port Conflict

• Problem: Running the container with make docker-dev-run failed with an "address already in use" error, as port 5000 is often used by the macOS AirPlay Receiver.
• Solution: Updated the docker-dev-run target in the Makefile to map to port 5001 on the host (-p 5001:5000) to avoid this common conflict.

With these changes, users on arm64/macOS can successfully build and run the development container.

[northdpole]

Thanks for the contribution! Just a couple comments and this is ready

[3Sangeetha3]

@northdpole Thanks for the feedback! I've investigated the --host=0.0.0.0 concern and made changes to address the security implications while keeping the Docker setup functional.

The Problem

Without --host=0.0.0.0, Flask binds to 127.0.0.1 inside the container, which means it only accepts connections from within the container itself. Even with -p 5000:5000 (or -p 5001:5000), the host machine cannot reach the Flask server because it's not listening on the container's Docker bridge interface. This results in ERR_CONNECTION_RESET when trying to access http://localhost:5000 from the browser.

Why This Happens

Docker containers have their own isolated network namespace. When Flask binds to 127.0.0.1 inside the container:

• It only listens on the container's loopback interface
• The Docker port mapping cannot forward traffic to it
• The host machine gets connection refused/reset errors

To make the containerized app accessible, Flask must bind to 0.0.0.0 (all interfaces) inside the container so it can accept connections through the Docker bridge network.

The Solution

I've created a separate Make target specifically for Docker:

dev-flask-docker:
    . ./venv/bin/activate && INSECURE_REQUESTS=1 FLASK_APP=`pwd`/cre.py  FLASK_CONFIG=development flask run --host=0.0.0.0

And updated the Dockerfile to use this target:
ENTRYPOINT make dev-flask-docker

The original dev-flask target remains unchanged and continues to use 127.0.0.1 for local development outside Docker.

Why This is secure

I understand the concern about 0.0.0.0, but in this Docker context, it's actually safe. Here's why:

The container's 0.0.0.0 is isolated — it's only binding to all interfaces inside the container's own network namespace, not on your actual machine.

We're explicitly mapping to localhost — The -p 127.0.0.1:5001:5000 in the docker run command ensures the app is only accessible from your local machine, not from other devices on your network.

If there are any additional security improvements needed, please let me know and review the changes.