Podman के साथ RHEL पर Secure Gateway
Kubernetes के बिना Red Hat Enterprise Linux hosts पर Secure Gateway डिप्लॉय करें, जहाँ gateway और इसका encrypted cache Roboflow Deployment Manager द्वारा प्रबंधित Podman containers के रूप में चलते हैं।
सुरक्षित गेटवे यह उन Red Hat Enterprise Linux होस्ट्स पर भी चलता है जिन पर Docker या Kubernetes में से कोई भी नहीं है। एक समर्पित इंस्टॉलर गेटवे और उसके एन्क्रिप्टेड कैश को Podman कंटेनरों के रूप में तैनात करता है, जिन्हें Roboflow Deployment Manager (rfdm) द्वारा पर्यवेक्षित किया जाता है, जो Podman को उसके Docker-संगत API के माध्यम से संचालित करता है। आपको Docker परिनियोजन जैसा ही गेटवे मिलता है (एक नियंत्रित एग्रेस बिंदु जो Roboflow API को प्रॉक्सी करता है और आपके बेड़े के लिए मॉडल वज़न तथा कंटेनर इमेज को कैश करता है) उसी air-gapped bundle मॉडल के साथ, उस कंटेनर रनटाइम पर जो RHEL के साथ आता है।
आर्किटेक्चर
Roboflow Deployment Manager होस्ट पर एक systemd सेवा के रूप में चलता है और Podman की Docker-संगत API (
podman.socket) के माध्यम से कंटेनरों को प्रबंधित करता है। यह गेटवे को कॉन्फ़िगर, अपडेट और चालू रखता है।गेटवे और उसका कैश बैकएंड (SeaweedFS, rest पर एन्क्रिप्शन के साथ एक S3-संगत स्टोर) सिस्टम (root) Podman इंस्टेंस के अंतर्गत कंटेनरों के रूप में चलते हैं।
गेटवे पोर्ट प्रकाशित करता है
80और443सीधे होस्ट पर: HTTPS443पर, और HTTP80को HTTPS पर रीडायरेक्ट करता है।कैश संग्रहीत है
/data/seaweedfsहोस्ट फ़ाइलसिस्टम पर, जिसे कैश कंटेनर में bind-mount किया गया है। किसी LVM वॉल्यूम ग्रुप या स्टोरेज प्रॉविज़नर की आवश्यकता नहीं है।SELinux enforcing बना रहता है। प्रबंधित कंटेनर कॉन्फ़िगरेशन में वॉल्यूम माउंट SELinux लेबल (
:Z/z) के साथ आते हैं, इसलिए न मैन्युअल relabeling की ज़रूरत है और न permissive mode की।
यह एक सिंगल-होस्ट परिनियोजन है। High availability और multi-host क्लस्टर समर्थित नहीं हैं।
गेटवे के लिए एक समर्पित होस्ट का उपयोग करें। Podman और CRI-O (जिस रनटाइम का MicroShift उपयोग करता है) होस्ट के कंटेनर स्टोरेज को साझा करते हैं, इसलिए एक में इमेज cleanup (उदा: podman image prune) दूसरे रनटाइम द्वारा कैश की गई इमेज को भी रिक्लेम कर सकता है। यदि होस्ट MicroShift चला रहा है, तो इसके बजाय MicroShift परिनियोजन का उपयोग करें।
पूर्वापेक्षाएँ
x86_64 पर एक Red Hat Enterprise Linux 9.x होस्ट, जिसमें Podman 4.x या नया हो। इंस्टॉलर बंडल बनाया गया है
linux-amd64केवल के लिए। Podman RHEL रिपॉज़िटरी से बिना किसी अतिरिक्त सदस्यता के आता है, लेकिन एक न्यूनतम इंस्टॉलेशन में यह मौजूद नहीं भी हो सकता: पहले चलाएँsudo dnf install podmanयदिpodman --versionविफल होता है। देखें समर्थन मैट्रिक्स.रूट एक्सेस: गेटवे सिस्टम (root) Podman इंस्टेंस के अंतर्गत स्थापित होता है
डिस्क: कंटेनर इमेज के लिए लगभग 3 GB
/और इसके साथ/dataके अंतर्गत कैश के लिए जगह, जो 50 GB तक बढ़ता हैपोर्ट्स
80और443जो होस्ट पर गेटवे के लिए उपलब्ध हैंकनेक्टेड इंस्टॉल के लिए, आउटबाउंड HTTPS
api.roboflow.comऔरrepo.roboflow.com
कनेक्टेड होस्ट पर इंस्टॉल करें
Podman इंस्टॉलर बंडल डाउनलोड करें और उसकी अखंडता सत्यापित करें:
इसे निकालें और इंस्टॉलर को root के रूप में चलाएँ:
इंस्टॉलर:
Podman API socket (
podman.socket) को सक्षम करता है, वही Docker-संगत API जिसके माध्यम से Deployment Manager कंटेनरों को प्रबंधित करता है।बंडल की गई Secure Gateway और SeaweedFS इमेज को होस्ट के root Podman स्टोरेज में लोड करता है। रजिस्ट्री से कुछ भी खींचा नहीं जाता।
यदि होस्ट पर मौजूद legacy CNI leftovers अन्यथा कंटेनरों के बीच DNS को तोड़ देते, तो Podman के नेटवर्क बैकएंड को netavark में स्विच करता है।
गेटवे का TLS प्रमाणपत्र और निजी कुंजी जनरेट करता है।
Roboflow Deployment Manager को Podman मोड में एक systemd सेवा के रूप में इंस्टॉल करता है और उसकी डिवाइस कॉन्फ़िगरेशन लिखता है।
सक्षम करता है
podman-restart.serviceताकि होस्ट रीबूट के बाद कंटेनर वापस आ जाएँ।Deployment Manager शुरू करता है, जो गेटवे और कैश कंटेनर बनाता और शुरू करता है।
परिनियोजन सत्यापित करें:
गेटवे और कैश कंटेनर दोनों Upहोने चाहिए, और health check को HTTP 200 लौटाना चाहिए। -k फ़्लैग तब तक आवश्यक है जब तक आप गेटवे के प्रमाणपत्र पर भरोसा नहीं करते; देखें TLS और ट्रस्ट.
एयर-गैप्ड इंस्टॉल करें
वही बंडल उन होस्ट्स पर इंस्टॉल होता है जिनमें इंटरनेट एक्सेस नहीं है। कंटेनर इमेज इसमें 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 छोड़ देना सबसे आम कारण है कि गेटवे अब अपनी कुंजी नहीं पढ़ पाता (देखें समस्या निवारण).
Inference Servers को कनेक्ट करना
हर उस मशीन पर जो Roboflow Inference Server चलाती है, गेटवे का client install script चलाएँ। यह गेटवे के प्रमाणपत्र को मशीन के trust store में जोड़ता है और उसके Roboflow ट्रैफ़िक (API calls, model weights, और container image pulls) को गेटवे के माध्यम से रूट करता है:
फ़्लैग यहाँ आवश्यक है: मशीन अभी गेटवे के प्रमाणपत्र पर भरोसा नहीं करती, और यही script इंस्टॉल करती है। इसे केवल उस नेटवर्क पथ पर चलाएँ जिसे आप नियंत्रित करते हैं, या script को स्वयं कॉपी करके पहले जाँचें। -k वैकल्पिक रूप से, किसी individual Inference Server को
के साथ गेटवे की ओर इंगित करें SECURE_GATEWAY environment variable; देखें Inference Servers को कनेक्ट करना. उपयोग करें SECURE_GATEWAY=https://repo.roboflow.com. संस्करणों के बीच explicit HTTPS scheme का उपयोग करें; pending runtime-hardening build bare addresses और plaintext gateways को संभालने के तरीके बदलता है, जैसा कि Security Configuration Migrationमें वर्णित है। hostname भी महत्वपूर्ण है: जनरेट किया गया प्रमाणपत्र repo.roboflow.com को कवर करता है https://<host-ip> प्रमाणपत्र सत्यापन में विफल होता है, भले ही मशीन प्रमाणपत्र पर भरोसा करने लगे। पहले 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.crt
SELinux कंटेनर को होस्ट 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.
समर्थन मैट्रिक्स
9.x
4.x
Podman 4 RHEL 9 के साथ आता है
9.x
5.x
RHEL 9.6 पर Podman 5.4.0 के साथ सत्यापित
Podman 4.x न्यूनतम समर्थित संस्करण है। किसी वर्तमान RHEL 9.x रिलीज़ के साथ आने वाला Podman बिना किसी अतिरिक्त रिपॉज़िटरी या पैकेज के समर्थित है।
अंतिम अपडेट
क्या यह उपयोगी था?