वितरित ग्राहकों को एक निजी InfluxDB डेटाबेस से कैसे कनेक्ट करें

InfluxDB समय-श्रृंखला डेटा संग्रहीत करने के लिए सेंसर और सेवाओं के लिए एक लोकप्रिय तरीका बन गया है, और InfluxData, InfluxCloud के लिए त्वरित और आसान बनाता है। हालांकि जिन ग्राहकों से हमने बात की है उनमें से कुछ प्रबंधित क्लाउड सेवा में सब कुछ संग्रहीत नहीं कर रहे हैं। कभी-कभी उनके पास डेटा को स्वयं अपने डेटा केंद्र में संग्रहीत करने के लिए विशिष्ट व्यावसायिक, विनियामक या अनुपालन कारण होते हैं। दूसरी बार वे अपनी आपदा रिकवरी योजना के हिस्से के रूप में इन्फ्लक्सडीबी क्लाउड दोनों को डेटा भेजने के लिए टेलीग्राफ में कई आउटपुट का उपयोग कर रहे हैं।

जो भी कारण हो, एक एकल ग्राहक को एक निजी इन्फ्लक्सडीबी डेटाबेस से सुरक्षित रूप से कनेक्ट करने में संभावित रूप से नेटवर्क मार्ग स्थापित करना, फायरवॉल खोलना, एनएसीएल और सुरक्षा समूहों को समायोजित करना शामिल है। उन सभी परिवर्तनों को स्वीकृत और तैनात करने के लिए जो भी आंतरिक प्रक्रियाएँ शामिल हो सकती हैं, उन्हें नेविगेट करने का उल्लेख नहीं करना। InfluxDB का मूल्य कभी-कभी केवल एक ग्राहक के डेटा लिखने के बारे में नहीं है, यह सैकड़ों या अधिक का समर्थन करने में सक्षम होने के बारे में है। इसलिए प्रत्येक नए डिवाइस के लिए, या जब भी किसी डिवाइस के नेटवर्क कॉन्फ़िगरेशन में बदलाव होता है, तो उस नेटवर्क प्रशासन को दोहराएं, और आपको बहुत जल्दी ऐसी स्थिति मिल जाती है, जहां उन तंग नेटवर्क नियंत्रणों को बनाए रखना अस्थिर हो जाता है। अधिकांश लोग तब कुछ विकल्पों के बीच तौलेंगे: 1) दूरस्थ क्लाइंट और नेटवर्क इन्फ्लक्सडीबी डेटाबेस के बीच एक वीपीएन स्थापित करने की आवश्यकता होती है। जो कोई भी ग्राहकों का प्रबंधन कर रहा है उसके लिए उच्च सेटअप बोझ। और क्या वे वास्तव में चाहते हैं कि उनका नेटवर्क वीपीएन के माध्यम से आपसे जुड़ा हो? या 2) InfluxDB डेटाबेस को सीधे सार्वजनिक इंटरनेट पर प्रदर्शित करें, और प्रमाणीकरण प्रणाली पर भरोसा करें कि यह सुरक्षा के लिए पर्याप्त है।

आज मैं आपको तीसरे विकल्प के माध्यम से ले जा रहा हूँ। इसे लागू करने में केवल कुछ मिनट लगेंगे, किसी नेटवर्क परिवर्तन की आवश्यकता नहीं होगी, और आपको अपना निजी डेटाबेस सार्वजनिक इंटरनेट पर डालने से रोकेगा। हमें इसके साथ मिलने वाले अन्य लाभों की एक पूरी मेज़बानी भी मिलेगी, जिसे एक बार काम करने के बाद मैं कवर करूँगा।

प्रारंभिक व्यवस्था

यदि आप सीधे इसके कार्यशील उदाहरण में कूदना चाहते हैं, तो हमारे पास GitHub a पर उपलब्ध है डॉकर के लिए इन्फ्लक्सडीबी + टेलीग्राफ + ओकैम डेमो जिसे आप डॉकर कंपोज़ के साथ स्थानीय रूप से चला सकते हैं। यह स्टार्टअप स्क्रिप्ट में बदलाव के साथ इन्फ्लक्सडीबी और टेलीग्राफ के लिए आधिकारिक डॉकर छवियों का उपयोग करता है, इसलिए प्रत्येक सेवा कनेक्शन स्थापित करने के लिए ओकैम का उपयोग करती है। इसे कैसे चलाना है, इस पर पूर्ण निर्देश README में शामिल हैं।

