> 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-microshift.md). # MicroShift पर Secure Gateway Red Hat Device Edge पर Secure Gateway डिप्लॉय करें, जहाँ gateway और इसका encrypted cache Roboflow Deployment Manager द्वारा प्रबंधित MicroShift workloads के रूप में चलते हैं। [सुरक्षित गेटवे](/deployment/hi/self-hosted/enterprise/secure-gateway.md) MicroShift का उपयोग करते हुए Red Hat Device Edge पर भी चलता है, जो एज डिवाइसों के लिए Red Hat का Kubernetes वितरण है। एक समर्पित इंस्टॉलर गेटवे और उसके एन्क्रिप्टेड कैश को Kubernetes वर्कलोड के रूप में तैनात करता है, जिसे RHEL होस्ट पर चल रहे Roboflow Deployment Manager (`rfdm`) द्वारा पर्यवेक्षित किया जाता है। आपको Docker डिप्लॉयमेंट जैसा ही गेटवे मिलता है (निकास का एक नियंत्रित बिंदु जो Roboflow API को प्रॉक्सी करता है और आपके फ्लीट के लिए मॉडल वेट्स और कंटेनर इमेजों को कैश करता है), जिसे Red Hat Device Edge पर मानकीकृत होस्ट्स के लिए पैकेज किया गया है। {% hint style="info" %} यह पृष्ठ MicroShift डिप्लॉयमेंट को कवर करता है। MicroShift या Docker के बिना RHEL होस्ट्स के लिए, देखें [RHEL पर Podman के साथ सुरक्षित गेटवे](/deployment/hi/self-hosted/enterprise/secure-gateway-podman.md). Docker होस्ट्स के लिए, और गेटवे के कॉन्फ़िगरेशन संदर्भ (कैशिंग, TLS वेरिएबल्स, लॉग निर्यात) के लिए, देखें [सुरक्षित गेटवे](/deployment/hi/self-hosted/enterprise/secure-gateway.md) और [सुरक्षित गेटवे मैनुअल](https://secure-gateway.roboflow.com/manual/). {% endhint %} ## आर्किटेक्चर * Roboflow Deployment Manager RHEL होस्ट पर systemd सेवा के रूप में चलता है और MicroShift के Kubernetes API के माध्यम से वर्कलोड्स का प्रबंधन करता है। यह गेटवे को कॉन्फ़िगर, अपडेट और चलाते हुए रखता है। * गेटवे और उसका कैश बैकएंड (SeaweedFS, एट-रेस्ट एन्क्रिप्शन वाला S3-संगत स्टोर) `roboflow-edge` नेमस्पेस में Deployments के रूप में चलते हैं। * एक `LoadBalancer` Service डिवाइस IP पर गेटवे को प्रकाशित करता है: पोर्ट पर HTTPS `443` और पोर्ट पर HTTP-से-HTTPS रीडायरेक्ट `80`. * कैश MicroShift के LVMS storage provisioner द्वारा उपलब्ध कराए गए persistent volume पर संग्रहीत होता है। volume claim 60 GB का है, जिसे गेटवे के 50 GB कैश और अतिरिक्त स्थान के लिए आकार दिया गया है। * सभी वर्कलोड्स MicroShift के डिफ़ॉल्ट restricted security profile के तहत बिना विशेषाधिकार के चलते हैं: न privileged containers, न root उपयोगकर्ता, और न कोई custom security context grants। यह single-node डिप्लॉयमेंट है। High availability और multi-node clusters समर्थित नहीं हैं। ## पूर्वापेक्षाएँ * x86\_64 पर Red Hat Enterprise Linux 9.6 होस्ट, वैध Red Hat subscription के साथ। इंस्टॉलर बंडल इसके लिए बनाया गया है `linux-amd64` केवल। * Red Hat build of MicroShift 4.16 या उससे नया, आपके OpenShift pull secret के कॉन्फ़िगरेशन के साथ इंस्टॉल और चल रहा हो। 4.20 (EUS) की अनुशंसा की जाती है; देखें [सपोर्ट मैट्रिक्स](#support-matrix). * कम से कम 60 GB खाली स्थान वाला एक LVM volume group। MicroShift का LVMS provisioner उससे गेटवे का कैश वॉल्यूम बनाता है; यदि volume group न हो, या खाली स्थान बहुत कम हो, तो storage request `लंबित` ही रहता है और कैश कभी शुरू नहीं होता। * `skopeo` होस्ट पर इंस्टॉल किया हुआ (`sudo dnf install skopeo`)। इंस्टॉलर इससे बंडल की गई इमेजों को CRI-O के स्टोरेज में कॉपी करता है और यदि यह अनुपस्थित हो तो रुक जाता है। * OpenShift CLI (`oc`) होस्ट पर इंस्टॉल, आपके MicroShift रिलीज़ से मेल खाने वाले संस्करण में। MicroShift इसे इंस्टॉल नहीं करता, और इस पृष्ठ पर सत्यापन तथा समस्या निवारण कमांड इसका उपयोग करते हैं। इसे sudo के `secure_path` (`/usr/bin` में कहीं इंस्टॉल करें ( `sudo` इससे हटाता है `/usr/local/bin` को `PATH`से, इसलिए `oc` वहाँ अनपैक करने पर `sudo: oc: command not found`. * पोर्ट्स `80` और `443` डिवाइस IP पर गेटवे के लिए उपलब्ध * कनेक्टेड इंस्टॉल्स के लिए, आउटबाउंड HTTPS `api.roboflow.com` और `repo.roboflow.com` यदि firewalld चल रहा है, जो स्टॉक RHEL इंस्टॉलेशन पर होता है, तो इंस्टॉल करने से पहले गेटवे के पोर्ट खोलें और MicroShift के pod network को trusted zone में रखें। इसके बिना, pod networking और client access दोनों विफल हो जाते हैं: ```bash sudo firewall-cmd --permanent --zone=trusted --add-source=10.42.0.0/16 sudo firewall-cmd --permanent --zone=trusted --add-source=169.254.169.1 sudo firewall-cmd --permanent --add-service=http --add-service=https sudo firewall-cmd --reload ``` firewalld reload, OVN pods के फिर से शुरू होने तक MicroShift pod networking को तोड़ देता है, इसलिए reload के बाद पुनर्प्राप्ति चरण के साथ आगे बढ़ें [समस्या निवारण](#troubleshooting). {% hint style="warning" %} इंस्टॉलर MicroShift के डिफ़ॉल्ट ingress router को अक्षम कर देता है ताकि गेटवे डिवाइस पर पोर्ट 80 और 443 का स्वामी बन सके। यदि आप इस होस्ट पर पहले से router के माध्यम से अन्य वर्कलोड्स प्रदान कर रहे हैं, तो यह डिप्लॉयमेंट मॉडल उनसे टकराएगा: गेटवे के लिए समर्पित डिवाइस का उपयोग करें। {% endhint %} ## कनेक्टेड होस्ट पर इंस्टॉल करें MicroShift इंस्टॉलर बंडल डाउनलोड करें और उसकी अखंडता सत्यापित करें: ```bash curl -fOL https://repo.roboflow.com/rfdm/secure-gateway/microshift/latest/secure-gateway-microshift-installer-linux-amd64.tar.gz curl -fOL https://repo.roboflow.com/rfdm/secure-gateway/microshift/latest/secure-gateway-microshift-installer-linux-amd64.tar.gz.sha256 echo "$(cat secure-gateway-microshift-installer-linux-amd64.tar.gz.sha256) secure-gateway-microshift-installer-linux-amd64.tar.gz" \ | sha256sum -c - ``` इसे निकालें और रूट के रूप में इंस्टॉलर चलाएँ: ```bash tar xzf secure-gateway-microshift-installer-linux-amd64.tar.gz cd secure-gateway-microshift-installer sudo ./install-microshift.sh \ --api-key \ --device-id \ --workspace ``` इंस्टॉलर: 1. जाँचता है कि MicroShift चल रहा है और समर्थित संस्करण पर है, तथा स्टोरेज के लिए एक LVM volume group उपलब्ध है। 2. बंडल की गई Secure Gateway और SeaweedFS इमेजों को होस्ट के कंटेनर स्टोरेज में लोड करता है। रजिस्ट्री से कुछ भी पुल नहीं किया जाता। 3. इमेजों को CRI-O के कॉन्फ़िगरेशन में pin करता है ताकि Kubernetes disk-pressure garbage collection उन्हें कभी न हटाए। 4. MicroShift के डिफ़ॉल्ट ingress router को अक्षम करता है और MicroShift को पुनः आरंभ करता है, जिससे गेटवे के लिए पोर्ट 80 और 443 मुक्त हो जाते हैं। 5. Roboflow Deployment Manager को systemd सेवा के रूप में इंस्टॉल करता है और इसकी device configuration लिखता है। 6. Deployment Manager शुरू करता है, जो `roboflow-edge` नेमस्पेस बनाता है और गेटवे तथा कैश को तैनात करता है। डिप्लॉयमेंट सत्यापित करें: ```bash sudo systemctl is-active rfdm sudo oc get pods -n roboflow-edge \ --kubeconfig /var/lib/microshift/resources/kubeadmin/kubeconfig curl -fk https:///health ``` दोनों pods को `Running`होना चाहिए, और health check से HTTP 200 लौटना चाहिए। `-k` फ़्लैग तब तक आवश्यक है जब तक आप गेटवे के प्रमाणपत्र पर भरोसा न कर लें; देखें [TLS और ट्रस्ट](#tls-and-trust). ## एयर-गैप्ड इंस्टॉल करें वही बंडल उन होस्ट्स पर भी इंस्टॉल होता है जिनके पास इंटरनेट एक्सेस नहीं है। कंटेनर इमेजें इसमें OCI archives के रूप में शामिल होती हैं और सीधे होस्ट के कंटेनर स्टोरेज में लोड हो जाती हैं। वर्कलोड्स सटीक version tags का संदर्भ लेते हैं, इसलिए इंस्टॉल के समय या बाद में, कभी भी रजिस्ट्री से कुछ भी पुल नहीं किया जाता। बंडल को कनेक्टेड मशीन पर डाउनलोड और सत्यापित करें, इसे रिमूवेबल मीडिया या अपनी आंतरिक फ़ाइल-स्थानांतरण प्रक्रिया के माध्यम से डिवाइस पर स्थानांतरित करें, फिर निकालें और चलाएँ `install-microshift.sh` ठीक ऊपर बताए अनुसार। सत्यापन समान है। ## TLS और ट्रस्ट डिफ़ॉल्ट रूप से, Roboflow Deployment Manager गेटवे के लिए एक self-signed certificate बनाता है और उसे `secure-gateway-tls` Secret (type `kubernetes.io/tls`) में `roboflow-edge` नेमस्पेस। गेटवे pod इस Secret को mount करता है और पोर्ट 443 पर HTTPS सर्व करता है। प्रमाणपत्र Deployment Manager की पुनः-स्थापना के बाद भी बना रहता है। जब यह अनुपस्थित हो, इसकी समाप्ति में 30 दिन या कम बचे हों, जब प्रमाणपत्र और private key मेल न खाएँ, या जब यह अब उन सभी नामों को कवर न करे जिन्हें नया प्रमाणपत्र कवर करता, तब Deployment Manager इसे बदल देता है। आपके अपने प्रमाणपत्र को उन सभी नामों को कवर करना होगा, अन्यथा अगली reconcile पर Deployment Manager इसे self-signed प्रमाणपत्र से बदल देगा: * `repo.roboflow.com`, `*.roboflow.com`और `localhost`. क्लाइंट गेटवे तक `repo.roboflow.com`के अंतर्गत पहुँचते हैं, इसलिए यदि प्रमाणपत्र इसे कवर नहीं करता तो कंटेनर इमेज पुल विफल हो जाते हैं। * `secure-gateway`, `secure-gateway.roboflow-edge.svc`और `secure-gateway.roboflow-edge.svc.cluster.local` * डिवाइस का hostname * IP पते `127.0.0.1` और डिवाइस IP अपना प्रमाणपत्र उपयोग करने के लिए, Secret की सामग्री बदलें और गेटवे को पुनः आरंभ करें: ```bash export KUBECONFIG=/var/lib/microshift/resources/kubeadmin/kubeconfig sudo -E oc create secret tls secure-gateway-tls -n roboflow-edge \ --cert=/path/to/gateway.crt --key=/path/to/gateway.key \ --dry-run=client -o yaml | sudo -E oc apply -f - sudo -E oc rollout restart deployment/secure-gateway -n roboflow-edge ``` अपना प्रमाणपत्र उसकी समाप्ति से 30 दिनों से अधिक पहले नवीनीकृत करें। यदि Secret में मौजूद प्रमाणपत्र अपने अंतिम 30 दिनों में प्रवेश करता है, तो Deployment Manager उसे ताज़ा बनाए गए self-signed प्रमाणपत्र से बदल देता है। डिवाइस का IP पता या hostname बदलने का भी वही प्रभाव होता है, इसलिए इनमें से किसी को बदलने से पहले अपना प्रमाणपत्र फिर से जारी करें। Deployment Manager इस डिवाइस के अपने TLS सेवा प्रमाणपत्रों से एक trust bundle भी बनाता है और उसे `roboflow-trust-bundle` ConfigMap के रूप में प्रकाशित करता है, जो गेटवे में mount होता है और यहाँ उपलब्ध कराया जाता है `/trust-bundle.crt`. client install script इसे प्रत्येक मशीन पर इंस्टॉल करता है जिस पर यह चलता है, इसलिए वे क्लाइंट इस डिवाइस की हर TLS सेवा पर भरोसा करते हैं, बिना आपको हाथ से प्रमाणपत्र वितरित किए। ## Inference Servers कनेक्ट करना प्रत्येक मशीन पर जो Roboflow Inference Server चलाती है, गेटवे का client install script चलाएँ। यह गेटवे के प्रमाणपत्र को मशीन के trust store में जोड़ता है और इसके Roboflow ट्रैफ़िक (API कॉल्स, model weights, और container image pulls) को गेटवे के माध्यम से रूट करता है। Secret से गेटवे का प्रमाणपत्र निर्यात करें और इसे क्लाइंट पर ऐसे चैनल के माध्यम से कॉपी करें जिस पर आपको पहले से भरोसा हो (उदा: `scp`आपकी संस्था की फ़ाइल-स्थानांतरण प्रक्रिया, रिमूवेबल मीडिया)। इसे प्रमाणपत्र सत्यापन बंद करके गेटवे से स्वयं न प्राप्त करें: ```bash export KUBECONFIG=/var/lib/microshift/resources/kubeadmin/kubeconfig sudo -E oc get secret secure-gateway-tls -n roboflow-edge \ -o jsonpath='{.data.tls\.crt}' | base64 -d > gateway-ca.crt scp gateway-ca.crt :/tmp/gateway-ca.crt ``` क्लाइंट पर, उस प्रमाणपत्र के विरुद्ध सत्यापित TLS कनेक्शन के माध्यम से install script डाउनलोड करें, फिर उसे चलाएँ: ```bash curl -fsSL --cacert /tmp/gateway-ca.crt \ https:///install-client.sh -o install-client.sh sudo bash install-client.sh --server ``` स्क्रिप्ट को अलग से डाउनलोड करना और फिर चलाना, आपको रूट के रूप में चलाने से पहले उसे पढ़ने की अनुमति भी देता है। इसे केवल उस नेटवर्क पथ पर चलाएँ जिसे आप नियंत्रित करते हैं: `install-client.sh` प्राप्त करता है `/ca.crt` और `/trust-bundle.crt` गेटवे से ही, कनेक्शन सत्यापित किए बिना, इसलिए उस पथ पर एक interceptor फिर भी उस चरण में एक trusted CA प्रदान कर सकता है, भले ही ऊपर का डाउनलोड सत्यापित था। वैकल्पिक रूप से, किसी individual Inference Server को गेटवे की ओर `SECURE_GATEWAY` environment variable के साथ निर्देशित करें; देखें [Inference Servers कनेक्ट करना](/deployment/hi/self-hosted/enterprise/secure-gateway.md#connecting-inference-servers). स्पष्ट scheme का उपयोग करें (`SECURE_GATEWAY=https://`) संस्करणों के बीच; प्रमाणपत्र को उस IP को कवर करना चाहिए। लंबित runtime-hardening build bare-address और plaintext व्यवहार को बदलता है, जैसा कि [Security Configuration Migration](/deployment/hi/self-hosted/inference-server/configuration/security-migration.md#gateway-transport)में वर्णित है। Inference Server को भी गेटवे के प्रमाणपत्र पर भरोसा करना होगा, जिसे client install script आपके लिए संभालता है। केवल गेटवे को बाहर जाने की पहुँच चाहिए `api.roboflow.com` और `repo.roboflow.com`. ## समस्या निवारण
लक्षणक्या करें
कैश वॉल्यूम अटका हुआ लंबितकोई LVM volume group नहीं, या 60 GB खाली वाला कोई नहीं। खाली स्थान जाँचने के लिए देखें sudo vgs; एक बार volume group में क्षमता हो जाने पर, वॉल्यूम स्वतः bind हो जाता है। छोटे वॉल्यूम पर चलाने के लिए, घटाएँ storage_size और CACHE_MAX_SIZE_GB को एक साथ /opt/rfdm/config/rfconfig.json.
गेटवे LoadBalancer Service अटका हुआ <pending>डिवाइस पर पोर्ट 80/443 अभी भी उपयोग में हैं, आमतौर पर क्योंकि डिफ़ॉल्ट router अभी भी सक्षम है। इंस्टॉलर इसे यहाँ एक snippet के माध्यम से सेट करता है /etc/microshift/config.d/10-roboflow-ingress.yaml, न कि /etc/microshift/config.yaml. पुष्टि करें sudo microshift show-config --mode effective रिपोर्ट करता है ingress.status: Removed, यदि वह गायब हो तो snippet बहाल करें, और MicroShift को पुनः आरंभ करें; साथ ही जाँचें कि कोई अन्य होस्ट प्रक्रिया 80 या 443 पर bind न हो।
firewalld reload के बाद कनेक्शन विफल हो जाते हैंfirewalld को reload करने से OVN नेटवर्किंग pods के पुनः शुरू होने तक MicroShift pod networking टूट जाती है। openshift-ovn-kubernetes नेमस्पेस में pods हटाएँ ताकि वे फिर से बन जाएँ, या MicroShift को पुनः आरंभ करें।
नोड बना रहता है NotReady; ovnkube-master pod crash-loop करता है साथ में MTU (...) of network interface ... is too small for specified overlay MTU (1500)आपके नेटवर्क इंटरफ़ेस का MTU 1500 से कम है (क्लाउड VPCs और VPN links पर आम; GCP 1460 उपयोग करता है)। pod MTU को इंटरफ़ेस MTU माइनस 100 पर सेट करें /etc/microshift/ovn.yamlमें: 1460 इंटरफ़ेस के लिए, फ़ाइल में यह एकमात्र पंक्ति होनी चाहिए mtu: 1360. फिर चलाएँ sudo systemctl stop microshift, echo 1 | sudo microshift-cleanup-data --ovnऔर sudo systemctl start microshift. cleanup चरण आवश्यक है क्योंकि पिछला MTU OVN डेटाबेस में संग्रहीत होता है।
गेटवे pods अटके हुए ImagePullBackOff होस्ट इमेज cleanup के बादइमेज pinning सटीक bundled references की रक्षा करता है, लेकिन podman rmi या podman image prune होस्ट पर अभी भी उसी storage CRI-O द्वारा उपयोग की जाने वाली sibling images और shared layers हटा सकता है। डिवाइस पर container storage को prune करने से बचें; यदि इमेजें चली गई हैं, तो उन्हें पुनः लोड करने के लिए इंस्टॉलर फिर से चलाएँ।
गेटवे लॉग्स Init handshake failed ... starting in local-cache-only modeस्टार्टअप पर गेटवे Roboflow API तक नहीं पहुँच सका (गलत API key, कोई outbound connectivity नहीं, या कैश अभी शुरू हो रहा था)। यह ट्रैफ़िक सेवा देना जारी रखता है और स्थानीय रूप से कैश भी करता है, लेकिन अपने S3-backed cache के बिना चलता है और अगले restart तक backend को telemetry या events रिपोर्ट नहीं कर सकता। कारण ठीक करें, फिर चलाएँ sudo oc rollout restart deployment/secure-gateway -n roboflow-edge --kubeconfig /var/lib/microshift/resources/kubeadmin/kubeconfig.
लॉग्स कहाँ हैंDeployment Manager: sudo journalctl -u rfdm. गेटवे और कैश: sudo oc logs deployment/secure-gateway -n roboflow-edge (और deployment/seaweedfs), साथ में --kubeconfig /var/lib/microshift/resources/kubeadmin/kubeconfig.
## सपोर्ट मैट्रिक्स
MicroShiftRHELनोट्स
4.199.6
4.20 (EUS)9.6अनुशंसित
4.219.6RHEL 10 पर MicroShift 4.21 एक Red Hat Technology Preview है और Secure Gateway के लिए समर्थित नहीं है।
MicroShift 4.16 न्यूनतम समर्थित संस्करण है। सम-संख्या वाले MicroShift रिलीज़ Extended Update Support (EUS) के साथ आते हैं, इसलिए लंबे समय तक चलने वाले edge deployments के लिए 4.20 सबसे अच्छा विकल्प है।