QueryProxy’yi doğrudan bir sunucuda mı çalıştırmak istiyorsunuz? Standart bir Laravel uygulamasıdır.

Gereksinimler

Proxy’leyeceğiniz veritabanlarının PDO sürücüleriyle birlikte PHP ≥ 8.3 (pdo_pgsql, pdo_mysql, pdo_sqlite; SQL Server hedefleri için pdo_sqlsrv)
Composer
Node.js 20.19+ ya da 22.12+ (yalnızca frontend varlıklarını derlemek için; sabitlenmiş Vite 8’in istediği sürümler)

Adımlar

git clone https://github.com/QueryProxy/QueryProxy.git
cd QueryProxy

composer install
cp .env.example .env
php artisan key:generate

touch database/database.sqlite
php artisan migrate            # demo takım için --seed ekleyin
php artisan queryproxy:create-admin   # ilk yönetici (demo takımı tohumladıysanız atlayın)

npm install && npm run build

Ardından üç süreci çalıştırın:

php artisan serve                                                        # web portalı (http://localhost:7432)
php artisan queue:work --queue=queries,default --tries=1 --timeout=310   # işçi; --timeout = QUERYPROXY_EXECUTION_TIMEOUT + 10 (varsayılan 300)
php artisan schedule:work                                                # zamanlayıcı

Kuyruk işçisi opsiyonel değildir. Onaylanan sorgular asla bir web isteği içinde değil, işçide çalışır. İşçi çalışmıyorsa talepler onaylanır ve sonsuza dek kuyrukta bekler. Üretimde işçiyi bir süreç yöneticisiyle (systemd, Supervisor) ayakta tutun ve --timeout değerini QUERYPROXY_EXECUTION_TIMEOUT değerinin biraz üzerinde ayarlayın. Bu değerin üst sınırı 86400 saniyedir: bunu aşan geçerli bir sayı hata vermez, 86400’e kırpılır. Docker girişi kırptığında [entrypoint] uyarısı basar; manuel kurulumda uygulama sessizce kırpar, bu yüzden --timeout değerini kırpılmış değerle tutarlı tutun (86400 + 10).

retry_after uyarısı (çalıştırma zaman aşımına eşit ya da altında olması) queue:work başlarken loglanır; queue:work --once ve queue:listen için de loglanır. İşçiyi deponun Compose örneğinden çalıştırıyorsanız --timeout değeri imaj girişinden gelir (QUERYPROXY_EXECUTION_TIMEOUT + 10); manuel kurulumda sayıyı kendiniz belirlersiniz.

Üretim notları

Uygulamayı, TLS’li gerçek bir web sunucusunun (nginx, Caddy) arkasında PHP-FPM üzerinden sunun; php artisan serve yalnızca deneme içindir. Resmi Docker imajı zaten nginx + php-fpm’i root olmayan bir kullanıcıyla çalıştırır — manuel kurulumda da bunu örnek alın. TLS’i sonlandıran bir vekil arkasındayken SESSION_SECURE_COOKIE=true ayarlayın.
QueryProxy’nin önünde bir vekil olduğunda TRUSTED_PROXIES’i vekilinizin IP’sine ya da CIDR’ına ayarlayın. Hiçbir vekile varsayılan olarak güvenilmez; bu yüzden o zamana kadar X-Forwarded-Proto yok sayılır (HTTPS algılanmaz, HSTS başlığı yok) ve denetim kayıtlarına istemcinin değil vekilin adresi düşer. Asla * kullanmayın. APP_URL’i kullanıcıların gerçekten eriştiği adrese ayarlayın — istek host’u ona sabitlenir. Bkz. Yapılandırma.
QUERYPROXY_RESULT_DISK’i özel bir diskte tutun. Herkese açık görünürlükte bir diske işaret ediyorsa QueryProxy sonuç yazmayı reddeder; sonuç yolları tahmin edilebilir olduğu için böyle bir disk indirme yetkilendirmesini tümden atlatır.
APP_KEY’i açıkça belirleyin ve dağıtımlar boyunca sabit tutun. Bu anahtar, saklanan bağlantı kimlik bilgilerinizi ve chat sırlarınızı şifreler; yeniden üretilen bir anahtar bunları okunamaz kılar. Anahtarları APP_PREVIOUS_KEYS ile döndürün ki mevcut şifreli veri hâlâ çözülebilsin.
SQLite yetmediğinde DB_* değişkenlerini MySQL veya PostgreSQL’e yönlendirin — bkz. Yapılandırma.
Zamanlayıcı, sonuç saklama temizliğini yürütür; schedule:work ile ya da her dakika php artisan schedule:run çağıran bir cron girdisiyle çalıştırın.
Dağıtımda yapılandırmayı önbelleğe alın: php artisan config:cache && php artisan route:cache. TRUSTED_PROXIES ve TRUSTED_HOSTS yapılandırma üzerinden okunur, bu yüzden .env’e yazmak yeterlidir — değiştirdikten sonra config:cache’i yeniden çalıştırın.