InfluxDB में डेटा भेजने वाले क्लाइंट के एंड-टू-एंड उदाहरण का अनुकरण करने के लिए हम एक Telegraf उदाहरण शुरू करने जा रहे हैं, क्या यह CPU ईवेंट्स को InfluxDB में उत्सर्जित करता है, और फिर उन दोनों के कनेक्ट होने के तरीके को बदल देता है कि हम उन्हें कैसे कनेक्ट करेंगे विभिन्न मेजबानों या नेटवर्कों पर। हालांकि इस उदाहरण के लिए, हम सब कुछ एक मशीन पर चला रहे होंगे।

ओकाम

यदि आपने पहले ओकैम को सेटअप किया है तो आप इस सेक्शन को छोड़ सकते हैं और सीधे नीचे इन्फ्लक्सडीबी सेट अप करने के लिए आगे बढ़ सकते हैं।

 brew install build-trust/ockam/ockam

(यदि आप हमारे पास पैकेज प्रबंधन के लिए काढ़ा का उपयोग नहीं कर रहे हैं अन्य प्रणालियों के लिए स्थापना निर्देश हमारे दस्तावेज़ में)

एक बार इंस्टॉल हो जाने के बाद आपको ओकाम ऑर्केस्ट्रेटर के साथ अपनी स्थानीय पहचान को नामांकित करने की आवश्यकता है, नीचे दिए गए आदेश को चलाएं और दिए गए निर्देशों का पालन करें:

 ockam enroll

इन्फ्लक्सडीबी

यदि आपके पास पहले से ही आपकी स्थानीय मशीन पर InfluxDB चल रहा है और आपके पास एक प्रमाणीकरण टोकन है जिसे आप इसे लिखने के लिए उपयोग कर सकते हैं तो आप इस अनुभाग को छोड़ सकते हैं और सीधे नीचे टेलीग्राफ स्थापित करने के लिए आगे बढ़ सकते हैं।

इस खंड के लिए पूर्वापेक्षाएँ पहले स्थापित करने के लिए हैं:

• इन्फ्लक्सडीबी
• इन्फ्लक्स सीएलआई

एक बार स्थापित होने के बाद हमें InfluxDB शुरू करने की आवश्यकता है ताकि हमारे पास उत्पन्न होने वाले मेट्रिक्स डेटा को संग्रहीत करने के लिए कहीं न कहीं हो। अधिकांश सिस्टम पर जो चलने जितना आसान होगा:

 influxd

फिर आपको कुछ लॉग आउटपुट देखना चाहिए, जिसमें अंतिम पंक्ति यह पुष्टि करती है कि influxd अब पोर्ट 8086 पर सुन रहा है:

 2023-02-21T23:49:43.106268Z info Listening {"log_id": "0fv9CURl000", "service": "tcp-listener", "transport": "http", "addr": ":8086", "port": 8086}

यदि बाढ़ सफलतापूर्वक शुरू हो गई है तो आप एक नया टर्मिनल सत्र खोल सकते हैं और इसे पृष्ठभूमि में चलने के लिए छोड़ सकते हैं। यदि बाढ़ सफलतापूर्वक प्रारंभ नहीं हुई है तो जाँच करें कुछ सामान्य मुद्दों के लिए आधिकारिक दस्तावेज विभिन्न ऑपरेटिंग सिस्टम के लिए।

अब हम प्रारंभिक डेटाबेस सेटअप को पूरा करने के लिए इनफ़्लक्स सीएलआई कमांड का उपयोग करने जा रहे हैं ताकि इनफ़्लक्स हमारे डेटा को प्राप्त कर सके। सेटअप कमांड चलाएँ और आवश्यक संकेतों को पूरा करें, संगठन और बकेट नामों को याद रखें जिनका आप उपयोग करते हैं क्योंकि हमें बाद में उनकी आवश्यकता होगी:

 influx setup

इसके बाद आपको अपने द्वारा अभी बनाए गए उपयोगकर्ता के लिए टोकन कॉपी करने की आवश्यकता होगी, जिसे आप ऑथ कमांड से पुनः प्राप्त कर सकते हैं:

 influx auth list

Telegraf

