# 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 Complex Commands
The current approach requires complex commands that are difficult to remember and execute:

### Linux Commands
- **From cmty-repos2.ivantito.com:**
  ```bash
  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:**
  ```bash
  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
  ```

## Important Prerequisites

### 1. Service Computer Requirement
- The script runs on the **same computer** as the service it connects to
- Make sure the internal service is running and accessible on the specified port
- Both the script and the target service must be running on the same physical/virtual machine

### 2. Docker Network Configuration
- If using Docker containers, ensure they are on the same network
- The script will use `127.0.0.1` to connect to the internal service
- For container-to-container communication, use appropriate Docker networking

### 3. Environment File Requirement
- End-user must prepare the `.env` file (or `.env.development`) in advance
- The file should contain all necessary configuration parameters
- Example `.env.development`:
  ```
  INSTANCE_NAME=myapp-3000
  INTERNAL_SERVICE_PORT=3000
  DOCKER_NETWORK=app-network
  FRP_SERVER_ADDR=192.168.1.100
  DOMAIN_NAME=myapp.example.com
  ```

## Script Download and Execution

### Method 1: SSH Download and Run
The script can be executed by downloading it via SSH:
```bash
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
```

### Method 2: Direct Execution
If running locally after copying the script:
```bash
./auto-sys-deploy.sh setup-rvs-prxy
```

## Environment File Support

### 1. Automatic Loading
- The script automatically loads from `.env.development` (highest priority)
- Falls back to `.env.production` or `.env` if development file not found
- Also checks in the script's directory if not found in current directory

### 2. Variable Persistence
- If variables are missing from the environment file, the script will prompt for them
- Answered values are automatically saved back to the appropriate .env file
- This ensures values persist for future runs

### 3. Supported Variables
- `INSTANCE_NAME`: Name for the service instance (container and volume names will be {INSTANCE_NAME}-frpc)
- `INTERNAL_SERVICE_PORT`: Port on which the local service is running (e.g., 3000)
- `DOCKER_NETWORK`: Docker network name (if applicable)
- `FRP_SERVER_ADDR`: FRP server IP address
- `FRP_SERVER_PORT`: FRP server port (default 16999)
- `DOMAIN_NAME`: Domain name for routing
- `RAD_REMOTE_PORT`: Remote port for rad proxy (if specified)
- `SSH_REMOTE_PORT`: Remote port for SSH proxy (if specified)
- `WEB_REMOTE_PORT`: Remote port for web proxy (if specified)
- `PROXY_*_PORT`: Dynamic proxy configuration (e.g., `PROXY_API_PORT=8080`, `PROXY_DATABASE_PORT=5432`)
- `PROXY_*_LOCAL_PORT`: Local port for the corresponding proxy (e.g., `PROXY_API_LOCAL_PORT=8000`)
- The script creates as many proxies as defined by the environment variables

## Benefits of Current Approach

### 1. Same-Computer Execution
- The script runs on the same computer as the service
- No need to pass complex parameters across network boundaries
- Direct access to local services via 127.0.0.1

### 2. Simplified Configuration
- All configuration via environment files
- No complex command-line parameter passing
- Easy to maintain different configurations for different environments

### 3. Streamlined Workflow
- Single execution point: SSH download and run
- Automatic environment loading
- Consistent configuration management