> For the complete documentation index, see [llms.txt](https://docs.roboflow.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.roboflow.com/deployment/hi/self-hosted/enterprise/secure-gateway-podman.md). # Podman के साथ RHEL पर Secure Gateway Kubernetes के बिना Red Hat Enterprise Linux hosts पर Secure Gateway डिप्लॉय करें, जिसमें gateway और उसका encrypted cache Roboflow Deployment Manager द्वारा प्रबंधित Podman containers के रूप में चल रहा हो। [सुरक्षित गेटवे](/deployment/hi/self-hosted/enterprise/secure-gateway.md) यह उन Red Hat Enterprise Linux होस्ट्स पर भी चलता है जिन पर Docker या Kubernetes में से कोई भी नहीं है। एक समर्पित इंस्टॉलर गेटवे और उसके एन्क्रिप्टेड कैश को Podman कंटेनरों के रूप में तैनात करता है, जिन्हें Roboflow Deployment Manager (`rfdm`) द्वारा पर्यवेक्षित किया जाता है, जो Podman को उसके Docker-संगत API के माध्यम से संचालित करता है। आपको Docker परिनियोजन जैसा ही गेटवे मिलता है (एक नियंत्रित एग्रेस बिंदु जो Roboflow API को प्रॉक्सी करता है और आपके बेड़े के लिए मॉडल वज़न तथा कंटेनर इमेज को कैश करता है) उसी air-gapped bundle मॉडल के साथ, उस कंटेनर रनटाइम पर जो RHEL के साथ आता है। {% hint style="info" %} तीन परिनियोजन मॉडल उपलब्ध हैं। उपयोग करें [Docker परिनियोजन](/deployment/hi/self-hosted/enterprise/secure-gateway.md) उन होस्ट्स पर जिन पर पहले से Docker चल रहा है, यह पृष्ठ उन RHEL होस्ट्स पर जिन पर Docker या Kubernetes नहीं है, और [MicroShift पर सुरक्षित गेटवे](/deployment/hi/self-hosted/enterprise/secure-gateway-microshift.md) Red Hat Device Edge होस्ट्स पर, जिन्हें Kubernetes बेड़े के रूप में प्रबंधित किया जाता है। गेटवे का कॉन्फ़िगरेशन संदर्भ (कैशिंग, TLS चर, लॉग निर्यात) तीनों में साझा है: देखें [सुरक्षित गेटवे](/deployment/hi/self-hosted/enterprise/secure-gateway.md) और [सुरक्षित गेटवे मैनुअल](https://secure-gateway.roboflow.com/manual/). {% endhint %} ## आर्किटेक्चर * Roboflow Deployment Manager होस्ट पर एक systemd सेवा के रूप में चलता है और Podman की Docker-संगत API (`podman.socket`) के माध्यम से कंटेनरों को प्रबंधित करता है। यह गेटवे को कॉन्फ़िगर, अपडेट और चालू रखता है। * गेटवे और उसका कैश बैकएंड (SeaweedFS, rest पर एन्क्रिप्शन के साथ एक S3-संगत स्टोर) सिस्टम (root) Podman इंस्टेंस के अंतर्गत कंटेनरों के रूप में चलते हैं। * गेटवे पोर्ट प्रकाशित करता है `80` और `443` सीधे होस्ट पर: HTTPS `443`पर, और HTTP `80` को HTTPS पर रीडायरेक्ट करता है। * कैश संग्रहीत है `/data/seaweedfs` होस्ट फ़ाइलसिस्टम पर, जिसे कैश कंटेनर में bind-mount किया गया है। किसी LVM वॉल्यूम ग्रुप या स्टोरेज प्रॉविज़नर की आवश्यकता नहीं है। * SELinux enforcing बना रहता है। प्रबंधित कंटेनर कॉन्फ़िगरेशन में वॉल्यूम माउंट SELinux लेबल (`:Z`/`z`) के साथ आते हैं, इसलिए न मैन्युअल relabeling की ज़रूरत है और न permissive mode की। यह एक सिंगल-होस्ट परिनियोजन है। High availability और multi-host क्लस्टर समर्थित नहीं हैं। {% hint style="warning" %} गेटवे के लिए एक समर्पित होस्ट का उपयोग करें। Podman और CRI-O (जिस रनटाइम का MicroShift उपयोग करता है) होस्ट के कंटेनर स्टोरेज को साझा करते हैं, इसलिए एक में इमेज cleanup (उदा: `podman image prune`) दूसरे रनटाइम द्वारा कैश की गई इमेज को भी रिक्लेम कर सकता है। यदि होस्ट MicroShift चला रहा है, तो इसके बजाय [MicroShift परिनियोजन](/deployment/hi/self-hosted/enterprise/secure-gateway-microshift.md) का उपयोग करें। {% endhint %} ## पूर्वापेक्षाएँ * x86\_64 पर एक Red Hat Enterprise Linux 9.x होस्ट, जिसमें Podman 4.x या नया हो। इंस्टॉलर बंडल बनाया गया है `linux-amd64` केवल के लिए। Podman RHEL रिपॉज़िटरी से बिना किसी अतिरिक्त सदस्यता के आता है, लेकिन एक न्यूनतम इंस्टॉलेशन में यह मौजूद नहीं भी हो सकता: पहले चलाएँ `sudo dnf install podman` यदि `podman --version` विफल होता है। देखें [समर्थन मैट्रिक्स](#support-matrix). * रूट एक्सेस: गेटवे सिस्टम (root) Podman इंस्टेंस के अंतर्गत स्थापित होता है * डिस्क: कंटेनर इमेज के लिए लगभग 3 GB `/` और इसके साथ `/data`के अंतर्गत कैश के लिए जगह, जो 50 GB तक बढ़ता है * पोर्ट्स `80` और `443` जो होस्ट पर गेटवे के लिए उपलब्ध हैं * कनेक्टेड इंस्टॉल के लिए, आउटबाउंड HTTPS `api.roboflow.com` और `repo.roboflow.com` {% hint style="info" %} MicroShift परिनियोजन के विपरीत, यहाँ कोई Kubernetes वितरण स्थापित नहीं करना है: न OpenShift pull secret और न LVM वॉल्यूम ग्रुप। आपकी Red Hat सदस्यता को केवल RHEL को ही कवर करना होगा। {% endhint %} ## कनेक्टेड होस्ट पर इंस्टॉल करें Podman इंस्टॉलर बंडल डाउनलोड करें और उसकी अखंडता सत्यापित करें: ```bash curl -fOL https://repo.roboflow.com/rfdm/secure-gateway/podman/latest/secure-gateway-podman-installer-linux-amd64.tar.gz curl -fOL https://repo.roboflow.com/rfdm/secure-gateway/podman/latest/secure-gateway-podman-installer-linux-amd64.tar.gz.sha256 echo "$(cat secure-gateway-podman-installer-linux-amd64.tar.gz.sha256) secure-gateway-podman-installer-linux-amd64.tar.gz" \\ | sha256sum -c - ``` इसे निकालें और इंस्टॉलर को root के रूप में चलाएँ: ```bash tar xzf secure-gateway-podman-installer-linux-amd64.tar.gz cd secure-gateway-podman-installer sudo ./install-podman.sh \\ --api-key \\ --device-id \\ --workspace ``` इंस्टॉलर: 1. Podman API socket (`podman.socket`) को सक्षम करता है, वही Docker-संगत API जिसके माध्यम से Deployment Manager कंटेनरों को प्रबंधित करता है। 2. बंडल की गई Secure Gateway और SeaweedFS इमेज को होस्ट के root Podman स्टोरेज में लोड करता है। रजिस्ट्री से कुछ भी खींचा नहीं जाता। 3. यदि होस्ट पर मौजूद legacy CNI leftovers अन्यथा कंटेनरों के बीच DNS को तोड़ देते, तो Podman के नेटवर्क बैकएंड को netavark में स्विच करता है। 4. गेटवे का TLS प्रमाणपत्र और निजी कुंजी जनरेट करता है। 5. Roboflow Deployment Manager को Podman मोड में एक systemd सेवा के रूप में इंस्टॉल करता है और उसकी डिवाइस कॉन्फ़िगरेशन लिखता है। 6. सक्षम करता है `podman-restart.service` ताकि होस्ट रीबूट के बाद कंटेनर वापस आ जाएँ। 7. Deployment Manager शुरू करता है, जो गेटवे और कैश कंटेनर बनाता और शुरू करता है। परिनियोजन सत्यापित करें: ```bash sudo systemctl is-active rfdm sudo podman ps curl -fk https:///health ``` गेटवे और कैश कंटेनर दोनों `Up`होने चाहिए, और health check को HTTP 200 लौटाना चाहिए। `-k` फ़्लैग तब तक आवश्यक है जब तक आप गेटवे के प्रमाणपत्र पर भरोसा नहीं करते; देखें [TLS और ट्रस्ट](#tls-and-trust). ## एयर-गैप्ड इंस्टॉल करें वही बंडल उन होस्ट्स पर इंस्टॉल होता है जिनमें इंटरनेट एक्सेस नहीं है। कंटेनर इमेज इसमें OCI archives के रूप में शामिल रहती हैं और सीधे होस्ट के Podman स्टोरेज में लोड की जाती हैं। कंटेनर सटीक version tags का उपयोग करते हैं, इसलिए इंस्टॉल के समय या बाद में, कभी भी रजिस्ट्री से कुछ भी नहीं खींचा जाता। कनेक्टेड मशीन पर बंडल डाउनलोड और सत्यापित करें, उसे removable media या अपनी आंतरिक फ़ाइल-स्थानांतरण प्रक्रिया से होस्ट पर ट्रांसफर करें, फिर निकालें और चलाएँ `install-podman.sh` ठीक ऊपर दिए अनुसार। सत्यापन वही है। ## TLS और ट्रस्ट इंस्टॉलर गेटवे के लिए एक self-signed प्रमाणपत्र जनरेट करता है, जिसके साथ यह पोर्ट `443` पर HTTPS सर्व करता है और पोर्ट `80` पर HTTP को HTTPS पर रीडायरेक्ट करता है। जनरेट किया गया प्रमाणपत्र common name `repo.roboflow.com`का उपयोग करता है, साथ ही `*.roboflow.com`, `localhost`और `127.0.0.1`को भी कवर करता है, और 10 वर्षों के लिए मान्य है। इंस्टॉलर को फिर से चलाने पर वह जनरेट की गई जोड़ी तब तक बनी रहती है जब तक उस पर एक वर्ष से अधिक समय बचा है, इसलिए आपने पहले clients को जो trust वितरित किया था, वह काम करता रहता है। यह केवल जनरेट की गई सामग्री पर लागू होता है: इंस्टॉलर इसे अलग से ट्रैक करता है, इसलिए बिना `--cert` और `--key` के पुनः-रन पर, आपके द्वारा दी गई प्रमाणपत्र को self-signed प्रमाणपत्र से अधिलेखित कर देता है। गेटवे अपना प्रमाणपत्र और कुंजी पढ़ता है `/etc/secure-gateway/tls/tls.crt` और `/etc/secure-gateway/tls/tls.key` होस्ट पर। पास करें `--cert` और `--key` को `install-podman.sh` अपने स्वयं के material को शुरू से इंस्टॉल करने के लिए, या उन दो फ़ाइलों को बदलकर गेटवे कंटेनर को पुनः प्रारंभ करें। आपके प्रमाणपत्र में `repo.roboflow.com`को कवर करना होगा: client install script उस hostname को `/etc/hosts`में गेटवे की ओर पुनर्निर्देशित करता है, और कंटेनर रनटाइम इमेज खींचने से पहले TLS hostname की जाँच करते हैं। गेटवे प्रक्रिया अपने कंटेनर के अंदर UID 1000 के रूप में group 0 के साथ चलती है, इसलिए यह फ़ाइलों को उनके owner permissions के माध्यम से पढ़ती है। इंस्टॉलर दोनों फ़ाइलों को owner `1000:0`पर सेट करता है, mode `0640` कुंजी पर `0644` प्रमाणपत्र पर, और directory को owner `root:0` और mode `0750`पर। फ़ाइलों को root के रूप में बदलकर root-owned छोड़ देना सबसे आम कारण है कि गेटवे अब अपनी कुंजी नहीं पढ़ पाता (देखें [समस्या निवारण](#troubleshooting)). ## Inference Servers को कनेक्ट करना हर उस मशीन पर जो Roboflow Inference Server चलाती है, गेटवे का client install script चलाएँ। यह गेटवे के प्रमाणपत्र को मशीन के trust store में जोड़ता है और उसके Roboflow ट्रैफ़िक (API calls, model weights, और container image pulls) को गेटवे के माध्यम से रूट करता है: ```bash curl -fsSLk https:///install-client.sh | sudo bash -s -- --server ``` फ़्लैग यहाँ आवश्यक है: मशीन अभी गेटवे के प्रमाणपत्र पर भरोसा नहीं करती, और यही script इंस्टॉल करती है। इसे केवल उस नेटवर्क पथ पर चलाएँ जिसे आप नियंत्रित करते हैं, या script को स्वयं कॉपी करके पहले जाँचें। `-k` वैकल्पिक रूप से, किसी individual Inference Server को के साथ गेटवे की ओर इंगित करें `SECURE_GATEWAY` environment variable; देखें [Inference Servers को कनेक्ट करना](/deployment/hi/self-hosted/enterprise/secure-gateway.md#connecting-inference-servers). उपयोग करें `SECURE_GATEWAY=https://repo.roboflow.com`. संस्करणों के बीच explicit HTTPS scheme का उपयोग करें; pending runtime-hardening build bare addresses और plaintext gateways को संभालने के तरीके बदलता है, जैसा कि [Security Configuration Migration](/deployment/hi/self-hosted/inference-server/configuration/security-migration.md#gateway-transport)में वर्णित है। hostname भी महत्वपूर्ण है: जनरेट किया गया प्रमाणपत्र `repo.roboflow.com` को कवर करता है `https://` प्रमाणपत्र सत्यापन में विफल होता है, भले ही मशीन प्रमाणपत्र पर भरोसा करने लगे। पहले client install script चलाएँ, जो `repo.roboflow.com` को गेटवे की ओर `/etc/hosts` इंगित करता है और प्रमाणपत्र इंस्टॉल करता है। इसके बजाय IP address का उपयोग करने के लिए, उसे कवर करने वाला अपना प्रमाणपत्र जारी करें और इसे `--cert` और `--key`के साथ इंस्टॉल करें। केवल गेटवे को outbound access की आवश्यकता है `api.roboflow.com` और `repo.roboflow.com`. ## समस्या निवारण
लक्षणक्या करें
कंटेनर नाम से एक-दूसरे को resolve नहीं कर पाते, और गेटवे अपने कैश तक पहुँचते समय name-resolution त्रुटियाँ लॉग करता हैPodman legacy CNI नेटवर्क बैकएंड का उपयोग कर रहा है, जिसमें container DNS नहीं है, आमतौर पर पहले के कंटेनर रनटाइम से बचे हुए CNI leftovers के कारण। जाँच करें sudo podman info --format '{{.Host.NetworkBackend}}'; इसे रिपोर्ट करना चाहिए netavark. इंस्टॉलर आवश्यक होने पर netavark चुनने के लिए /etc/containers/containers.conf.d/ के अंतर्गत एक drop-in लिखता है। फिक्स के बाद मौजूदा कंटेनर पुराने backend पर बने रहते हैं, इसलिए उन्हें हटाएँ sudo podman rm -f secure-gateway seaweedfs और Deployment Manager को पुनः प्रारंभ करें (sudo systemctl restart rfdm) ताकि उन्हें पुनः बनाया जा सके।
गेटवे इस त्रुटि के साथ विफल होता है Permission denied अपनी TLS कुंजी पढ़ते समयप्रमाणपत्र और कुंजी फ़ाइलों का स्वामित्व होना चाहिए 1000:0 (mode 0640 कुंजी पर 0644 प्रमाणपत्र पर), एक ऐसे directory में जिसका स्वामित्व root:0 mode के साथ 0750हो। इंस्टॉलर इसे सेट करता है; सामान्य कारण यह है कि प्रमाणपत्र को root के रूप में मैन्युअल रूप से बदला गया हो। उन्हें हाथ से सेट करें, फिर गेटवे कंटेनर को पुनः प्रारंभ करें: sudo chown 1000:0 /etc/secure-gateway/tls/tls.crt /etc/secure-gateway/tls/tls.key, sudo chmod 0640 /etc/secure-gateway/tls/tls.key, sudo chmod 0644 /etc/secure-gateway/tls/tls.crt. पुनः चलाना install-podman.sh भी इसे ठीक कर देता है, लेकिन फिर से --cert और --key पास करें यदि आपने अपना स्वयं का प्रमाणपत्र लाया था, या पुनः-रन उसे self-signed one से बदल देता है।
Permission denied माउंट की गई directory में लिखनावॉल्यूम माउंट में उसका SELinux लेबल नहीं है। प्रबंधित कॉन्फ़िगरेशन में हर वॉल्यूम एक :Z (या shared :z) विकल्प के साथ आता है; यदि आपने माउंट हाथ से जोड़ा है, तो SELinux को permissive mode में डालने के बजाय लेबल जोड़ें।
गेटवे इस प्रकार crash-loop करता है PermissionError पढ़ते समय /etc/ssl/certs/ca-certificates.crtSELinux कंटेनर को होस्ट CA bundle से रोक रहा है जिसे Deployment Manager माउंट करता है। यह denial दबा दी जाती है, इसलिए audit searches में कुछ नहीं मिलता। चलाएँ sudo setsebool -P container_read_certs on. इंस्टॉलर यह boolean सेट करता है, इसलिए इसे पुनः चलाने से होस्ट भी ठीक हो जाता है।
गेटवे लॉग्स Init handshake failed ... starting in local-cache-only modeस्टार्टअप पर गेटवे Roboflow API तक नहीं पहुँच सका (गलत API key, आउटबाउंड कनेक्टिविटी नहीं, या कैश अभी शुरू हो रहा था)। यह ट्रैफ़िक सर्व करता रहता है और स्थानीय रूप से कैश भी करता है, लेकिन अपने S3-समर्थित कैश के बिना चलता है और अगले रिस्टार्ट तक backend को telemetry या events रिपोर्ट नहीं कर सकता। कारण ठीक करें, फिर गेटवे कंटेनर को पुनः प्रारंभ करें: sudo podman restart <gateway-container>, container name के साथ sudo podman ps.
लॉग्स कहाँ हैंDeployment Manager: sudo journalctl -u rfdm. Gateway और cache: sudo podman logs <container>, container names के साथ sudo podman ps.
## समर्थन मैट्रिक्स
RHELPodmanनोट्स
9.x4.xPodman 4 RHEL 9 के साथ आता है
9.x5.xRHEL 9.6 पर Podman 5.4.0 के साथ सत्यापित
Podman 4.x न्यूनतम समर्थित संस्करण है। किसी वर्तमान RHEL 9.x रिलीज़ के साथ आने वाला Podman बिना किसी अतिरिक्त रिपॉज़िटरी या पैकेज के समर्थित है।