टेलीग्राफ स्थापित करें , और एक बार यह सेटअप हो जाने के बाद हमें एक कॉन्फ़िगरेशन फ़ाइल की आवश्यकता होगी जो हमारे इनपुट स्रोत और हमारे आउटपुट गंतव्य को परिभाषित करती है। टेलीग्राफ में ऐसी फ़ाइल उत्पन्न करने के लिए धन्यवाद शामिल है, जिसे हम इनपुट स्रोत के रूप में और हमारे आउटपुट के रूप में इन्फ्लक्सडीबी के साथ हमारी मेजबान मशीन के सीपीयू उपयोग के साथ पूर्व-कॉन्फ़िगर करने के लिए निर्दिष्ट कर सकते हैं।

आधार कॉन्फ़िगरेशन चलाने के लिए:

 telegraf config \ --section-filter agent:inputs:outputs \ --input-filter cpu \ --output-filter influxdb_v2 > telegraf.conf

जनरेट हुई telegraf.conf फ़ाइल खोलें और [[outputs.influxdb_v2]] सेक्शन खोजें जो इस तरह दिखना चाहिए:

 [[outputs.influxdb_v2]] ## The URLs of the InfluxDB cluster nodes. ## ## Multiple URLs can be specified for a single cluster, only ONE of the ## urls will be written to each interval. ## ex: urls = ["https://us-west-2-1.aws.cloud2.influxdata.com"] urls = ["http://127.0.0.1:8086"] ## Token for authentication. token = "" ## Organization is the name of the organization you wish to write to. organization = "" ## Destination bucket to write into. bucket = ""

टोकन, संगठन और बकेट के लिए खाली मानों को पिछले अनुभाग के मानों से बदलें इन्फ्लक्सडीबी की स्थापना और परिवर्तन सहेजें। अब आप टेलीग्राफ शुरू कर सकते हैं:

 telegraf --config telegraf.conf

जांचें कि यह सब काम कर रहा है

भविष्य के आदेशों और परीक्षण के लिए अपने मूल्यों का पुन: उपयोग करना आसान बनाने के लिए, पर्यावरण चर की एक श्रृंखला में उपयुक्त मूल्यों (यानी, नीचे दिए गए प्लेसहोल्डर्स को अपने वास्तविक मूल्यों से बदलें) को स्टोर करें:

 export INFLUX_PORT=8086 \ INFLUX_TOKEN=your-token-here \ INFLUX_ORG=your-org \ INFLUX_BUCKET=your-bucket

अब हम देख सकते हैं कि टेलीग्राफ नियमित रूप से इन्फ्लक्सडीबी को डेटा भेज रहा है। हमारे द्वारा पहले बनाया गया कॉन्फ़िगरेशन प्रत्येक 10 सेकंड में CPU आँकड़े उत्सर्जित करेगा, इसलिए हम InfluxDB को एक क्वेरी भेज सकते हैं और इसे पिछले 1 मिनट के लिए सभी डेटा वापस करने के लिए भेज सकते हैं:

 curl \ --header "Authorization: Token $INFLUX_TOKEN" \ --header "Accept: application/csv" \ --header 'Content-type: application/vnd.flux' \ --data "from(bucket:\"$INFLUX_BUCKET\") |> range(start:-1m)" \ http://localhost:$INFLUX_PORT/api/v2/query?org=$INFLUX_ORG

टेलीग्राफ + एक निजी इन्फ्लक्सडीबी को ओकाम के साथ सुरक्षित रूप से कनेक्ट करें

उपरोक्त उदाहरण डिफ़ॉल्ट अनएन्क्रिप्टेड HTTP ट्रांसपोर्ट का उपयोग करके, एक ही होस्ट पर चल रही इन दो सेवाओं को जोड़ता है। अधिकांश गैर-तुच्छ कॉन्फ़िगरेशन में इन्फ्लक्सडीबी एक अलग होस्ट पर चल रहा होगा जिसमें एक या एक से अधिक टेलीग्राफ नोड डेटा भेज रहे हैं। उत्पादन में यह संभावना नहीं है कि एक अनएन्क्रिप्टेड परिवहन स्वीकार्य है, यह हमेशा सार्वजनिक इंटरनेट पर इन्फ्लक्सडीबी पोर्ट को संभावित रूप से उजागर करने के लिए वांछनीय नहीं है।

इस खंड में हम आपको दिखाएंगे कि किसी भी मौजूदा सेवा में बहुत कम कॉन्फ़िगरेशन परिवर्तनों के साथ इन दोनों समस्याओं को कैसे हल किया जा सकता है।

अपने नोड्स बनाना और नामांकन करना

