Standardize to single non-root Dockerfile

[chungyau97]

Description

This PR will replace #5495.
Standardizes the project to use a single non-root Dockerfile instead of maintaining multiple Dockerfiles.

Manual Data Migration from ~/.flowise to flowise_data

# Create temporary container with the volume
docker create --name temp-flowise -v docker_flowise_data:/home/node/.flowise node:20-alpine

# Copy data
Linux/Mac: docker cp ~/.flowise/. temp-flowise:/home/node/.flowise/
Win: docker cp C:\Users\[YOUR_COMPUTER_NAME]\.flowise\. temp-flowise:/home/node/.flowise/

# Fix permissions
docker run --rm -v docker_flowise_data:/data node:20-alpine chown -R node:node /data

# Remove temporary container
docker rm temp-flowise

Result

Enterprise Test

Test with image publish to Docker Hub flowiseaiyau/test

Initialization with old docker-compose.yml	flowiseaiyau/test:0.0.2 with new docker-compose.yml

Enterprise Queue Mode Test

Test with image publish to Docker Hub flowiseaiyau/test

flowiseaiyau/test:0.0.2 with new docker-compose-queue-prebuilt.yml Conversation Chain	flowiseaiyau/test:0.0.2 with new docker-compose-queue-prebuilt.yml Conversational Retrieval QA Chain Upsert	flowiseaiyau/test:0.0.2 with new docker-compose-queue-prebuilt.yml Conversational Retrieval QA Chain Chat

Cloud Test

Test with image publish to Cloud Staging ECR

Conversation Chain	Conversational Retrieval QA Chain Upsert	Conversational Retrieval QA Chain Chat

[gemini-code-assist]

Summary of Changes

Hello @chungyau97, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request focuses on improving the security posture of the Docker environment by standardizing the application to run as a non-root user. It involves updating critical file paths within the container and adjusting the application's startup command to align with this more secure configuration, ensuring a consistent and safer deployment strategy.

Highlights

• Non-Root User Standardization: All internal Docker paths for database, secret keys, logs, and blob storage have been updated from /root/.flowise to /home/node/.flowise, ensuring the application runs as a non-root user for enhanced security.
• Application Startup Command Update: The Docker Compose entrypoint has been modified to use pnpm start instead of flowise start, indicating a change in how the application is initiated within the container.
• Docker Image Reference Change: The Docker image in docker-compose.yml has been updated to flowiseaiyau/test:latest, likely for testing purposes by the author.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request standardizes the Docker configuration to use a single non-root user, which is a great improvement for security. The changes in .env.example and docker-compose.yml correctly reflect the new user's home directory. However, the docker-compose.yml file points to a temporary test image. This must be corrected before merging to ensure the correct image is used in deployments.

[gemini-code-assist]

The Docker image is set to a test image (flowiseaiyau/test:latest). This should be changed back to the official image, likely flowiseai/flowise:latest, before this PR is merged to avoid deploying a potentially unstable or incorrect version.

        image: flowiseai/flowise:latest

[chungyau97]

Remember to change this back to flowiseai/flowise:latest.

[chungyau97]

Remember to change this back to flowiseai/flowise:latest.

[chungyau97]

Remember to change this back to flowiseai/flowise:latest.

[HenryHengZJ]

Here's another idea:

1. Container starts as root (needed for migration)
2. Entrypoint script checks if /root/.flowise has data:

#!/bin/sh
set -e

OLD_DIR="/root/.flowise"
NEW_DIR="/home/node/.flowise"

# If old directory exists and has content, and new directory doesn't exist or is empty
if [ -d "$OLD_DIR" ] && [ "$(ls -A $OLD_DIR 2>/dev/null)" ] && [ ! -d "$NEW_DIR" -o ! "$(ls -A $NEW_DIR 2>/dev/null)" ]; then
    echo "Migrating data from $OLD_DIR to $NEW_DIR..."
    
    # Create new directory if it doesn't exist
    mkdir -p "$NEW_DIR"
    
    # Copy all data from old to new location
    cp -rp "$OLD_DIR"/* "$NEW_DIR"/ 2>/dev/null || true
    
    # Fix ownership for node user
    chown -R node:node "$NEW_DIR"
    
    echo "Migration complete!"
else
    # Ensure the new directory exists with correct permissions
    mkdir -p "$NEW_DIR"
    chown -R node:node "$NEW_DIR"
fi

# Switch to node user and run flowise
exec su-exec node flowise start "$@"

4. If yes, it copies data to /home/node/.flowise and fixes permissions
5. Script then uses su-exec to switch to node user before running flowise
6. Application runs as non-root node user with access to migrated data

However, if we were to simplify to using 1 root Dockerfile, we have to consider the scenario where majority of the users are still using the old docker-compose.yml with the entrypoint: /bin/sh -c "sleep 3; flowise start. This will break since the root Dockerfile is now using pnpm start not flowise start.

We need to find a way that has backward compatibility

• Simplifying to 1 Dockerfile
• Running as non-root user
• Automatic migration from old to new location
• Make sure it doesnt break even if user is still using the same docker-compose.yml

Extra: We should also look at Dockerfile at docker/worker directory.

TLDR: a much bigger effort is needed to revamp the strategy of Docker implementation, making sure it is backward compatible, and battle tested on major cloud providers. This is a huge change with big impact.

Note: /root/.flowise can be configured to other path, so we cant hardcode that into the entrypoint