Skip to main content
Self-hosting एक Enterprise तैनाती है। Enterprise लाइसेंस प्राप्त करने के लिए Failproof AI से संपर्क करें।

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

  • Kubernetes 1.27 या नवीनतर संस्करण, cluster-admin पहुंच के साथ
  • Kustomize समर्थन के साथ kubectl
  • Helm 3
  • निजी ghcr.io/agenteye-enterprise images तक पहुंच
  • दो DNS नाम: एक डैशबोर्ड के लिए और एक ingest के लिए
  • PostgreSQL और ClickHouse के लिए persistent storage
  • cert-manager और Traefik, या समकक्ष ingress और certificate infrastructure जो आपके overlay में अनुकूलित हो
  • उत्पादन OTP लॉगिन और सूचनाओं के लिए SMTP
स्रोत tree AWS/EKS-उन्मुख overlay और एक अलग GCP/GKE overlay प्रदान करता है। उनके certificate, load-balancer, या backup निर्देशों को संयोजित न करें: GKE अपना DNS-01, GCS, और autoscaling कॉन्फ़िगरेशन उपयोग करता है।

​
तैनाती अनुक्रम

1

क्लस्टर तैयार करें

cert-manager और सार्वजनिक/डैशबोर्ड ingress नियंत्रकों को स्थापित करें, उनके load balancers को सत्यापित करें, फिर namespace, image-pull credentials, database credentials, bootstrap admin key, और authentication/SMTP secrets बनाएं।
2

सार्वजनिक डोमेन कॉन्फ़िगर करें

overlay की जेनरेट की गई domain environment file में INGEST_DOMAIN और DASHBOARD_DOMAIN सेट करें और DNS रिकॉर्ड बनाएं जो मेल खाने वाले load balancers की ओर इशारा करते हों।
3

एक platform overlay लागू करें और सत्यापित करें

customer/EKS या GCP overlay का उपयोग करें। प्रदान किए गए Kustomize output का निरीक्षण करें, इसे लागू करें, और सभी workloads और certificates के अपने इच्छित state तक पहुंचने की पुष्टि करें, इससे पहले कि मशीनों को नामांकित करें।
4

पहुंच और ingestion को bootstrap करें

संरक्षित admin के रूप में साइन इन करें, एक organization-scoped machine key बनाएं, और सार्वजनिक ingest endpoint के माध्यम से एक छोटा परीक्षण सत्र भेजें।

​
आवश्यक और वैकल्पिक सेवाएं

​
Audit क्षमता और विफलता वितरण

जब उपलब्ध हो तो dedicated audit-agent deployment पर audits चलाएं। प्रत्येक audit-agent pod डिफ़ॉल्ट रूप से एक investigation स्वीकार करता है; प्रति-pod concurrency को बढ़ाए बिना replicas के साथ throughput स्केल करें, साथ ही memory को भी बढ़ाएं। सर्वर server replicas × AUDIT_WORKERS audits को समवर्ती रूप से dispatch कर सकता है, इसलिए dispatcher क्षमता audit-agent fleet को भरने के लिए पर्याप्त होनी चाहिए। जब प्रत्येक audit-agent slot व्यस्त हो, एक audit प्रतीक्षा करता है और अपने cadence के एक चौथाई तक retry करता है, छह घंटे तक सीमित। यदि कोई slot उपलब्ध नहीं होता, तो run निष्कर्ष के बिना पूरा होता है और विफलता ईमेल भेजता है। बार-बार “busy” विफलताएं अधिक audit-agent replicas या अधिक व्यापक रूप से अलग schedule anchors के लिए कॉल करती हैं। बार-बार “shutting down” विफलताएं अस्थिर pods या अपर्याप्त क्षमता के बजाय एक लूपिंग rollout का संकेत देती हैं। विफलता सूचनाओं के लिए एक सक्षम ईमेल चैनल और SMTP की आवश्यकता है। वे audit के recipients का उपयोग करते हैं, फिर alerts.email_default_recipients पर fallback करते हैं जब audit के पास कोई ईमेल चैनल नहीं है।