पहला कदम ओकाम के साथ खुद को नामांकित करना है, अपनी परियोजना की जानकारी को सहेजना है, और अपने इन्फ्लक्सडीबी और टेलीग्राफ नोड्स के लिए नामांकन टोकन बनाना है:

 ockam enroll ockam project information --output json > project.json export OCKAM_INFLUXDB_TOKEN=$( \ ockam project enroll --attribute component=influxdb) export OCKAM_TELEGRAF_TOKEN=$( \ ockam project enroll --attribute component=telegraf)

अब हम अपनी InfluxDB सेवा के लिए एक नोड बना सकते हैं:

 ockam identity create influxdb ockam project authenticate --identity influxdb \ --token $OCKAM_INFLUXDB_TOKEN --project-path project.json ockam node create influxdb \ --project project.json \ --identity influxdb ockam policy set \ --at influxdb \ --resource tcp-outlet \ --expression '(= subject.component "telegraf")' ockam tcp-outlet create \ --at /node/influxdb \ --from /service/outlet \ --to 127.0.0.1:8086 ockam forwarder create influxdb \ --at /project/default \ --to /node/influxdb

उन कमांड्स में कुछ चीजें हुई हैं, तो आइए जल्दी से उन्हें अनपैक करें:

• हमने एक नया नोड बनाया है जिसे influxdb कहा जाता है, और इसे ओकाम के साथ उस टोकन का उपयोग करके नामांकित किया है जिसे हमने पहले उत्पन्न किया था। यदि आप उस आदेश को देखते हैं जो टोकन उत्पन्न करता है तो आप देखेंगे कि हमने इस टोकन को component=influxdb की विशेषता के साथ टैग किया है।
• इसके बाद हमने influxdb नोड में एक नीति जोड़ी, जिसमें कहा गया है कि केवल वे नोड जिनके पास telegraf के मूल्य के साथ एक component विशेषता है, टीसीपी आउटलेट से कनेक्ट करने में सक्षम होंगे।
• अगला हम एक टीसीपी आउटलेट बनाते हैं। यह influxdb नोड से एक पाइप की तरह है जिसे हमने अभी-अभी 127.0.0.1:8086 के TCP पोर्ट के लिए बनाया है (यानी, वह पोर्ट जिस पर हमारा InfluxDB डेटाबेस सुन रहा है)। यह ओकाम नोड अब अन्य नोड्स से प्राप्त होने वाले किसी भी डेटा को उस गंतव्य तक पाइप करेगा। हालाँकि केवल वे नोड जो उस कनेक्शन को स्थापित करने में सक्षम होंगे, जो पिछले चरण में परिभाषित नीति को पास करते हैं।
• अंत में हम अपने प्रोजेक्ट पर एक फारवर्डर बनाते हैं, जो अब हमारे प्रोजेक्ट में अन्य नोड्स को influxdb और रूट ट्रैफिक की खोज करने की अनुमति देता है।

टेलीग्राफ के लिए संबंधित क्लाइंट नोड बनाकर इस कनेक्शन के दूसरे पक्ष को स्थापित करने का समय आ गया है:

 ockam identity create telegraf ockam project authenticate --identity telegraf \ --token $OCKAM_TELEGRAF_TOKEN --project-path project.json ockam node create telegraf \ --project project.json \ --identity telegraf ockam policy set \ --at telegraf \ --resource tcp-inlet \ --expression '(= subject.component "influxdb")' ockam tcp-inlet create \ --at /node/telegraf \ --from 127.0.0.1:8087 \ --to /project/default/service/forward_to_influxdb/secure/api/service/outlet

अब हम इन तीन आदेशों को खोल सकते हैं और उन्होंने क्या किया है:

• पहले की तरह, हमने एक नया नोड बनाने के लिए जनरेट किए गए नामांकन टोकन का उपयोग किया है और इसे हमारे प्रोजेक्ट के साथ पंजीकृत किया है। इस बार यह telegraf नोड है।
• हमने अपनी सुरक्षा स्थिति में सुधार के लिए फिर से एक नीति लागू की है। यह नीति एक टीसीपी इनलेट बनाने की अनुमति देती है, लेकिन केवल तभी जब दूसरे छोर पर नोड में influxdb मान के साथ विशेषता component हो।
• अंत में हम टीसीपी इनलेट बनाते हैं। यह परिभाषित करने का एक तरीका है कि कनेक्शन के लिए नोड को कहाँ सुनना चाहिए (इस मामले में टीसीपी पोर्ट 8087 पर), और उस ट्रैफ़िक को कहाँ अग्रेषित करना चाहिए। यह नोड हमारे द्वारा पहले बनाए गए फ़ॉरवर्डर के माध्यम से डेटा को अग्रेषित करेगा, जो बदले में इसे हमारे इनफ़्लुक्सडीबी नोड में भेज देगा, जो इसे इन्फ़्लक्सडीबी डेटाबेस में भेजता है।

