rvs-prxy/Design_Doc/shorter_cmd.md

4.0 KiB

Generic rvs-prxy System Implementation

Overview

This document addresses the implementation of a generic reverse proxy system with simplified command execution. The goal is to provide a more user-friendly approach for setting up reverse proxy services using FRP and Traefik.

Current Commands (After Merging)

The scripts have been merged into a single auto-sys-deploy.sh script, eliminating the need for DOWNLOAD_SOURCE and SCRIPT_PATH:

Linux Commands

  • From cmty-repos2.ivantito.com:

    ssh -i ~/.ssh/itl-devs1 -o StrictHostKeyChecking=accept-new -p 13076 ubuntu@cmty-repos2.ivantito.com "cat /repos/repos/cmptr-infra/rvs-prxy/auto-sys-deploy.sh" bash -s -- setup-rvs-prxy
    
  • From cmty-repos1.ivantito.com:

    ssh -i ~/.ssh/itl-devs1 -o StrictHostKeyChecking=accept-new -p 13072 ubuntu@cmty-repos1.ivantito.com "cat /wws/repos/cmptr-infra/rvs-prxy/auto-sys-deploy.sh" bash -s -- setup-rvs-prxy
    

Simplified Approach: Unified Script

To address the complexity of the current commands, we recommend merging auto-sys-deploy.sh and update-compose-config.sh into a single, comprehensive script called rvs-prxy-setup.sh. This would:

  1. Reduce Command Length: Instead of the long SSH command, users would run:

    curl -s https://raw.githubusercontent.com/owner/repo/main/rvs-prxy-setup.sh | bash -s -- setup-rvs-prxy --service-port 3000 --domain myapp.example.com
    
  2. Simplify Parameter Passing: All configuration options would be available through command-line arguments

  3. Include .env Support: The unified script would support .env files for default values

Proposed Unified Script Features

1. Command-Line Arguments

  • --instance-name: Set the instance name
  • --service-port: Set the internal service port (e.g., 3000)
  • --docker-network: Set the Docker network
  • --frp-server: Set the FRP server address
  • --domain: Set the domain name
  • --env-file: Specify the .env file to use

2. Environment File Support

  • The script will automatically detect and use .env, .env.development, or .env.production
  • Parameters from environment files are used as defaults during script execution
  • Missing parameters will prompt for input
  • Answered parameters are automatically saved to the appropriate .env file for future use

3. Simplified Execution

The unified approach would make the command much shorter and easier to remember:

# Download and execute with minimal parameters
curl -s https://raw.githubusercontent.com/owner/repo/main/rvs-prxy-setup.sh | bash -s -- setup-rvs-prxy --service-port 3000 --domain myapp.example.com

# Or with an existing .env file
curl -s https://raw.githubusercontent.com/owner/repo/main/rvs-prxy-setup.sh | bash -s -- setup-rvs-prxy --env-file .env

Implementation Benefits

1. Reduced Complexity

  • Single script handles both client and proxy configuration
  • Simplified command syntax without requiring DOWNLOAD_SOURCE and SCRIPT_PATH
  • More straightforward execution model

2. Streamlined Workflow

  • Combined functionality of both current scripts
  • Single point of execution for the entire setup process
  • Better error handling and validation

3. Easy Maintenance

  • Unified codebase for easier updates
  • Centralized configuration management
  • Consistent logging and error reporting

Environment File Usage

  • .env files must be created by the end-user on their local computer
  • The file should be in the same directory where the command is executed
  • The unified script will read configuration from the .env file before prompting for input
  • Example .env file:
    INSTANCE_NAME=myapp-3000
    INTERNAL_SERVICE_PORT=3000
    DOCKER_NETWORK=app-network
    FRP_SERVER_ADDR=192.168.1.100
    DOMAIN_NAME=myapp.example.com
    

Future Recommendations

  • Create a GitHub repository with the unified script
  • Provide multiple download methods (curl, wget, direct SSH)
  • Include comprehensive documentation and error handling in the unified script
  • Support for various environments (development, staging, production)