vicanso/pingapnginx のようなリバースプロキシ、pingora 上に構築、シンプルで効率的。
pingap のバージョンが安定するまで、プルリクエストは受け付けられません。ご質問がある場合は、まず新しい issue を作成してください。
Pingap は、Cloudflare Pingora を採用した高性能リバースプロキシです。簡潔な TOML ファイルと直感的な Web 管理インターフェースを通じて、動的でダウンタイムゼロの設定ホットリロードを可能にし、運用管理を簡素化します。
その中核となる強みは強力なプラグインシステムにあり、認証 (JWT、Key Auth)、セキュリティ (CSRF、IP/Referer/UA 制限)、トラフィック制御 (レート制限、キャッシュ)、コンテンツ変更 (リダイレクト、コンテンツ置換)、可観測性 (リクエスト ID) のための 20 以上のすぐに使える機能を提供します。これにより Pingap は単なるプロキシではなく、柔軟で拡張可能なアプリケーションゲートウェイとなり、API 保護からモダンな Web アプリケーションのデプロイまで、複雑なシナリオを容易に処理できるよう設計されています。
中文说明 | Documentation · 中文文档 | Examples | Plugins | Crates
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"]
🚀 高性能と信頼性
🔧 動的で使いやすい
🧩 強力な拡張性
📊 モダンな可観測性
{:ja4}、アップストリームヘッダーでは $ja4) により、OpenSSL と rustls のビルドのいずれでも、クライアントをその TLS スタックで識別可能。Pingap を始める最も簡単な方法は Docker Compose を使用することです。
docker-compose.yml ファイルを作成します:# docker-compose.yml
version: '3.8'
services:
pingap:
image: vicanso/pingap:latest # For production, use a specific version like vicanso/pingap:0.12.1-full
container_name: pingap-instance
restart: always
ports:
- "80:80"
- "443:443"
volumes:
# Mount a local directory to persist all configurations and data
- ./pingap_data:/opt/pingap
environment:
# Configure using environment variables
- PINGAP_CONF=/opt/pingap/conf
- PINGAP_ADMIN_ADDR=0.0.0.0:80/pingap
- PINGAP_ADMIN_USER=pingap
- PINGAP_ADMIN_PASSWORD=<YourSecurePassword> # Change this!
command:
# Start pingap and enable hot-reloading
- 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 ビルドを使用PINGAP_TLS=rustls — Linux では、-rustls-full ビルド (rustls TLS バックエンド、すべてのオプション機能、OpenSSL なし) をインストール。TLS バックエンド を参照# Full-featured build
curl -sSL https://raw.githubusercontent.com/vicanso/pingap/main/install.sh | PINGAP_FULL=1 sh
サポート対象: Linux x86_64/arm64、Darwin x86_64/arm64。利用可能なすべてのアセットについては releases ページ を参照してください。
バイナリからの実行を含むより詳細な手順については、ドキュメント をご覧ください。
1 つのコマンドで、ドメインを https で提供し、バックエンドに転送するのに十分です:
# certificate requested from let's encrypt
pingap --domain=pingap.io --upstream=192.168.1.1:3000
# or bring your own certificate
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 で提供します)。リストにないホストへのリクエストには 404 が返されます。
設定は起動のたびに生成されるため、管理 UI から編集することはできません。単一のサーバーを超える用途には --conf を使用してください。これはこれらのフラグと組み合わせることはできません。
Pingap はダウンタイムなしで設定変更に適応するように設計されています。
ホットリロード (--autoreload): アップストリーム、ロケーション、プラグインの更新など、ほとんどの変更では、Pingap は再起動なしで 10 秒以内に新しい設定を適用します。これはコンテナ環境に推奨されるモードです。
グレースフルリスタート (-a または --autorestart): サーバーのリッスンポートの変更など、根本的な変更では、このモードは完全なダウンタイムゼロの再起動を実行し、リクエストが失われないようにします。
ハンドオーバーは時間ベースではなくレディネス駆動です。置換プロセスは -d -u で起動され、リスナーを引き継ぐ準備ができた瞬間にアップグレードソケットの隣の unix ソケットを介して報告し、その後にのみ実行中のプロセスが自身に SIGQUIT を送信します。置換プロセスが終了した場合、そのデーモンが死んだ場合、または basic.restart_ready_timeout (デフォルト 1m) が先に経過した場合、再起動は中止され、実行中のプロセスは提供を続けます。
make dev
Web 管理が必要な場合は、nodejs をインストールして Web アセットをビルドする必要があります。
# generate admin web asset
cd web
npm i
cd ..
make build-web
デフォルトのビルドは、openssl クレートによってソースからコンパイルされた OpenSSL で TLS を終端します。代わりに rustls でビルドするには、OpenSSL のソースビルドを省略します (C コンパイラは依然として必要です。rustls の暗号プロバイダである ring と aws-lc-rs には C とアセンブリが含まれています):
cargo build --release --no-default-features --features tls-rustls
# with the optional features as well
cargo build --release --no-default-features --features tls-rustls,full
rustls ビルドは、サーバーごとの tls_min_version、tls_max_version、tls_cipher_list、tls_ciphersuites 設定を設定検証時 (起動、--test、自動再起動) に拒否します。常に rustls のデフォルト暗号スイートで TLS 1.2 と 1.3 を提供します。管理 UI は、実行中のバイナリが rustls ビルドの場合、これらのフィールドを無効にします。動的 SNI 証明書、自己署名 CA 発行、ACME、アップストリームの ca オプションを含むその他すべては同じように動作します。ビルド済みイメージも同じバリアントを提供します: vicanso/pingap:rustls-full (リリースでは :<version>-rustls-full)、および :latest と :full。アップストリームを検証する際に知っておくべき違いが 1 つあります: rustls (webpki) は CA:TRUE を持つサーバー証明書を拒否しますが、OpenSSL は受け入れます。そのため、手早く openssl req -x509 で自己署名証明書を使用するバックエンドは、アップストリームの ca オプションが信頼できるようにする前に、CA によって署名された適切なリーフ証明書 (または CA フラグのない自己署名リーフ証明書) が必要です。--version (長形式)、起動ログ、管理ホームページはすべて、バイナリがどのバックエンドでビルドされたかを報告します。
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。