इतना ही! लोकलहोस्ट पोर्ट 8087 पर श्रोता अब सभी ट्रैफ़िक को InfluxDB पर भेज रहा है, जहाँ भी वह चल रहा है। यदि वह डेटाबेस एक अलग होस्ट पर था, जो क्लाउड में चल रहा था, या एक निजी डेटा केंद्र में नामांकन और अग्रेषण अभी भी सुनिश्चित करेगा कि 127.0.0.1:8087 के साथ हमारा संचार उस डेटाबेस से सुरक्षित रूप से जुड़ा रहेगा जहाँ भी डेटाबेस चल रहा है।

सुरक्षित कनेक्शन का उपयोग करने के लिए मौजूदा कॉन्फ़िगरेशन को अपडेट करें

इस उदाहरण ने मुख्य रूप से पोर्ट 8087 पर टीसीपी इनलेट बनाया क्योंकि इनफ्लक्सड सेवा उसी होस्ट पर चल रही थी और पहले से ही पोर्ट 8086 के लिए बाध्य थी। एक उत्पादन परिनियोजन में जहां टेलीग्राफ और इन्फ्लक्सडीबी अलग-अलग होस्ट पर हैं, टीसीपी इनलेट पोर्ट 8086 पर सुन सकता है और इस डिफ़ॉल्ट कॉन्फ़िगरेशन को बदलने की आवश्यकता नहीं होगी।

जबकि यह एक एकल होस्ट पर चलने वाला एक सरलीकृत उदाहरण है, आपकी तैनाती के बावजूद निम्नलिखित निर्देश समान हैं। एक बार influxdb और telegraf नोड्स के नामांकित होने और चलने के बाद, आपको केवल एक ही परिवर्तन करने की आवश्यकता है, जो कि आपके telegraf.conf को स्थानीय श्रवण पोर्ट को इंगित करने के लिए अपडेट करना है:

 [[outputs.influxdb_v2]] urls = ["http://127.0.0.1:8087"]

टेलीग्राफ सेवा को पुनरारंभ करें, और फिर हम जांच सकते हैं कि यह अभी भी उसी आदेश का उपयोग करके डेटा संग्रहीत कर रहा है जिसे हमने पहले उपयोग किया था। z

सुरक्षित रूप से कनेक्टेड क्लाइंट, और बहुत कुछ...

यहां दिए गए उदाहरण ने 10 मिनट से भी कम समय में हमारी सबसे गंभीर समस्या को हल कर दिया है, जबकि कई मूल्यवान सुधारों को जोड़ा है जो तुरंत स्पष्ट नहीं हैं क्योंकि उन्हें दूर कर दिया गया है:

• निजी डेटाबेस निजी रहते हैं: आपके इन्फ्लक्सडीबी का पोर्ट सार्वजनिक इंटरनेट के संपर्क में नहीं आया है, और इसलिए तीसरे पक्ष के लिए कोई मार्ग नहीं है

  
  

• ट्रांज़िट में एन्क्रिप्ट किया गया: आपके नोड्स के बीच स्थापित सुरक्षित चैनल एंड-टू-एंड एन्क्रिप्टेड है। प्रत्येक नोड अपनी स्वयं की क्रिप्टोग्राफ़िक कुंजियाँ उत्पन्न करता है, और अपनी अनूठी साख जारी की जाती है। इसके बाद वे एक दूसरे के बीच पारस्परिक रूप से भरोसेमंद सुरक्षित चैनल स्थापित करने के लिए इनका उपयोग करते हैं। कुंजियों को संग्रहीत या वितरित करने के लिए किसी तृतीय-पक्ष सेवा पर निर्भरता को हटाकर आप अपनी भेद्यता सतह क्षेत्र को कम करने और विफलता के एकल बिंदुओं को समाप्त करने में सक्षम हैं।

  
  

