
reproxy v1.7.1
경량 에지 HTTP(S) 서버 및 리버스 프록시로, 자동 SSL, Docker/Consul 디스커버리, 경로별 인증, 속도 제한, 상태 확인 기반 장애 조치를 제공합니다.
Reproxy는 다양한 프로바이더(docker, static, file, consul catalog)를 지원하는 간단한 엣지 HTTP(s) 서버 / 리버스 프록시입니다. 하나 이상의 프로바이더가 요청된 서버, 요청된 URL, 대상 URL, 헬스 체크 URL에 대한 정보를 제공합니다. 단일 바이너리 또는 docker 컨테이너로 배포됩니다.
- Let's Encrypt를 이용한 자동 SSL 종료
- 사용자 제공 SSL 인증서 지원
- 간단하지만 유연한 프록시 규칙
- 정적, 명령줄 프록시 규칙 프로바이더
- 동적, 파일 기반 프록시 규칙 프로바이더
- 자동 검색 기능을 갖춘 Docker 프로바이더
- 서비스 태그로 검색하는 Consul Catalog 프로바이더
- 다중 (가상) 호스트 지원
- 선택적 트래픽 압축
- 선택적 IP 기반 접근 제어
- 라우트별 기본 인증
- 사용자 정의 크기 제한 및 타임아웃
- 단일 바이너리 배포
- Docker 컨테이너 배포
- 선택적 "SPA 친화적" 모드를 갖춘 내장 정적 자산 서버
- 리다이렉트 규칙 지원
- 전체 활동 및 사용자 활동에 대한 선택적 제한기
- 실시간 헬스 체크 및 장애 조치/로드 밸런싱
- 라우트 정보와 prometheus 메트릭을 제공하는 관리 서버
- RPC를 통한 플러그인 지원으로 사용자 정의 기능 구현
- Apache Log Format과 간소화된 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" - 자동 docker 검색 사용:
reproxy --docker.enabled --docker.auto - docker 컨테이너로 실행:
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에서 확인하세요
정적 프로바이더
이것은 모든 매핑 규칙을 명령줄(또는 환경 변수)에서 직접 정의하는 가장 간단한 프로바이더입니다. 여러 규칙을 지원합니다. 각 규칙은 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/sec(앞의 위치 필드는 비워둠).
4번째 요소는 헬스 보고에 사용되는 선택적 ping url을 정의합니다. 5번째 요소는 선택적으로 헬스 체크 요청을 백엔드로 전달하는 것을 활성화합니다(true, yes, 1). 자세한 내용은 헬스 체크 섹션을 참조하세요. 6번째 요소는 선택적 라우트별 요청 타임아웃(Go duration, 예: 5m, 30s)입니다. 0 또는 비어 있으면 전역 --timeout.write 설정을 상속합니다. 7번째 요소는 선택적 라우트별 사용자당 req/sec 제한입니다. 0 또는 비어 있으면 --throttle.user를 상속합니다. 빈 위치 필드가 허용됩니다(예: 사용하지 않는 중간 필드에 ,,).
파일 프로바이더
이 프로바이더는 라우팅 규칙이 담긴 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를 설정하여 제공할 수 있습니다:
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 provider
Docker provider는 추가 구성 없이 완전 자동 검색(--docker.auto 사용)을 지원합니다. 기본적으로 http://<url>/<container name>/(.*)와 같은 모든 요청을 해당 컨테이너의 내부 IP와 노출된 포트로 리다이렉트합니다. 활성(실행 중) 컨테이너만 감지됩니다.
이 기본값은 레이블로 변경할 수 있습니다: