Secure Gateway

Secure Gateway उन routes को proxy करता है जिन्हें Roboflow Deployment servers को आपकी कंपनी के DMZ में चाहिए, और model weights तथा container images को स्थानीय रूप से cache करता है।

Secure Gateway, Roboflow Inference Server को इंटरनेट से फ़ायरवॉल करने पर, Roboflow API और आपके मॉडलों के वज़न के लिए एक प्रॉक्सी है। यह इसका उत्तराधिकारी है License Server और मॉडल वज़न तथा कंटेनर इमेजों की स्थानीय कैशिंग जोड़ता है, ताकि इन्फ़रेंस सर्वरों का एक बेड़ा आउटबाउंड ट्रैफ़िक के एक ही नियंत्रित बिंदु को साझा करे।

यह पेज मूल बातें कवर करता है। पूर्ण कॉन्फ़िगरेशन और संचालन संदर्भ के लिए, देखें Secure Gateway मैनुअल.

पूर्वापेक्षाएँ

• Docker Engine 20.10+, या Kubernetes v1.24+

• एक होस्ट जिसकी पहुँच api.roboflow.com और repo.roboflow.com तक हो

• पोर्ट 80 उपलब्ध हो, और TLS का समापन गेटवे के सामने एक लोड बैलेंसर पर या कंटेनर के अंदर हो

• 4GB+ मेमोरी

• कैश के लिए एक S3 bucket, या 50GB+ स्थानीय डिस्क

Secure Gateway का उपयोग करना

ऐसी मशीन पर जिसकी पहुँच हो https://api.roboflow.com और https://repo.roboflow.com (और पोर्ट 80 जो आपकी निजी नेटवर्क में चल रहे Inference Server के लिए खुला हो), Secure Gateway कंटेनर खींचें:

docker pull repo.roboflow.com/roboflow-edge/secure-gateway:latest

यह latest टैग सबसे हालिया रिलीज़ को ट्रैक करता है। प्रोडक्शन के लिए, और खासकर air-gapped deployments के लिए, इसके बजाय एक विशिष्ट संस्करण को पिन करें ताकि अपग्रेड जानबूझकर और पुनरुत्पादन योग्य रहें, उदाहरण के लिए repo.roboflow.com/roboflow-edge/secure-gateway:0.2.0.

इसे स्थानीय डिस्क कैश के साथ चलाएँ:

docker run -d --name secure-gateway -p 80:80 --restart unless-stopped \
    -v gateway-cache:/var/cache/secure-gateway \
    repo.roboflow.com/roboflow-edge/secure-gateway:latest

सुनिश्चित करें कि यह चल रहा है:

curl http://localhost/health

स्थानीय डिस्क के बजाय S3 पर कैश करने के लिए, सेट करें CACHE_S3_BUCKET और CACHE_S3_REGION environment variables. किसी instance या IAM role का उपयोग करने के लिए credentials को unset छोड़ दें।

TLS प्रमाणपत्र

डिफ़ॉल्ट रूप से गेटवे साधारण HTTP पर सुनता है, और आप इसके सामने एक लोड बैलेंसर पर TLS का समापन करते हैं। गेटवे से ही HTTPS सर्व करने के लिए, अपना प्रमाणपत्र और निजी कुंजी कंटेनर में माउंट करें और दोनों सेट करें TLS_CERT_FILE और TLS_KEY_FILE. फिर गेटवे अपने कॉन्फ़िगर किए गए पोर्ट पर HTTPS सर्व करता है:

docker run -d --name secure-gateway -p 443:443 --restart unless-stopped \
    -e PORT=443 \
    -e TLS_CERT_FILE=/etc/ssl/certs/gateway.crt \
    -e TLS_KEY_FILE=/etc/ssl/private/gateway.key \
    -v /path/to/certs:/etc/ssl:ro \
    -v gateway-cache:/var/cache/secure-gateway \
    repo.roboflow.com/roboflow-edge/secure-gateway:latest

दोनों TLS_CERT_FILE और TLS_KEY_FILE इनबाउंड HTTPS सक्षम करने के लिए आवश्यक हैं, और प्रत्येक एक PEM-encoded फ़ाइल की ओर संकेत करता है।

जब गेटवे का आउटबाउंड ट्रैफ़िक Zscaler जैसे किसी कॉर्पोरेट TLS inspection proxy से होकर गुजरे, तब सेट करें TLS_CA_BUNDLE को उस proxy के CA bundle पर ताकि गेटवे api.roboflow.com और repo.roboflow.com के साथ अपने कनेक्शनों पर भरोसा करे:

-e TLS_CA_BUNDLE=/etc/ssl/certs/corporate-ca.pem

Inference Servers को जोड़ना

प्रत्येक Inference Server को गेटवे की ओर निर्देशित करें, इसके साथ SECURE_GATEWAY environment variable. इसे गेटवे के hostname या IP address पर सेट करें, बिना किसी scheme के। तब Inference Server अपनी Roboflow API calls और model weight downloads को सीधे इंटरनेट तक पहुँचने के बजाय गेटवे के माध्यम से रूट करता है।

sudo docker run --net=host \
    --env SECURE_GATEWAY=10.0.1.1 \
    roboflow/inference-server:cpu

यदि गेटवे पोर्ट 80 के अलावा किसी और पोर्ट पर सुनता है, तो उसे शामिल करें, उदाहरण के लिए SECURE_GATEWAY=10.0.1.1:8080. Inference Server इस पते पर HTTP के माध्यम से गेटवे से जुड़ता है, इसलिए पुष्टि करें कि host और port Inference Server के नेटवर्क से पहुँच योग्य हैं।

केवल गेटवे को api.roboflow.com और repo.roboflow.com तक outbound access की आवश्यकता होती है। Inference Server शुरू होने के बाद, एक मॉडल चलाएँ और पुष्टि करें कि अनुरोध गेटवे के access logs में दिखाई दें।

विरासती LICENSE_SERVER वेरिएबल अभी भी SECURE_GATEWAYएक उपनाम के रूप में स्वीकार किया जाता है, इसलिए मौजूदा deployments काम करते रहते हैं। यह deprecated है और Q3 2026 के अंत में हटाने के लिए निर्धारित है।

कैशिंग

Secure Gateway पहली डाउनलोड पर प्रत्येक response को कैश करता है, और यह इस आधार पर tiered होता है कि सामग्री कितनी बार बदलती है। content-addressed container blobs और model weights सबसे लंबे समय तक रखे जाते हैं, और mutable API responses एक छोटे समय-खंड के लिए। किसी भी Inference Server के बाद के अनुरोध कैश से सर्व किए जाते हैं, जिससे bandwidth उपयोग और पूरे fleet में cold starts कम होते हैं।