​
तैनाती को सत्यापित करें

  1. कॉन्फ़िगर किए गए डैशबोर्ड डोमेन को खोलें, admin OTP प्रवाह को पूरा करें, और organization का नाम और slug सुनिश्चित करें।
  2. Administration → Keys पर जाएं और एक संकीर्ण रूप से scoped machine key बनाएं।
  3. एक परीक्षण सत्र भेजें, फिर इसे Observe → Events और Observe → Sessions में सुनिश्चित करें।
  4. एक alert channel परीक्षण करें और, जब कॉन्फ़िगर किया जाए, एक manual evaluation और audit परीक्षण करें।

​
प्रमाणीकरण और ईमेल

डैशबोर्ड ईमेल और one-time codes का उपयोग करता है। SMTP के अभाव में, विकास तैनाती server output में OTP codes log करती है। जब SMTP_HOST सेट हो, तो username, password, और sender एक समूह के रूप में आवश्यक हैं या सर्वर शुरू होने से इनकार करता है। SMTP_TLS एक boolean है। समर्थित encrypted transport STARTTLS है, सामान्यतः port 587 पर; implicit SMTPS port 465 पर वर्तमान server transport द्वारा समर्थित नहीं है। सार्वजनिक डैशबोर्ड URL को सही तरीके से सेट करें क्योंकि OTP, alert, incident, और audit ईमेल deep links के लिए इसका उपयोग करते हैं। Organization membership नियंत्रित करता है कि कौन कोड का अनुरोध कर सकता है; प्रत्येक organization Administration → Settings में अपने स्वयं के member sign-ins को आगे restrict कर सकता है।

​
Multi-tenant आवश्यकताएं

दूसरा organization बनाने से पहले, एक मजबूत, स्थिर organization ClickHouse derivation secret कॉन्फ़िगर करें और इसे सभी server replicas में समान रखें। इसे coordinated migration के बिना rotate करने से organization-specific ClickHouse users orphan हो सकते हैं। instance-admin listener को आंतरिक रखें। प्रदान किया गया operator console opt-in है और kubectl port-forward के लिए डिज़ाइन किया गया है, सार्वजनिक ingress के लिए नहीं। इसे सक्षम करने के लिए इसके स्वयं के मजबूत API key, एक super-admin mailbox, और कार्यशील SMTP second-factor delivery की आवश्यकता है।

​
Break-glass organization CLI

agenteye-orgctl server image के अंदर ships करता है और directly PostgreSQL और ClickHouse से बात करता है। यह सार्वजनिक server या operator console unhealthy होने पर उपलब्ध रहता है।
समर्थित organization operations में create, list, rename, soft-delete, restore, ClickHouse-user reprovisioning, billing-date management, feature flags, और irreversible purge शामिल हैं। Member operations में add, list, update, remove, permission overrides, और protected-admin state शामिल हैं। purge से पहले soft-delete का उपयोग करें। org purge irreversible है और organization को पहले delete किए जाने की आवश्यकता है। संरक्षित members को organization के सामान्य Users page के माध्यम से तब तक remove या demote नहीं किया जा सकता जब तक एक operator explicitly उन्हें unprotect नहीं करता।

​
उत्पादन तत्परता checklist

  • Ingest और डैशबोर्ड DNS विभिन्न इच्छित ingress paths में resolve होते हैं।
  • TLS valid है; जहां आपकी तैनाती इसकी आवश्यकता है वहां ingest पर mutual TLS का उपयोग करें।
  • PostgreSQL और ClickHouse volumes में capacity alerts हैं।
  • Backups में दोनों datastores शामिल हैं और एक tested restore procedure है।
  • Health checks ingest silence, failed workloads, certificate expiry, storage pressure, और stale backups पर alert करते हैं।
  • Structured logs को एक मौजूदा cluster log pipeline को duplicate किए बिना एकत्रित किया जाता है।
  • Evaluator, audit, और alert worker concurrency को measured queue evidence के बिना change नहीं किया गया है।
  • एक pinned application release और rollback procedure upgrades से पहले recorded हैं।
तैनाती manifests में platform-specific security और availability assumptions हैं। उन्हें apply करने से पहले अपनी platform team के साथ rendered resources, network policies, ingress exposure, secret references, storage classes, disruption budgets, और backup destinations की समीक्षा करें।