ChrispyBacon-dev/DockFlare v1.7

DockFlare v1.7 Release Notes - Unified Ingress & Manual Rules!

on GitHub

DockFlare v1.7 Release Notes - Unified Ingress & Manual Rules!

I'm excited to announce the release of DockFlare v1.7, a significant update focused on expanding management capabilities and refining the user experience! This version introduces the highly requested Manual Ingress Rule Management, allowing you to bring non-Dockerized internal services under the umbrella of your Cloudflare Tunnel with the same ease as your containerized applications.

✨ New Features

• Manual Ingress Rule Management via UI:
  • Unified View: All managed public hostnames (both Docker-derived and manually added) are now displayed in a single, streamlined "Managed Ingress Rules" table in the Web UI.
  • Add Non-Docker Services: A new "Add Manual Rule" button and modal allow you to easily define public hostnames for services not running in Docker (e.g., your router admin page, Proxmox, NAS UI, internal wikis).
    • Specify hostname, target service URL (e.g., http://192.168.0.1:80, https://internal-server:8443), an optional Cloudflare Zone Name (if different from the global CF_ZONE_ID), and TLS verification settings.
    • DockFlare automatically handles the creation/deletion of the corresponding Cloudflare Tunnel ingress rule and DNS CNAME record.
  • Path Stripping for Services: When adding manual rules, any path included in the service URL (e.g., https://my-service/app/) will be automatically stripped (to https://my-service) for the Cloudflare Tunnel configuration, as Cloudflare expects only the scheme, host, and port. The original path from the user's request will still be passed to your origin service.
• Refined Access Policy Management:
  • Access Policies can now be managed via the UI for both Docker-derived rules and the new Manual Rules, offering the same options (Bypass, Authenticate by Email, Default TLD, etc.).
  • The "Revert" button for UI-set policies on manual rules now clearly indicates it will remove the specific UI policy, making the rule public or subject to a TLD policy.

🎨 UI/UX Enhancements

• Improved Badge Readability: Status badges ("active", "pending deletion", "Manual", "UI Override") in the "Managed Ingress Rules" table are now solid colors (instead of outlines) for much better contrast and readability across all themes.
• Consistent Pulsating Animations (Optional & Configurable):
  • The "Agent Status: running" badge continues to pulsate.
  • The "UI Override" badge now pulsates to draw attention to configurations deviating from label/default settings.
  • The "active" rule status badges are now static solid colors by default for less visual noise.
• Localized Time Display: The "Expires At" column for pending deletions now displays the timestamp in the user's local browser timezone instead of UTC, making it much more intuitive.
• Clearer Rule Identification: The "Identifier" column now explicitly shows "Manual Rule" for manually added entries, distinguishing them from container IDs.

🐛 Bug Fixes & Internal Improvements

• Corrected Ingress Rule Deletion: Resolved a critical bug where deleting a manual rule (and previously, sometimes expired Docker rules) would remove the DNS record and Access Application, but the ingress rule would persist in the Cloudflare Tunnel configuration. The update_cloudflare_config logic is now more assertive, ensuring that rules removed from DockFlare's management are also properly removed from the Cloudflare Tunnel.
• Robust State Handling: The internal source field for rules (docker or manual) is now more consistently managed throughout the application lifecycle (loading, processing, saving state), ensuring accurate differentiation and behavior in reconciliation and cleanup.
• Jinja Template Rendering: Addressed several Jinja2 template syntax and logic errors encountered during development, ensuring smoother page rendering.
• JavaScript Stability: Improved the JavaScript for handling dynamic elements and event listeners related to policy editing, resolving console errors.
• PEP 8 Imports: Standardized Python import order for better code readability and maintainability.

🔧 For Developers & Advanced Users

• The update_cloudflare_config function now takes a more authoritative stance: for the DockFlare-managed tunnel, any non-wildcard, non-catch-all ingress rule found on Cloudflare that is not present in DockFlare's managed_rules (either from Docker labels or manual UI entries) will be removed by DockFlare. This ensures the tunnel configuration accurately reflects DockFlare's intended state. True external wildcards and the API's catch-all rule are still preserved.

⬆️ Upgrading to v1.7

Due to significant improvements in state management and the introduction of the source field for rules, a completely clean state (both on Cloudflare and locally) is strongly recommended for the smoothest upgrade. This ensures all new logic operates from a pristine baseline and avoids potential conflicts. This is especially true if you are coming from a version prior to v1.7 or have experienced any inconsistencies.

Recommended Upgrade Path for a True Fresh Start:

1. Clean Up Existing Cloudflare Configuration:

   • Log in to your Cloudflare Dashboard: https://one.dash.cloudflare.com/
   • Navigate to Zero Trust from the sidebar.
   • In the Zero Trust dashboard, go to Access -> Tunnels.
   • Locate the tunnel previously managed by DockFlare (identified by your TUNNEL_NAME environment variable, e.g., "dockflared-tunnel" or your custom name).
   • Delete this tunnel. This will remove its configuration and associated ingress rules on Cloudflare.
   • Next, navigate to your DNS zone within the main Cloudflare Dashboard (usually by clicking your domain under "Websites"). Review and delete any old CNAME records that were pointing to the now-deleted tunnel's .cfargotunnel.com address. DockFlare v1.7 will recreate these as needed.

2. Stop and Remove your Local DockFlare Instance:
   (If using Docker Compose, navigate to the directory containing your docker-compose.yml file)

   docker compose down 

   (For older docker-compose v1, use docker-compose down)
   (If using docker run, use docker stop your_dockflare_container_name && docker rm your_dockflare_container_name)

3. Important: Back up Local State (Optional - for reference only):
   If you wish to keep a reference of your old state.json (e.g., to remember manual rules you'll need to re-add), you can back it up now. This old state file will not be reused for the clean upgrade.

   • Named Volume (e.g., dockflare_data): Note the content of /app/data/state.json within the volume if needed.
   • Bind Mount: Note the content of ./dockflare-data/state.json on your host if needed.

4. Pull the Latest DockFlare Image:

   docker pull alplat/dockflare:stable

   (You can also optionally remove the old image first with docker rmi alplat/dockflare:stable to ensure a completely fresh image pull.)

5. Purge the Local Docker Volume / Clear Bind Mount (CRITICAL for Clean Start):
   This step removes your old state.json, ensuring DockFlare v1.7 starts without any previous local state.

   • Named Volume (if named dockflare_data as per example docker-compose.yml):

     docker volume rm dockflare_data

     Note: If your docker-compose.yml is part of a project, Docker Compose might have prefixed the volume name (e.g., myproject_dockflare_data). Use docker volume ls to verify the exact name if the command above fails, and then use that exact name in the rm command.
   • Bind Mount: If you used a bind mount (e.g., ./dockflare-data:/app/data), delete the state.json file from your host directory (e.g., rm ./dockflare-data/state.json) or delete the entire host directory if it solely contains DockFlare data.

6. Start DockFlare with the New Image and Clean State:
   (If using Docker Compose)

   docker compose up -d

   (Or re-run your docker run ... command if not using Compose, ensuring your volume/bind mount for /app/data is correctly specified – it will be created fresh if it was a named volume that you removed).

   • DockFlare will start with an empty local state.
   • It will create a new tunnel on Cloudflare (using your TUNNEL_NAME).
   • It will perform its initial scan for Docker containers with labels, populating its rules and creating new ingress rules and DNS records.
   • You will need to re-add any services you wish to manage as "Manual Rules" via the new UI feature.

Why a completely clean state (Cloudflare & local) is recommended for v1.7:
The introduction of the source field ("docker" vs. "manual") and the refined update_cloudflare_config logic represent fundamental changes. Starting fresh ensures the integrity of the new rule management system, avoids potential conflicts from older state files or lingering Cloudflare configurations, and allows the application to establish itself as the authority for its managed tunnel from a known, clean baseline.