vicanso/pingapnginx のようなリバースプロキシ、pingora 上に構築、シンプルで効率的。
pingapのバージョンが安定するまでは、プルリクエストは受け付けられません。質問がある場合は、まず新しいIssueを作成してください。
Pingapは、Cloudflare Pingora を採用した高性能リバースプロキシです。簡潔なTOMLファイルと直感的なWeb管理インターフェースにより、動的でダウンタイムのない設定のホットリロードを実現し、運用管理を簡素化します。
その中核的な強みは、強力なプラグインシステムにあり、認証（JWT、キー認証）、セキュリティ（CSRF、IP/Referer/UA制限）、トラフィック制御（レート制限、キャッシング）、コンテンツ変更（リダイレクト、コンテンツ置換）、および可観測性（リクエストID）など、20以上のすぐに使える機能を提供します。これにより、Pingapは単なるプロキシではなく、柔軟で拡張可能なアプリケーションゲートウェイとなり、API保護から最新のWebアプリケーション展開まで、複雑なシナリオを簡単に処理できるように設計されています。
中文说明 | ドキュメント · 中文文档 | 例 | プラグイン | クレート
flowchart LR
internet("Internet") -- request --> pingap["Pingap"]
pingap -- proxy:pingap.io/api/* --> apiUpstream["10.1.1.1,10.1.1.2"]
pingap -- proxy:cdn.pingap.io --> cdnUpstream["10.1.2.1,10.1.2.2"]
pingap -- proxy:/* --> upstream["10.1.3.1,10.1.3.2"]
🚀 高性能と信頼性
🔧 動的で使いやすい
🧩 強力な拡張性
📊 最新の可観測性
Pingapを始める最も簡単な方法は、Docker Composeを使用することです。
docker-compose.ymlファイルを作成します:# docker-compose.yml
version: '3.8'
services:
pingap:
image: vicanso/pingap:latest # 本番環境ではvicanso/pingap:0.12.1-fullなどの特定バージョンを使用
container_name: pingap-instance
restart: always
ports:
- "80:80"
- "443:443"
volumes:
# すべての設定とデータを永続化するためにローカルディレクトリをマウント
- ./pingap_data:/opt/pingap
environment:
# 環境変数による設定
- PINGAP_CONF=/opt/pingap/conf
- PINGAP_ADMIN_ADDR=0.0.0.0:80/pingap
- PINGAP_ADMIN_USER=pingap
- PINGAP_ADMIN_PASSWORD=<YourSecurePassword> # 変更してください！
command:
# pingapを起動し、ホットリロードを有効化
- pingap
- --autoreload
mkdir pingap_data
docker-compose up -d
Pingapインスタンスが起動しました！設定した認証情報を使用して、http://localhost/pingap でWeb管理インターフェースにアクセスできます。
LinuxおよびmacOSでは、以下のコマンド1つで最新のプリビルドバイナリを/usr/local/bin/pingapにインストールできます:
curl -sSL https://raw.githubusercontent.com/vicanso/pingap/main/install.sh | sh
オプションの環境変数:
PINGAP_FULL=1 — -fullビルド（すべてのオプション機能が有効）をインストールPINGAP_LIBC=gnu — Linuxでは、デフォルトのmusl静的ビルドの代わりにglibcビルドを使用# フル機能ビルド
curl -sSL https://raw.githubusercontent.com/vicanso/pingap/main/install.sh | PINGAP_FULL=1 sh
サポート対象: Linux x86_64/arm64, Darwin x86_64/arm64。利用可能なすべてのアセットについてはリリースページを参照してください。
バイナリからの実行を含むより詳細な手順については、ドキュメントを参照してください。
単一のコマンドでドメインをHTTPSで提供し、バックエンドに転送できます:
# let's encryptから証明書を要求
pingap --domain=pingap.io --upstream=192.168.1.1:3000
# または独自の証明書を使用
pingap --domain=pingap.io --upstream=192.168.1.1:3000 --cert=/etc/ssl/pingap.io
--certがない場合、PingapはHTTP-01チャレンジを通じてLet's Encryptに証明書を要求するため、pingap.ioはこのホストに解決され、ポート80がインターネットから到達可能である必要があります。発行された証明書は~/.pingap/acme/<domains>.tomlに保存され、再起動時に再利用されます。発行にはレート制限があるため、削除しないでください。その他すべてはコマンドラインから指定します。--upstreamを変更すると、証明書に影響を与えずに次回起動時に有効になります。
--certは証明書自体、またはそれを含むディレクトリを受け入れます。一般的なfullchain.pem/privkey.pem、cert.pem/key.pem、tls.crt/tls.keyのレイアウトは自動的に検出されます。それ以外の場合は--keyを使用します。リスナーは、証明書がある場合はデフォルトで0.0.0.0:443、証明書もドメインもない場合は0.0.0.0:80になり、--addrで上書きできます。--upstreamはカンマ区切りのバックエンドリスト、--domainはカンマ区切りのホストリストです（省略すると、すべてのホストをプレーンHTTPで提供します）。
設定は起動のたびに生成されるため、管理UIから編集できません。単一サーバーを超える場合は--confを使用しますが、これらのフラグと組み合わせることはできません。
Pingapは、ダウンタイムなく設定変更に適応できるように設計されています。
Hot Reload (--autoreload): ほとんどの変更（アップストリーム、ロケーション、プラグインの更新など）に対して、Pingapは再起動せずに10秒以内に新しい設定を適用します。これはコンテナ環境に推奨されるモードです。
Graceful Restart (-a or --autorestart): 基本的な変更（サーバーのリッスンポートの変更など）に対して、このモードは完全なダウンタイムのない再起動を実行し、リクエストがドロップされないようにします。
make dev
Web管理が必要な場合は、nodejsをインストールしてWebアセットをビルドする必要があります。
# 管理Webアセットを生成
cd web
npm i
cd ..
make build-web
server "test" {
addr = "127.0.0.1:6118"
location "github-api" {
path = "/api"
proxy_set_headers = ["Host:api.github.com"]
rewrite = "^/api/(?<path>.+)$ /$1"
upstream "api" {
addrs = ["api.github.com:443"]
discovery = "dns"
sni = "api.github.com"
}
}
location "static" {
plugin "staticServe" {
category = "directory"
path = "~/Downloads"
step = "request"
}
}
}
[upstreams.api]
addrs = ["api.github.com:443"]
discovery = "dns"
sni = "api.github.com"
[plugins.staticServe]
category = "directory"
path = "~/Downloads"
step = "request"
[locations.github-api]
upstream = "api"
path = "/api"
proxy_set_headers = ["Host:api.github.com"]
rewrite = "^/api/(?<path>.+)$ /$1"
[locations.static]
plugins = ["staticServe"]
[servers.test]
addr = "127.0.0.1:6118"
locations = ["github-api", "static"]
関連する手順はこちら: https://pingap.io/crates/config
graph TD;
server["HTTP Server"];
locationA["Location A"];
locationB["Location B"];
locationPluginListA["Proxy Plugin List A"];
locationPluginListB["Proxy Plugin List B"];
upstreamA1["Upstream A1"];
upstreamA2["Upstream A2"];
upstreamB1["Upstream B1"];
upstreamB2["Upstream B2"];
locationResponsePluginListA["Response Plugin List A"];
locationResponsePluginListB["Response Plugin List B"];
start("New Request") --> server
server -- "host:HostA, Path:/api/*" --> locationA
server -- "Path:/rest/*"--> locationB
locationA -- "Exec Proxy Plugins" --> locationPluginListA
locationB -- "Exec Proxy Plugins" --> locationPluginListB
locationPluginListA -- "proxy pass: 10.0.0.1:8001" --> upstreamA1
locationPluginListA -- "proxy pass: 10.0.0.2:8001" --> upstreamA2
locationPluginListA -- "done" --> response
locationPluginListB -- "proxy pass: 10.0.0.1:8002" --> upstreamB1
locationPluginListB -- "proxy pass: 10.0.0.2:8002" --> upstreamB2
locationPluginListB -- "done" --> response
upstreamA1 -- "Exec Response Plugins" --> locationResponsePluginListA
upstreamA2 -- "Exec Response Plugins" --> locationResponsePluginListA
upstreamB1 -- "Exec Response Plugins" --> locationResponsePluginListB
upstreamB2 -- "Exec Response Plugins" --> locationResponsePluginListB
locationResponsePluginListA --> response
locationResponsePluginListB --> response
response["HTTP Response"] --> stop("Logging");
CPU: M4 Pro, スレッド: 1
wrk 'http://127.0.0.1:6118/ping' --latency
Running 10s test @ http://127.0.0.1:6118/ping
2 threads and 10 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 66.41us 23.67us 1.11ms 76.54%
Req/Sec 73.99k 2.88k 79.77k 68.81%
Latency Distribution
50% 67.00us
75% 80.00us
90% 91.00us
99% 116.00us
1487330 requests in 10.10s, 194.32MB read
Requests/sec: 147260.15
Transfer/sec: 19.24MB
現在のMSRVは1.88です。
このプロジェクトはApache License, Version 2.0の下でライセンスされています。