• पहचान और विशेषता आधारित अभिगम नियंत्रण: InfluxDB डेटाबेस के लिए एक मार्ग स्थापित करने के लिए प्राधिकरण, ग्राहक की विशिष्ट पहचान से जुड़ा हुआ है, जो आधुनिक और अक्सर गतिशील परिनियोजन दृष्टिकोणों के समर्थन के मामले में अधिक लचीला है और साथ ही अधिक स्पष्ट रूप से संरेखित करता है। अभिगम नियंत्रण के आसपास हमारे इरादे। यदि वे ग्राहक विश्वास स्थापित करने में सक्षम हैं कि वे वही हैं जो वे कहते हैं कि वे अपने पैकेट को डेटाबेस में रूट करने में सक्षम हैं। ऐतिहासिक दृष्टिकोणों की तुलना करें जो रिमोट नेटवर्क के बारे में धारणाओं के आधार पर स्थायी पहुंच निर्णय लेते हैं (उदाहरण के लिए यह अनुरोध आईपी एड्रेस से आ रहा है जिसे हमने पूर्व-अधिकृत किया है?)। यह इन्फ्लक्सडीबी डेटाबेस पर प्रमाणीकरण और प्राधिकरण नियंत्रण के अतिरिक्त है जो हमेशा की तरह काम करना जारी रखेगा।

  
  

• डिज़ाइन द्वारा सुरक्षित: उपरोक्त सभी के संयोजन का अर्थ है कि InfluxDB डेटाबेस तक पहुँचने का एकमात्र तरीका एक सुरक्षित चैनल पर है, जिसका अर्थ है कि किसी भी अंत में किसी भी गलत कॉन्फ़िगरेशन के बावजूद सभी संचार को एन्क्रिप्ट किया गया है (जैसे, HTTP / TLS) सक्षम नहीं किया जा रहा है)। और क्योंकि प्रत्येक नोड एक सामान्य प्रमाणपत्र या साझा एन्क्रिप्शन कुंजी साझा करने के बजाय एक दूसरे के साथ क्रेडेंशियल्स का आदान-प्रदान करता है, आप यह भी सुनिश्चित कर सकते हैं कि:

  
  

  1. आपूर्ति-श्रृंखला में कोई अन्य पक्ष ट्रांज़िट में डेटा को संशोधित करने में सक्षम नहीं है। आप उपभोक्ता को जो डेटा प्राप्त करते हैं, वह ठीक वही है जो आपके ग्राहकों द्वारा भेजा गया था।

  2. यह सुनिश्चित करने के लिए कि केवल अधिकृत ग्राहक ही InfluxDB को लिख सकते हैं, आपके विषय का डेटा अत्यधिक भरोसेमंद है। यदि आपकी और भी सख्त आवश्यकताएं हैं, तो आप अपने क्रेडेंशियल प्राधिकरण को नियंत्रित कर सकते हैं और व्यापक प्राधिकरण नीतियों को लागू कर सकते हैं।

     
     

• घटी भेद्यता सतह क्षेत्र: ओकाम सभी दूरस्थ सेवाओं को स्थानीय सेवाओं के रूप में उजागर करके ग्राहक पहुंच संबंधी चिंताओं को सरल करता है। हम इसे कहते हैं आभासी निकटता . जब किसी एप्लिकेशन के सभी दूरस्थ घटक लगभग हर दूसरे घटक के निकट हो जाते हैं, तो पूरे नेटवर्क की सुरक्षा और विश्वास की जटिलता, संपूर्ण बुनियादी ढाँचा, संपूर्ण इंटरनेट पूरी तरह से अलग हो जाता है। सभी तृतीय पक्ष मध्यस्थों को ऐप की भेद्यता सतह से हटा दिया गया है।

अगले कदम

• यदि आपने इस मार्गदर्शिका में दिए गए उदाहरण का अनुसरण नहीं किया है, तो आप कर सकते हैं ओकाम का प्रयोग शुरू करें हमारे दस्तावेज़ में दिए गए निर्देशों का पालन करके मुफ्त में।
• यदि आप विशेष रूप से इस बारे में या ओकाम के लिए अन्य संभावित उपयोग के मामलों के बारे में बात करना चाहते हैं, तो टीम को आपके साथ अधिक खुशी होगी। आपसे बात .
• वैकल्पिक रूप से आप हमारे साथ जुड़ सकते हैं, और डेवलपर्स के एक बढ़ते हुए समुदाय में शामिल हो सकते हैं जो सुरक्षित-दर-डिज़ाइन वाले एप्लिकेशन बनाकर विश्वास बनाना चाहते हैं। ट्रस्ट कम्युनिटी डिस्कॉर्ड सर्वर बनाएं या चालू Github .