
reproxy v1.7.0
경량 에지 HTTP(S) 서버 및 리버스 프록시로, 자동 SSL, Docker/Consul 디스커버리, 경로별 인증, 속도 제한, 상태 확인 기반 장애 조치를 제공합니다.
Reproxy는 다양한 제공자(docker, static, file, consul catalog)를 지원하는 간단한 엣지 HTTP(s) 서버/리버스 프록시입니다. 하나 이상의 제공자가 요청된 서버, 요청 URL, 대상 URL 및 상태 확인 URL에 대한 정보를 제공합니다. 단일 바이너리 또는 도커 컨테이너로 배포됩니다.
- Let's Encrypt를 이용한 자동 SSL 종료
- 사용자 제공 SSL 인증서 지원
- 간단하지만 유연한 프록시 규칙
- 정적, 명령줄 프록시 규칙 제공자
- 동적, 파일 기반 프록시 규칙 제공자
- 자동 검색을 지원하는 Docker 제공자
- 서비스 태그로 검색하는 Consul Catalog 제공자
- 여러 (가상) 호스트 지원
- 선택적 트래픽 압축
- 선택적 IP 기반 액세스 제어
- 경로별 기본 인증
- 사용자 정의 크기 제한 및 시간 제한
- 단일 바이너리 배포
- 도커 컨테이너 배포
- 선택적 "SPA 친화적" 모드가 있는 내장 정적 에셋 서버
- 리디렉션 규칙 지원
- 전체 활동 및 사용자 활동을 위한 선택적 제한기
- 실시간 상태 확인 및 장애 조치/부하 분산
- 경로 정보 및 프로메테우스 메트릭이 포함된 관리 서버
- RPC를 통한 플러그인 지원으로 사용자 정의 기능 구현
- Apache 로그 형식 및 단순화된 stdout 보고서를 모두 지원하는 선택적 로깅.
서버(호스트)는 FQDN(예: s.example.com), *(모든 항목) 또는 정규식으로 설정할 수 있습니다. 정확히 일치하는 경우가 우선 적용되므로, 서버가 example.com과 example\.(com|org)인 두 규칙이 있는 경우 example.com/some/url 요청은 전자와 일치합니다. 요청 URL은 정규식이 될 수 있습니다(예: ^/api/(.*)), 대상 URL에는 정규식 일치 그룹이 포함될 수 있습니다(예: http://d.example.com:8080/$1). 위의 예에서 http://s.example.com/api/something?foo=bar는 http://d.example.com:8080/something?foo=bar로 프록시됩니다.
편의상, 후행 /가 있고 정규식 그룹이 없는 요청은 /(.*)로 확장되고, 이러한 경우의 대상은 /$1로 확장됩니다. 즉, /api/ -> http://127.0.0.1/service는 ^/api/(.*) -> http://127.0.0.1/service/$1로 변환됩니다.
대상 URL에서 호스트 대체가 지원됩니다. 예를 들어 /files/${host}는 일치하는 호스트 이름으로 대체됩니다. $host(중괄호 없음)도 사용할 수 있습니다.
HTTP 및 HTTPS가 모두 지원됩니다. HTTPS의 경우 정적 인증서와 자동화된 ACME(Let's Encrypt) 인증서를 사용할 수 있습니다. 선택적 에셋 서버를 사용하여 정적 파일을 제공할 수 있습니다. reproxy를 시작하려면 최소한 하나의 제공자가 정의되어 있어야 합니다. 나머지 매개변수는 엄격히 선택 사항이며 합리적인 기본값을 가집니다.
예시:
- 정적 제공자 사용:
reproxy --static.enabled --static.rule="*,example.com/api/(.*),https://api.example.com/$1" - 자동 도커 검색 사용:
reproxy --docker.enabled --docker.auto - 도커 컨테이너로 사용:
docker up -p 80:8080 umputun/reproxy --docker.enabled --docker.auto - 자동 SSL 사용:
docker up -p 80:8080 -p 443:8443 umputun/reproxy --docker.enabled --docker.auto --ssl.type=auto --ssl.fqdn=example.com
설치
Reproxy는 작은 자체 포함 바이너리와 도커 이미지로 배포됩니다. 바이너리와 이미지 모두 여러 아키텍처와 여러 운영 체제(linux_x86_64, linux_arm64, linux_arm, macos_x86_64, macos_arm64, windows_x86_64 및 windows_arm 포함)를 지원합니다. 또한 arm64 및 x86 deb 및 rpm 패키지를 제공합니다.
- 바이너리 배포의 경우 릴리스 섹션에서 적절한 파일을 다운로드하십시오.
- Homebrew 사용자:
brew install umputun/apps/reproxy - 도커 컨테이너는 Docker Hub 및 Github Container Registry에서 사용할 수 있습니다. 예:
docker pull umputun/reproxy또는docker pull ghcr.io/umputun/reproxy.
최신 안정 버전에는 :vX.Y.Z 도커 태그(:latest 별칭 포함)가 있으며, 현재 master에는 :master 태그가 있습니다.
제공자
프록시 규칙은 다양한 제공자에 의해 제공됩니다. 현재 포함된 제공자는 file, docker, static 및 consul-catalog입니다. 각 제공자는 프록시 요청 및 정적(에셋)에 대해 여러 라우팅 규칙을 정의할 수 있습니다. 사용자는 동시에 여러 제공자를 설정할 수 있습니다.
다양한 제공자에 대한 예시는 examples에서 확인하세요.
Static 제공자
이것은 모든 매핑 규칙을 명령줄(또는 환경)에서 직접 정의하는 가장 간단한 제공자입니다. 여러 규칙이 지원됩니다. 각 규칙은 쉼표로 구분된 3~7개의 요소 server,sourceurl,destination[,ping-url[,forward-health-checks[,timeout[,throttle]]]]입니다. 예:
*,^/api/(.*),https://api.example.com/$1-/api접두사가 있는 모든 호스트/서버에 대한 요청을https://api.example.com으로 프록시합니다.example.com,/foo/bar,https://api.example.com/zzz,https://api.example.com/ping-example.com에 대한 모든 요청과/foo/barURL을https://api.example.com/zzz로 프록시하고 상태 확인을 위해https://api.example.com/ping을 사용합니다.example.com,/foo/bar,https://api.example.com/zzz,https://api.example.com/ping,true- 위와 동일하지만/ping및/health요청도 백엔드로 전달합니다.example.com,^/upload/(.*),https://api.example.com/$1,,,5m- 경로별 요청 시간 제한 5분(4번째 및 5번째 필드는 ping-url 및 forward-health-checks를 건너뛰기 위해 비워둠).example.com,^/login,https://api.example.com/login,,,,2- 사용자당 경로별 제한 2 req/초(이전 위치 필드는 비워둠).
4번째 요소는 상태 보고에 사용되는 선택적 ping URL을 정의합니다. 5번째 요소는 선택적으로 상태 확인 요청을 백엔드로 전달하는 기능을 활성화합니다(true, yes, 1). 자세한 내용은 상태 확인 섹션을 참조하십시오. 6번째 요소는 선택적 경로별 요청 시간 제한(Go 기간, 예: 5m, 30s)입니다. 0 또는 비어 있으면 전역 --timeout.write 설정을 상속합니다. 7번째 요소는 선택적 사용자당 req/초 제한입니다. 0 또는 비어 있으면 --throttle.user를 상속합니다. 빈 위치 필드가 허용됩니다(예: 사용되지 않는 중간 필드에 대해 ,,).
File 제공자
이 제공자는 라우팅 규칙이 포함된 yaml 파일을 사용합니다.
reproxy --file.enabled --file.name=config.yml
config.yml 예시:
default: # the same as * (catch-all) server
- { route: "^/api/svc1/(.*)", dest: "http://127.0.0.1:8080/blah1/$1" }
- {
route: "/api/svc3/xyz",
dest: "http://127.0.0.3:8080/blah3/xyz",
ping: "http://127.0.0.3:8080/ping",
remote: "192.168.1.0/24, 127.0.0.1", # optional, restrict access to the route
forward-health-checks: true # optional, forward /ping and /health to backend
}
- {
route: "^/admin/(.*)",
dest: "http://127.0.0.4:8080/$1",
auth: "admin:$2y$05$..." # optional, per-route basic auth (htpasswd bcrypt format)
}
- {
route: "^/upload/(.*)",
dest: "http://127.0.0.5:8080/$1",
timeout: 5m # optional, per-route request timeout (Go duration). 0 or omitted inherits --timeout.write
}
- {
route: "^/login",
dest: "http://127.0.0.6:8080/login",
throttle: 2 # optional, per-route req/sec per user. 0 or omitted inherits --throttle.user
}
srv.example.com:
- { route: "^/api/svc2/(.*)", dest: "http://127.0.0.2:8080/blah2/$1/abc" }
- { route: "/web/", dest: "/var/www", "assets": true }
"*.files.example.com":
- { route: "^/files/(.*)", dest: "http://123.123.200.200:8080/$host/$1" }
```
이것은 동적 제공자이며 파일 변경이 자동으로 적용됩니다.
**여러 도메인의 여러 정적 사이트**를 `assets: true`와 함께 서버 이름을 키로 사용하여 제공할 수 있습니다:```yaml
site-en.example.com:
- { route: "/", dest: "/var/www/en", "assets": true }
site-ru.example.com:
- { route: "/", dest: "/var/www/ru", "assets": true }
```
**중요:** 에셋 규칙의 `route` 필드는 경로 접두사(예: `/`, `/web/`)여야 하며, 정규식이 아니어야 합니다. `^/(.*)`와 같은 정규식 패턴은 `assets: true`에서 작동하지 않습니다. 정적 에셋 매칭은 정규식이 아닌 경로 접두사 비교를 사용하기 때문입니다.
### Docker 제공자
Docker 제공자는 추가 구성 없이 완전 자동 검색(`--docker.auto`)을 지원합니다. 기본적으로 모든 요청 `http://<url>/<컨테이너 이름>/(.*)`을 해당 컨테이너의 내부 IP와 노출된 포트로 리디렉션합니다. 활성(실행 중인) 컨테이너만 감지됩니다.
기본 동작은 라벨을 통해 변경할 수 있습니다:
```