និមិត្តសញ្ញា Juniper NETWORKSការណែនាំ API ស្ទ្រីម
បោះពុម្ពផ្សាយ
៨៦៦-៤៤៧-២១៩៤
ដោះលែង
4.2

មាតិកា លាក់
1 សេចក្តីផ្តើម
2 កំណត់រចនាសម្ព័ន្ធស្ទ្រីម API
3 ការប្រើប្រាស់ស្ទ្រីម API
4 ឯកសារ/ធនធាន
4.1 ឯកសារយោង

សេចក្តីផ្តើម

មគ្គុទ្ទេសក៍នេះពិពណ៌នាអំពីរបៀបទាញយកទិន្នន័យពី Paragon Active Assurance តាមរយៈ API ស្ទ្រីមរបស់ផលិតផល។
API ក៏ដូចជាកម្មវិធីចាក់ផ្សាយត្រូវបានរួមបញ្ចូលនៅក្នុងការដំឡើង Paragon Active Assurance។
ទោះយ៉ាងណាក៏ដោយ ការកំណត់រចនាសម្ព័ន្ធបន្តិចគឺចាំបាច់ មុនពេលអ្នកអាចប្រើ API ។ នេះត្រូវបានគ្របដណ្តប់នៅក្នុង "ការកំណត់រចនាសម្ព័ន្ធស្ទ្រីម API" នៅទំព័រ 1 ជំពូក។

កំណត់រចនាសម្ព័ន្ធស្ទ្រីម API

ជាងview
ជំពូកនេះពិពណ៌នាអំពីរបៀបកំណត់រចនាសម្ព័ន្ធស្ទ្រីម API ដើម្បីអនុញ្ញាតឱ្យជាវសារម៉ែត្រតាមរយៈ Kafka ។
pr
ខាងក្រោមនេះយើងនឹងឆ្លងកាត់៖

  • របៀបបើកស្ទ្រីម API
  • របៀបកំណត់ Kafka ដើម្បីស្តាប់អតិថិជនខាងក្រៅ
  • របៀបកំណត់ Kafka ដើម្បីប្រើ ACLs និងដំឡើងការអ៊ិនគ្រីប SSL សម្រាប់អតិថិជនដែលបាននិយាយ

Kafka គឺជាវេទិកាស្ទ្រីមព្រឹត្តិការណ៍ដែលអនុញ្ញាតឱ្យចាប់យកទិន្នន័យដែលបានផ្ញើពីប្រភពព្រឹត្តិការណ៍ផ្សេងៗ (ឧបករណ៍ចាប់សញ្ញា មូលដ្ឋានទិន្នន័យ ឧបករណ៍ចល័ត) ក្នុងទម្រង់នៃព្រឹត្តិការណ៍ស្ទ្រីម ក៏ដូចជាការរក្សាទុកជាប់លាប់នៃស្ទ្រីមព្រឹត្តិការណ៍ទាំងនេះសម្រាប់ការទាញយក និងរៀបចំនៅពេលក្រោយ។
ជាមួយ Kafka វាអាចធ្វើទៅបានដើម្បីគ្រប់គ្រងការផ្សាយព្រឹត្តិការណ៍ពីចុងដល់ចប់ក្នុងលក្ខណៈចែកចាយ ដែលអាចធ្វើមាត្រដ្ឋានបានខ្ពស់ បត់បែន អត់ធ្មត់ និងសុវត្ថិភាព។
ចំណាំ៖ Kafka អាច​ត្រូវ​បាន​កំណត់​រចនាសម្ព័ន្ធ​ក្នុង​វិធី​ផ្សេង​គ្នា​ជា​ច្រើន​និង​ត្រូវ​បាន​រចនា​ឡើង​សម្រាប់​ការ​ធ្វើ​មាត្រដ្ឋាន​និង​ប្រព័ន្ធ​ដែល​មិន​ប្រើ​ដដែល​។ ឯកសារនេះផ្តោតតែលើរបៀបកំណត់រចនាសម្ព័ន្ធវាដើម្បីប្រើប្រាស់មុខងារ Streaming API ដែលបានរកឃើញនៅក្នុង Paragon Active Assurance Control Center។ សម្រាប់ការដំឡើងកម្រិតខ្ពស់បន្ថែមទៀត យើងយោងទៅលើឯកសារផ្លូវការរបស់ Kafka៖ kafka.apache.org/26/documentation.html.

វាក្យសព្ទ

  • Kafka: វេទិកាស្ទ្រីមព្រឹត្តិការណ៍។
  • ប្រធានបទ Kafka៖ ការប្រមូលព្រឹត្តិការណ៍។
  • អតិថិជន/អ្នកប្រើប្រាស់ Kafka៖ ធាតុផ្សំដែលទទួលខុសត្រូវចំពោះការទាញយកព្រឹត្តិការណ៍ដែលបានរក្សាទុកនៅក្នុងប្រធានបទ Kafka។
  • ឈ្មួញកណ្តាល Kafka៖ ម៉ាស៊ីនមេស្រទាប់ផ្ទុកនៃចង្កោម Kafka ។
  • SSL/TLS៖ SSL គឺជាពិធីការសុវត្ថិភាពដែលត្រូវបានបង្កើតឡើងសម្រាប់បញ្ជូនព័ត៌មានប្រកបដោយសុវត្ថិភាពតាមអ៊ីនធឺណិត។ TLS គឺជាអ្នកស្នងតំណែងរបស់ SSL ដែលបានណែនាំក្នុងឆ្នាំ 1999 ។
  • SASL៖ ក្របខ័ណ្ឌដែលផ្តល់យន្តការសម្រាប់ការផ្ទៀងផ្ទាត់អ្នកប្រើប្រាស់ ការត្រួតពិនិត្យភាពត្រឹមត្រូវនៃទិន្នន័យ និងការអ៊ិនគ្រីប។
  • អ្នកជាវ API ស្ទ្រីម៖ ធាតុផ្សំដែលទទួលខុសត្រូវចំពោះការទាញយកព្រឹត្តិការណ៍ដែលបានរក្សាទុកនៅក្នុងប្រធានបទដែលបានកំណត់នៅក្នុង Paragon Active Assurance និងមានន័យថាសម្រាប់ការចូលប្រើខាងក្រៅ។
  • អាជ្ញាធរវិញ្ញាបនបត្រ៖ អង្គភាពដែលអាចទុកចិត្តបានដែលចេញ និងដកហូតវិញ្ញាបនបត្រសោសាធារណៈ។
  • វិញ្ញាបនបត្ររបស់អាជ្ញាធរវិញ្ញាបនប័ត្រ៖ វិញ្ញាបនបត្រសោសាធារណៈដែលកំណត់អត្តសញ្ញាណអាជ្ញាធរវិញ្ញាបនបត្រ។

របៀបដែលស្ទ្រីម API ដំណើរការ
ដូចដែលបានបញ្ជាក់ពីមុន ស្ទ្រីម API អនុញ្ញាតឱ្យអតិថិជនខាងក្រៅទាញយកព័ត៌មានអំពីម៉ែត្រពី Kafka ។
រាល់ការវាស់វែងដែលប្រមូលបានដោយភ្នាក់ងារសាកល្បង កំឡុងពេលធ្វើតេស្ត ឬត្រួតពិនិត្យភារកិច្ចត្រូវបានបញ្ជូនទៅសេវាកម្មស្ទ្រីម។
បន្ទាប់ពីដំណាក់កាលដំណើរការ សេវាកម្មស្ទ្រីមបោះពុម្ពផ្សាយម៉ែត្រទាំងនោះនៅលើ Kafka រួមជាមួយនឹងទិន្នន័យមេតាបន្ថែម។Juniper NETWORKS Streaming API Active Assurance - របៀបស្ទ្រីម API ដំណើរការប្រធានបទ Kafka
Kafka មានគំនិតនៃប្រធានបទដែលទិន្នន័យទាំងអស់ត្រូវបានបោះពុម្ព។ នៅក្នុង Paragon Active Assurance មានប្រធានបទ Kafka ជាច្រើនដែលមាន។ ទោះយ៉ាងណាក៏ដោយ មានតែផ្នែករងនៃវត្ថុទាំងនេះប៉ុណ្ណោះដែលមានន័យសម្រាប់ការចូលប្រើខាងក្រៅ។
គណនី Paragon Active Assurance នីមួយៗនៅក្នុង Control Center មានប្រធានបទពីរ។ ខាងក្រោម ACCOUNT គឺជាឈ្មោះខ្លីនៃគណនី៖

  • paa.public.accounts.{ACCOUNT}.metrics
  • សារម៉ែត្រទាំងអស់សម្រាប់គណនីដែលបានផ្តល់ឱ្យត្រូវបានបោះពុម្ពផ្សាយចំពោះប្រធានបទនេះ។
  • ចំនួនដ៏ធំនៃទិន្នន័យ
  • ប្រេកង់អាប់ដេតខ្ពស់។
  • paa.public.accounts.{ACCOUNT}.ទិន្នន័យមេតា
  • មានទិន្នន័យមេតាដែលទាក់ទងនឹងទិន្នន័យម៉ែត្រ ឧទាហរណ៍ample តេស្ត ម៉ូនីទ័រ ឬភ្នាក់ងារតេស្តដែលភ្ជាប់ជាមួយម៉ែត្រ
  • ចំនួនតូចនៃទិន្នន័យ
  • ប្រេកង់អាប់ដេតទាប

បើកដំណើរការស្ទ្រីម API
ចំណាំ៖ ការណែនាំទាំងនេះគឺត្រូវដំណើរការនៅលើម៉ាស៊ីនមេរបស់មជ្ឈមណ្ឌលបញ្ជាដោយប្រើ sudo ។
ដោយសារស្ទ្រីម API បន្ថែមផ្នែកខ្លះទៅមជ្ឈមណ្ឌលបញ្ជា វាមិនត្រូវបានបើកតាមលំនាំដើមទេ។ ដើម្បីបើក API ដំបូងយើងត្រូវបើកការបោះពុម្ពម៉ែត្រទៅ Kafka នៅក្នុងការកំណត់សំខាន់ file:

  • /etc/netrounds/netrounds.conf

KAFKA_METRICS_ENABLED = ពិត
ព្រមាន៖ ការបើកមុខងារនេះអាចប៉ះពាល់ដល់ដំណើរការរបស់មជ្ឈមណ្ឌលបញ្ជា។ ត្រូវប្រាកដថាអ្នកបានកំណត់ទំហំឧទាហរណ៍របស់អ្នកស្របតាម។
បន្ទាប់ ដើម្បីបើកការបញ្ជូនបន្តរង្វាស់ទាំងនេះទៅកាន់ប្រធានបទ Kafka ត្រឹមត្រូវ៖

  • /etc/netrounds/metrics.yaml

streaming-api៖ ពិត
ដើម្បីបើក និងចាប់ផ្តើមសេវាកម្មស្ទ្រីម API សូមដំណើរការ៖
សេវាកម្ម sudo ncc បើកការវាស់វែង timescaledb
សេវាកម្ម sudo ncc ចាប់ផ្តើមការវាស់វែង timescaledb
ជាចុងក្រោយ ចាប់ផ្តើមសេវាកម្មឡើងវិញ៖
សេវាកម្ម sudo ncc ចាប់ផ្តើមឡើងវិញ
ការផ្ទៀងផ្ទាត់ថាស្ទ្រីម API ដំណើរការនៅក្នុងមជ្ឈមណ្ឌលបញ្ជា
ចំណាំ៖ ការណែនាំទាំងនេះគឺត្រូវដំណើរការនៅលើម៉ាស៊ីនមេរបស់មជ្ឈមណ្ឌលបញ្ជា។
ឥឡូវនេះអ្នកអាចផ្ទៀងផ្ទាត់ថាអ្នកកំពុងទទួលបានម៉ែត្រនៅលើប្រធានបទ Kafka ត្រឹមត្រូវ។ ដើម្បីធ្វើដូច្នេះ សូមដំឡើងឧបករណ៍ប្រើប្រាស់ kafkacat៖
sudo apt-get ធ្វើបច្ចុប្បន្នភាព
sudo apt-get ដំឡើង kafkacat
ប្រសិនបើអ្នកមានការសាកល្បង ឬម៉ូនីទ័រដែលកំពុងដំណើរការនៅក្នុងមជ្ឈមណ្ឌលបញ្ជា អ្នកគួរតែអាចប្រើ kafkacat ដើម្បីទទួលបានម៉ែត្រ និងទិន្នន័យមេតាលើប្រធានបទទាំងនេះ។
ជំនួសគណនីរបស់ខ្ញុំដោយឈ្មោះខ្លីនៃគណនីរបស់អ្នក (នេះជាអ្វីដែលអ្នកឃើញនៅក្នុងមជ្ឈមណ្ឌលបញ្ជារបស់អ្នក។ URL):
នាំចេញ METRICS_TOPIC=paa.public.accounts.myaccount.metrics
នាំចេញ METADATA_TOPIC=paa.public.accounts.myaccount.metadata
ឥឡូវនេះ អ្នកគួរតែឃើញម៉ែត្រដោយដំណើរការពាក្យបញ្ជានេះ៖
kafkacat -b ${KAFKA_FQDN}:9092 -t ${METRICS_TOPIC} -C -e
ទៅ view ទិន្នន័យមេតា ដំណើរការពាក្យបញ្ជាខាងក្រោម (ចំណាំថាវានឹងមិនធ្វើបច្ចុប្បន្នភាពញឹកញាប់ទេ)៖
kafkacat -b ${KAFKA_FQDN}:9092 -t ${METADATA_TOPIC} -C -e
ចំណាំ៖
kafkacat”អតីតអតិថិជនamples” នៅទំព័រ 14
វាផ្ទៀងផ្ទាត់ថាយើងមាន API ស្ទ្រីមដែលកំពុងដំណើរការពីក្នុងមជ្ឈមណ្ឌលបញ្ជា។ ទោះយ៉ាងណាក៏ដោយ ភាគច្រើនទំនងជាអ្នកចាប់អារម្មណ៍ក្នុងការចូលប្រើទិន្នន័យពីម៉ាស៊ីនភ្ញៀវខាងក្រៅជំនួសវិញ។ ផ្នែកបន្ទាប់ពិពណ៌នាអំពីរបៀបបើក Kafka សម្រាប់ការចូលប្រើខាងក្រៅ។
បើក Kafka សម្រាប់ម៉ាស៊ីនខាងក្រៅ
ចំណាំ៖ ការណែនាំទាំងនេះគឺត្រូវដំណើរការនៅលើម៉ាស៊ីនមេរបស់មជ្ឈមណ្ឌលបញ្ជា។
តាមលំនាំដើម Kafka ដែលដំណើរការនៅលើមជ្ឈមណ្ឌលបញ្ជាត្រូវបានកំណត់រចនាសម្ព័ន្ធដើម្បីស្តាប់តែនៅលើម៉ាស៊ីនមូលដ្ឋានសម្រាប់ការប្រើប្រាស់ផ្ទៃក្នុងប៉ុណ្ណោះ។
វាអាចធ្វើទៅបានដើម្បីបើក Kafka សម្រាប់អតិថិជនខាងក្រៅដោយការកែប្រែការកំណត់ Kafka ។
ការតភ្ជាប់ទៅ Kafka: ការព្រមាន
Juniper NETWORKS Streaming API Active Assurance - និមិត្តសញ្ញា ប្រយ័ត្ន៖ សូមអានវាដោយយកចិត្តទុកដាក់ ព្រោះវាងាយស្រួលក្នុងការដោះស្រាយបញ្ហាទាក់ទងនឹង Kafka ប្រសិនបើអ្នកមិនទាន់យល់អំពីគោលគំនិតទាំងនេះ។
នៅក្នុងការរៀបចំមជ្ឈមណ្ឌលបញ្ជាដែលបានពិពណ៌នានៅក្នុងឯកសារនេះ មានតែឈ្មួញកណ្តាល Kafka តែមួយប៉ុណ្ណោះ។
ទោះជាយ៉ាងណាក៏ដោយ ចំណាំថាឈ្មួញកណ្តាល Kafka មានបំណងដំណើរការជាផ្នែកមួយនៃក្រុម Kafka ដែលអាចមានឈ្មួញកណ្តាល Kafka ជាច្រើន។
នៅពេលភ្ជាប់ទៅឈ្មួញកណ្តាល Kafka ការតភ្ជាប់ដំបូងត្រូវបានបង្កើតឡើងដោយអតិថិជន Kafka ។ ជុំវិញការតភ្ជាប់នេះ ឈ្មួញកណ្តាល Kafka នឹងត្រឡប់បញ្ជីឈ្មោះ "អ្នកស្តាប់ដែលបានផ្សព្វផ្សាយ" ដែលជាបញ្ជីនៃឈ្មួញកណ្តាល Kafka មួយ ឬច្រើន។
នៅពេលទទួលបានបញ្ជីនេះ អតិថិជន Kafka នឹងផ្តាច់ទំនាក់ទំនង បន្ទាប់មកភ្ជាប់ទៅអ្នកស្តាប់ដែលបានផ្សាយពាណិជ្ជកម្មទាំងនេះឡើងវិញ។ អ្នកស្តាប់ដែលបានផ្សាយពាណិជ្ជកម្មត្រូវតែមានឈ្មោះម៉ាស៊ីន ឬអាសយដ្ឋាន IP ដែលអាចចូលប្រើបានដោយម៉ាស៊ីនភ្ញៀវ Kafka បើមិនដូច្នោះទេ ម៉ាស៊ីនភ្ញៀវនឹងបរាជ័យក្នុងការតភ្ជាប់។
ប្រសិនបើការអ៊ិនគ្រីប SSL ត្រូវបានប្រើ ពាក់ព័ន្ធនឹងវិញ្ញាបនបត្រ SSL ដែលត្រូវបានចងភ្ជាប់ទៅនឹងឈ្មោះម៉ាស៊ីនជាក់លាក់មួយ វាកាន់តែសំខាន់ដែលម៉ាស៊ីនភ្ញៀវ Kafka ទទួលបានអាសយដ្ឋានត្រឹមត្រូវដើម្បីភ្ជាប់ទៅ ព្រោះបើមិនដូច្នេះទេ ការភ្ជាប់អាចត្រូវបានបដិសេធ។
សូមអានបន្ថែមអំពីអ្នកស្តាប់ Kafka នៅទីនេះ៖ www.confluent.io/blog/kafka-listeners-explained
ការអ៊ិនគ្រីប SSL/TLSE
ដើម្បីប្រាកដថាមានតែអតិថិជនដែលជឿទុកចិត្តប៉ុណ្ណោះដែលត្រូវបានអនុញ្ញាតឱ្យចូលប្រើ Kafka និង Streaming API យើងត្រូវកំណត់រចនាសម្ព័ន្ធដូចខាងក្រោម៖

  • ការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវ៖ អតិថិជនត្រូវតែផ្តល់ឈ្មោះអ្នកប្រើប្រាស់ និងពាក្យសម្ងាត់តាមរយៈការតភ្ជាប់សុវត្ថិភាព SSL/TLS រវាងម៉ាស៊ីនភ្ញៀវ និង Kafka។
  • ការអនុញ្ញាត៖ អតិថិជនដែលបានផ្ទៀងផ្ទាត់អាចអនុវត្តការងារដែលគ្រប់គ្រងដោយ ACLs ។

នេះគឺចប់ហើយ។view:
Juniper NETWORKS Streaming API Active Assurance - របៀបស្ទ្រីម API ដំណើរការ 1*) ការ​ផ្ទៀងផ្ទាត់​ឈ្មោះ​អ្នក​ប្រើ / ពាក្យ​សម្ងាត់​បាន​ធ្វើ​នៅ​លើ​ឆានែល​ដែល​បាន​អ៊ិនគ្រីប SSL

ដើម្បីយល់ច្បាស់អំពីរបៀបដែលការអ៊ិនគ្រីប SSL/TLS ដំណើរការសម្រាប់ Kafka សូមមើលឯកសារផ្លូវការ៖ docs.confluent.io/platform/current/kafka/encryption.html
វិញ្ញាបនបត្រ SSL/TLS បានបញ្ចប់view
ចំណាំ៖ នៅក្នុងផ្នែករងនេះ យើងនឹងប្រើវាក្យស័ព្ទខាងក្រោម៖
វិញ្ញាបនបត្រ៖ វិញ្ញាបនបត្រ SSL ដែលចុះហត្ថលេខាដោយអាជ្ញាធរវិញ្ញាបនប័ត្រ (CA)។ ឈ្មួញកណ្តាល Kafka នីមួយៗមានមួយ។
ឃ្លាំងសម្ងាត់៖ ឃ្លាំងសម្ងាត់ file ដែលរក្សាទុកវិញ្ញាបនបត្រ។ ឃ្លាំងសម្ងាត់ file មានសោឯកជននៃវិញ្ញាបនបត្រ; ដូច្នេះ ចាំបាច់ត្រូវរក្សាទុកដោយសុវត្ថិភាព។
ហាង​លក់​ទំនិញ៖ ក file មានវិញ្ញាបនបត្រ CA ដែលអាចទុកចិត្តបាន។
ដើម្បីរៀបចំការផ្ទៀងផ្ទាត់រវាងម៉ាស៊ីនភ្ញៀវខាងក្រៅ និង Kafka ដែលដំណើរការនៅក្នុងមជ្ឈមណ្ឌលបញ្ជា ភាគីទាំងពីរត្រូវតែមានឃ្លាំងសម្ងាត់ដែលបានកំណត់ជាមួយនឹងវិញ្ញាបនបត្រដែលពាក់ព័ន្ធដែលបានចុះហត្ថលេខាដោយអាជ្ញាធរវិញ្ញាបនបត្រ (CA) រួមជាមួយនឹងវិញ្ញាបនបត្រឫសគល់ CA ។
បន្ថែមពីលើនេះ អតិថិជនក៏ត្រូវតែមាន truststore ដែលមានវិញ្ញាបនបត្រ root CA ផងដែរ។
វិញ្ញាបនបត្រឫសគល់ CA គឺជារឿងធម្មតាសម្រាប់ឈ្មួញកណ្តាល Kafka និងអតិថិជន Kafka ។
ការបង្កើតវិញ្ញាបនបត្រដែលត្រូវការ
នេះត្រូវបានរៀបរាប់នៅក្នុង “ឧបសម្ព័ន្ធ” នៅទំព័រ ១៧។
ការកំណត់រចនាសម្ព័ន្ធ Kafka Broker SSL/TLS នៅក្នុងមជ្ឈមណ្ឌលបញ្ជា
ចំណាំ៖ ការណែនាំទាំងនេះគឺត្រូវដំណើរការនៅលើម៉ាស៊ីនមេរបស់មជ្ឈមណ្ឌលបញ្ជា។
ចំណាំ៖ មុននឹងបន្ត អ្នកត្រូវតែបង្កើត keystore ដែលមានវិញ្ញាបនបត្រ SSL ដោយធ្វើតាមការណែនាំនៅក្នុង "ឧបសម្ព័ន្ធ" នៅទំព័រ 17។ ផ្លូវដែលបានរៀបរាប់ខាងក្រោមបានមកពីការណែនាំទាំងនេះ។
ឃ្លាំងសម្ងាត់ SSL គឺ ក file រក្សាទុកនៅលើថាសជាមួយ file ផ្នែកបន្ថែម .jks ។
នៅពេលដែលអ្នកមានវិញ្ញាបនបត្រដែលត្រូវការត្រូវបានបង្កើតឡើងសម្រាប់ទាំងឈ្មួញកណ្តាល Kafka និងអតិថិជន Kafka ដែលអាចប្រើបាន អ្នកអាចបន្តដោយកំណត់រចនាសម្ព័ន្ធឈ្មួញកណ្តាល Kafka ដែលដំណើរការនៅក្នុងមជ្ឈមណ្ឌលបញ្ជា។ អ្នកត្រូវដឹងដូចខាងក្រោម៖

  • ៖ ឈ្មោះម៉ាស៊ីនសាធារណៈរបស់មជ្ឈមណ្ឌលបញ្ជា; នេះត្រូវតែអាចដោះស្រាយបាន និងអាចចូលដំណើរការបានដោយអតិថិជន Kafka ។
  • ៖ ពាក្យ​សម្ងាត់​ឃ្លាំង​សម្ងាត់​ដែល​បាន​ផ្ដល់​ពេល​បង្កើត​វិញ្ញាបនបត្រ SSL ។
  • និង ៖ ទាំងនេះគឺជាពាក្យសម្ងាត់ដែលអ្នកចង់កំណត់សម្រាប់អ្នកគ្រប់គ្រង និងអ្នកប្រើប្រាស់អតិថិជនរៀងៗខ្លួន។ ចំណាំថាអ្នកអាចបន្ថែមអ្នកប្រើប្រាស់បន្ថែមទៀត ដូចដែលបានបញ្ជាក់នៅក្នុង exampលេ

កែសម្រួល ឬបន្ថែម (ជាមួយការចូលប្រើ sudo) លក្ខណៈសម្បត្តិខាងក្រោមក្នុង /etc/kafka/server.properties ដោយបញ្ចូលអថេរខាងលើដូចបានបង្ហាញ៖
Juniper NETWORKS Streaming API Active Assurance - និមិត្តសញ្ញា ព្រមាន៖ កុំដក PLAINTEXT://localhost:9092; វានឹងធ្វើឱ្យខូចមុខងាររបស់មជ្ឈមណ្ឌលបញ្ជា ដោយសារសេវាកម្មខាងក្នុងនឹងមិនអាចទំនាក់ទំនងបានទេ។

…
# អាសយដ្ឋានដែលឈ្មួញកណ្តាល Kafka ស្តាប់។
listeners=PLAINTEXT://localhost:9092,SASL_SSL://0.0.0.0:9093
# ទាំងនេះគឺជាម៉ាស៊ីនដែលបានផ្សព្វផ្សាយត្រឡប់ទៅអតិថិជនណាមួយដែលភ្ជាប់។
advertised.listeners=PLAINTEXT://localhost:9092,SASL_SSL:// ៖ ៩០៩៣
…
####### កំណត់រចនាសម្ព័ន្ធផ្ទាល់ខ្លួន
# ការកំណត់ SSL
ssl.endpoint.identification.algorithm=
ssl.keystore.location=/var/ssl/private/kafka.server.keystore.jks
ssl.keystore.password=
ssl.key.password=
ssl.client.auth=គ្មាន
ssl.protocol=TLSv1.2
# ការកំណត់រចនាសម្ព័ន្ធ SASL
sasl.enabled.mechanisms=PLAIN
listener.name.sasl_ssl.plain.sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginMo
dule ទាមទារ \\
username=”admin” \\
ពាក្យសម្ងាត់ =” ” \
user_admin=” ” \
user_client=” ”;
# ចំណាំ អ្នកប្រើប្រាស់អាចបន្ថែមជាមួយ user_ =
# ការអនុញ្ញាត បើក ACLs
authorizer.class.name=kafka.security.authorizer.AclAuthorizer
super.users=អ្នកប្រើប្រាស់:admin

ការដំឡើងបញ្ជីត្រួតពិនិត្យការចូលប្រើ (ACLs)
បើក ACLs នៅលើម៉ាស៊ីនមូលដ្ឋាន
Juniper NETWORKS Streaming API Active Assurance - និមិត្តសញ្ញា ព្រមាន៖ ដំបូងយើងត្រូវរៀបចំ ACLs សម្រាប់ localhost ដូច្នេះ Control Center ខ្លួនឯងនៅតែអាចចូលប្រើ Kafka បាន។ ប្រសិនបើរឿងនេះមិនត្រូវបានធ្វើទេ អ្វីៗនឹងខូច។

######### ធាតុ ACLs សម្រាប់អ្នកប្រើប្រាស់អនាមិក
/usr/lib/kafka/bin/kafka-acls.sh \\
-authorizer kafka.security.authorizer.AclAuthorizer \\
–authorizer-properties zookeeper.connect=localhost:2181 \\
-add -allow-principal User: ANONYMOUS -allow-host 127.0.0.1 -cluster
/usr/lib/kafka/bin/kafka-acls.sh \\
-authorizer kafka.security.authorizer.AclAuthorizer \\
–authorizer-properties zookeeper.connect=localhost:2181 \\
–add –allow-principal User: ANONYMOUS –allow-host 127.0.0.1 –topic '*'
/usr/lib/kafka/bin/kafka-acls.sh \\
-authorizer kafka.security.authorizer.AclAuthorizer \\
–authorizer-properties zookeeper.connect=localhost:2181 \\
–add –allow-principal User: ANONYMOUS –allow-host 127.0.0.1 –group '*'

បន្ទាប់មកយើងត្រូវបើក ​​ACLs សម្រាប់ការចូលប្រើបានតែអានខាងក្រៅ ដូច្នេះអ្នកប្រើប្រាស់ខាងក្រៅត្រូវបានអនុញ្ញាតឱ្យអានប្រធានបទ paa.public.* ។
ចំណាំ៖ សម្រាប់ការគ្រប់គ្រងល្អិតល្អន់ សូមមើលឯកសារផ្លូវការរបស់ Kafka ។

######### ធាតុ ACLs សម្រាប់អ្នកប្រើប្រាស់ខាងក្រៅ
/usr/lib/kafka/bin/kafka-acls.sh \\
-authorizer kafka.security.authorizer.AclAuthorizer \\
–authorizer-properties zookeeper.connect=localhost:2181 \\
–add –allow-principal User:* –operation read –operation describe \
- ក្រុម 'NCC'
/usr/lib/kafka/bin/kafka-acls.sh \\
-authorizer kafka.security.authorizer.AclAuthorizer \\
–authorizer-properties zookeeper.connect=localhost:2181 \\
–add –allow-principal User:* –operation read –operation describe \
- ប្រធានបទ paa.public ។ -resource-pattern-type បុព្វបទ

នៅពេលរួចរាល់ហើយ អ្នកត្រូវចាប់ផ្តើមសេវាកម្មឡើងវិញ៖
សេវាកម្ម sudo ncc ចាប់ផ្តើមឡើងវិញ
ដើម្បីផ្ទៀងផ្ទាត់ថាម៉ាស៊ីនភ្ញៀវអាចបង្កើតការតភ្ជាប់សុវត្ថិភាព ដំណើរការពាក្យបញ្ជាខាងក្រោមនៅលើកុំព្យូទ័រម៉ាស៊ីនភ្ញៀវខាងក្រៅ (មិនមែននៅលើម៉ាស៊ីនមេរបស់មជ្ឈមណ្ឌលបញ្ជាទេ)។ ខាងក្រោម PUBLIC_HOSTNAME គឺជាឈ្មោះម៉ាស៊ីនរបស់មជ្ឈមណ្ឌលបញ្ជា៖
openssl s_client -debug -connect ${PUBLIC_HOSTNAME}:9093 -tls1_2 | grep "ការចរចាឡើងវិញដោយសុវត្ថិភាព IS ត្រូវបានគាំទ្រ"
នៅក្នុងលទ្ធផលពាក្យបញ្ជា អ្នកគួរតែឃើញវិញ្ញាបនបត្រម៉ាស៊ីនមេ ក៏ដូចជាដូចខាងក្រោម៖
ការចរចាឡើងវិញដោយសុវត្ថិភាព IS ត្រូវបានគាំទ្រ
ដើម្បីធានាថាសេវាកម្មខាងក្នុងត្រូវបានផ្តល់សិទ្ធិចូលប្រើម៉ាស៊ីនមេ Kafka សូមពិនិត្យមើលកំណត់ហេតុខាងក្រោមfiles:

  • /var/log/kafka/server.log
  • /var/log/kafka/kafka-authorizer.log

ធ្វើ​ឱ្យ​មាន​សុពលភាព​ការ​តភ្ជាប់​អតិថិជន​ខាងក្រៅ
កាហ្វកាកាត
ចំណាំ៖ ការណែនាំទាំងនេះគឺត្រូវដំណើរការលើកុំព្យូទ័រអតិថិជន (មិនមែននៅលើម៉ាស៊ីនមេរបស់មជ្ឈមណ្ឌលបញ្ជាទេ)។
ចំណាំ៖ ដើម្បីបង្ហាញព័ត៌មានអំពីម៉ែត្រ សូមប្រាកដថាម៉ូនីទ័រយ៉ាងហោចណាស់មួយកំពុងដំណើរការនៅក្នុងមជ្ឈមណ្ឌលបញ្ជា។
ដើម្បីផ្ទៀងផ្ទាត់ និងផ្ទៀងផ្ទាត់ការតភ្ជាប់ជាម៉ាស៊ីនភ្ញៀវខាងក្រៅ វាអាចប្រើឧបករណ៍ប្រើប្រាស់ kafkacat ដែលត្រូវបានដំឡើងនៅក្នុងផ្នែក "ផ្ទៀងផ្ទាត់ថាស្ទ្រីម API ដំណើរការនៅក្នុងមជ្ឈមណ្ឌលបញ្ជា" នៅទំព័រទី 4 ។
អនុវត្តជំហានដូចខាងក្រោមៈ
ចំណាំ៖ ខាងក្រោម CLIENT_USER គឺជាអ្នកប្រើប្រាស់ដែលបានបញ្ជាក់ពីមុននៅក្នុង file /etc/kafka/server.properties ក្នុង Control Center៖ គឺ user_client និងពាក្យសម្ងាត់ដែលបានកំណត់នៅទីនោះ។
វិញ្ញាបនបត្រឫសគល់ CA ដែលប្រើដើម្បីចុះហត្ថលេខាលើវិញ្ញាបនបត្រ SSL ខាងម៉ាស៊ីនមេត្រូវតែមានវត្តមាននៅលើម៉ាស៊ីនភ្ញៀវ។

  • បង្កើត ក file client.properties ដែលមានខ្លឹមសារដូចខាងក្រោម៖

security.protocol=SASL_SSL
ssl.ca.location={PATH_TO_CA_CERT}
sasl.mechanisms=PLAIN
sasl.username={CLIENT_USER}
sasl.password={CLIENT_PASSWORD}
កន្លែងណា

  • {PATH_TO_CA_CERT} គឺជាទីតាំងនៃវិញ្ញាបនបត្រឫសគល់ CA ដែលប្រើដោយឈ្មួញកណ្តាល Kafka
  • {CLIENT_USER} និង {CLIENT_PASSWORD} គឺជាអត្តសញ្ញាណអ្នកប្រើប្រាស់សម្រាប់អតិថិជន។
  • ដំណើរការពាក្យបញ្ជាខាងក្រោមដើម្បីមើលសារដែលប្រើប្រាស់ដោយ kafkacat៖

នាំចេញ KAFKA_FQDN=
នាំចេញ METRICS_TOPIC=paa.public.accounts។ .ម៉ែត្រ
kafkacat -b ${KAFKA_FQDN}:9093 -F client.properties -t ${METRICS_TOPIC} -C -e
ដែល {METRICS_TOPIC} គឺជាឈ្មោះប្រធានបទ Kafka ដែលមានបុព្វបទ “paa.public”។

ចំណាំ៖ កំណែចាស់របស់ kafkacat មិនផ្តល់ជម្រើស -F សម្រាប់អានការកំណត់ម៉ាស៊ីនភ្ញៀវពី a file. ប្រសិនបើអ្នកកំពុងប្រើកំណែបែបនេះ អ្នកត្រូវតែផ្តល់ការកំណត់ដូចគ្នាពីបន្ទាត់ពាក្យបញ្ជាដូចបានបង្ហាញខាងក្រោម។

kafkacat -b ${KAFKA_FQDN}:9093 \\
-X security.protocol=SASL_SSL \\
-X ssl.ca.location={PATH_TO_CA_CERT} \\
-X sasl.mechanisms=PLAIN \\
-X sasl.username={CLIENT_USER} \\
-X sasl.password={CLIENT_PASSWORD} \\
-t ${METRICS_TOPIC} -C -e
ដើម្បីបំបាត់កំហុសការតភ្ជាប់ អ្នកអាចប្រើជម្រើស -d៖

បំបាត់កំហុសទំនាក់ទំនងអ្នកប្រើប្រាស់
kafkacat -d អ្នកប្រើប្រាស់ -b ${KAFKA_FQDN}:9093 -F client.properties -t ${METRICS_TOPIC} -C -e
# បំបាត់កំហុសទំនាក់ទំនងឈ្មួញកណ្តាល
kafkacat -d ឈ្មួញកណ្តាល -b ${KAFKA_FQDN}:9093 -F client.properties -t ${METRICS_TOPIC} -C -e

ត្រូវប្រាកដថាយោងទៅឯកសារសម្រាប់បណ្ណាល័យម៉ាស៊ីនភ្ញៀវ Kafka ដែលកំពុងប្រើប្រាស់ ដោយសារលក្ខណៈសម្បត្តិអាចខុសគ្នាពីឯកសារនៅក្នុង client.properties ។
ទម្រង់សារ
សារដែលប្រើសម្រាប់ប្រធានបទម៉ែត្រ និងទិន្នន័យមេតាត្រូវបានដាក់សៀរៀលក្នុងទម្រង់ Protocol buffers (protobuf) (សូមមើល developers.google.com/protocol-buffers) គ្រោងការណ៍សម្រាប់សារទាំងនេះប្រកាន់ខ្ជាប់នូវទម្រង់ដូចខាងក្រោម៖

គ្រោងការណ៍ម៉ែត្រ Protobuf

វាក្យសម្ព័ន្ធ = "proto3";
នាំចូល “google/protobuf/timestamp.proto”;
កញ្ចប់ paa.streamingapi;
ជម្រើស go_package = “.;paa_streamingapi”;
សារ​ម៉ែត្រ {
google.protobuf.ពេលវេលាបំផុតamp ដងបំផុតamp = ៩៧;
ផែនទី តម្លៃ = 2;
int32 stream_id = 3;
}
/**
* តម្លៃម៉ែត្រអាចជាចំនួនគត់ ឬអណ្តែត។
*/
សារ MetricValue {
ប្រភេទ​មួយ {
int64 int_val = 1;
អណ្តែត float_val = 2;
}
}

គ្រោងការណ៍ទិន្នន័យមេតា Protobuf

វាក្យសម្ព័ន្ធ = "proto3";
កញ្ចប់ paa.streamingapi;
ជម្រើស go_package = “.;paa_streamingapi”;
សារ​ទិន្នន័យ​មេតា {
int32 stream_id = 1;
string stream_name = 2;
ផែនទី tags = ៩៧;
}

អតិថិជន Examples

ចំណាំ៖ ពាក្យ​បញ្ជា​ទាំង​នេះ​មាន​គោល​បំណង​ដំណើរការ​លើ​ម៉ាស៊ីន​ភ្ញៀវ​ខាងក្រៅ​សម្រាប់​ឧampកុំព្យូទ័រយួរដៃរបស់អ្នក ឬស្រដៀងគ្នា ហើយមិនមែននៅក្នុងមជ្ឈមណ្ឌលបញ្ជាទេ។
ចំណាំ៖ ដើម្បីបង្ហាញព័ត៌មានអំពីម៉ែត្រ សូមប្រាកដថាម៉ូនីទ័រយ៉ាងហោចណាស់មួយកំពុងដំណើរការនៅក្នុងមជ្ឈមណ្ឌលបញ្ជា។
មជ្ឈមណ្ឌលបញ្ជា tarball រួមបញ្ចូលទាំងប័ណ្ណសារ paa-streaming-api-client-examples.tar.gz (អតិថិជន-ឧamples) ដែលមាន ឧample ស្គ្រីប Python បង្ហាញពីរបៀបប្រើ Streaming API ។
ការដំឡើង និងកំណត់រចនាសម្ព័ន្ធអតិថិជន Examples
អ្នករកឃើញអតិថិជន - ឧamples នៅក្នុងថត Paragon Active Assurance Control Center៖

នាំចេញ CC_VERSION=4.2.0
cd ./paa-control-center_${CC_VERSION}
ls paa-streaming-api-client-examples*
ដើម្បីដំឡើង client-examples នៅលើកុំព្យូទ័រភ្ញៀវខាងក្រៅរបស់អ្នក សូមបន្តដូចខាងក្រោម៖
# បង្កើតថតសម្រាប់ស្រង់មាតិការបស់អតិថិជន examples tarball
mkdir paa-streaming-api-client-examples
# ស្រង់ខ្លឹមសាររបស់អតិថិជន ឧamples tarball
tar xzf paa-streaming-api-client-examples.tar.gz -C paa-streaming-api-client-examples
# ទៅកាន់ថតដែលបានបង្កើតថ្មី។
ស៊ីឌី paa-streaming-api-client-examples
អតិថិជន-ឧamples តម្រូវឱ្យ Docker ដំណើរការ។ ការទាញយក និងការណែនាំអំពីការដំឡើងសម្រាប់ Docker អាចរកបាននៅ https://docs.docker.com/engine/install.

ការប្រើប្រាស់ Client Examples
អតិថិជន - ឧampឧបករណ៍ les អាចដំណើរការជាទម្រង់មូលដ្ឋាន ឬកម្រិតខ្ពស់ ដើម្បីបង្កើត exampភាពស្មុគស្មាញផ្សេងៗគ្នា។ ក្នុងករណីទាំងពីរនេះ វាក៏អាចដំណើរការអតីតamples ជាមួយនឹងការកំណត់រចនាសម្ព័ន្ធ file មានលក្ខណៈសម្បត្តិបន្ថែមសម្រាប់ការប្ដូរតាមបំណងបន្ថែមទៀតនៃភាគីអតិថិជន។
របៀបមូលដ្ឋាន
នៅក្នុងរបៀបមូលដ្ឋាន រង្វាស់ម៉ែត្រ និងទិន្នន័យមេតារបស់ពួកវាត្រូវបានចាក់ផ្សាយដោយឡែកពីគ្នា។ ដល់ទីបញ្ចប់នេះ អតិថិជនស្តាប់ប្រធានបទ Kafka នីមួយៗដែលមានសម្រាប់ការចូលប្រើខាងក្រៅ ហើយគ្រាន់តែបោះពុម្ពសារដែលបានទទួលទៅកុងសូល។
ដើម្បីចាប់ផ្តើមការប្រតិបត្តិនៃ ex មូលដ្ឋានamples, រត់:
./build.sh run-basic –kafka-brokers localhost:9092 –គណនី ACCOUNT_SHORTNAME
ដែល ACCOUNT_SHORTNAME គឺជាឈ្មោះខ្លីនៃគណនីដែលអ្នកចង់ទទួលបានម៉ែត្រពី។
ដើម្បីបញ្ចប់ការប្រតិបត្តិរបស់អតីតample ចុច Ctrl + C. (អាចមានការពន្យាពេលបន្តិច មុនពេលការប្រតិបត្តិឈប់ ដោយសារអតិថិជនរង់ចាំព្រឹត្តិការណ៍អស់ពេល។)
របៀបកម្រិតខ្ពស់
ចំណាំ៖ ម៉ែត្រត្រូវបានបង្ហាញសម្រាប់តែម៉ូនីទ័រ HTTP ដែលដំណើរការនៅក្នុងមជ្ឈមណ្ឌលបញ្ជាប៉ុណ្ណោះ។
ការប្រតិបត្តិក្នុងរបៀបកម្រិតខ្ពស់បង្ហាញពីទំនាក់ទំនងរវាងម៉ែត្រ និងសារទិន្នន័យមេតា។ វាអាចទៅរួចដោយសារវត្តមាននៅក្នុងសារម៉ែត្រនីមួយៗនៃវាលលេខសម្គាល់ស្ទ្រីម ដែលសំដៅលើសារទិន្នន័យមេតាដែលត្រូវគ្នា។
ដើម្បីប្រតិបត្តិ ឧamples, រត់:
./build.sh run-advanced –kafka-brokers localhost:9092 –គណនី ACCOUNT_SHORTNAME
ដែល ACCOUNT_SHORTNAME គឺជាឈ្មោះខ្លីនៃគណនីដែលអ្នកចង់ទទួលបានម៉ែត្រពី។
ដើម្បីបញ្ចប់ការប្រតិបត្តិរបស់អតីតample ចុច Ctrl + C. (អាចមានការពន្យាពេលបន្តិច មុនពេលការប្រតិបត្តិឈប់ ដោយសារអតិថិជនរង់ចាំព្រឹត្តិការណ៍អស់ពេល។)
ការកំណត់បន្ថែម
វាអាចទៅរួចក្នុងការដំណើរការអតីតamples ជាមួយនឹងការកំណត់រចនាសម្ព័ន្ធបន្ថែមរបស់អតិថិជនដោយប្រើ -config-file ជម្រើសតាមពីក្រោយដោយ ក file ឈ្មោះ​ដែល​មាន​លក្ខណៈ​សម្បត្តិ​ក្នុង​សំណុំ​បែបបទ key=value ។
./build.sh run-advanced \\
-kafka-brokers localhost:9092 \\
– គណនី ACCOUNT_SHORTNAME \
- កំណត់រចនាសម្ព័ន្ធ -file client_config.properties

ចំណាំ៖ ទាំងអស់។ files យោង​ក្នុង​ពាក្យ​បញ្ជា​ខាង​លើ​ត្រូវ​តែ​មាន​ទីតាំង​ស្ថិត​នៅ​ក្នុង​ថត​បច្ចុប្បន្ន ហើយ​ត្រូវ​បាន​បញ្ជូន​ដោយ​ប្រើ​តែ​ផ្លូវ​ដែល​ទាក់ទង។ នេះអនុវត្តទាំងពីរចំពោះ -config-file អាគុយម៉ង់ និងធាតុទាំងអស់នៅក្នុងការកំណត់រចនាសម្ព័ន្ធ file ដែលពិពណ៌នា file ទីតាំង។
ធ្វើឱ្យមានសុពលភាពការផ្ទៀងផ្ទាត់អតិថិជនខាងក្រៅ
ដើម្បីធ្វើសុពលភាពការផ្ទៀងផ្ទាត់អតិថិជនពីខាងក្រៅមជ្ឈមណ្ឌលបញ្ជាដោយប្រើប្រាស់ client-examples, អនុវត្តជំហានដូចខាងក្រោម:

  • ពីថត Paragon Active Assurance Control Center ប្តូរទៅ paa-streaming-api-clientexamples folder:
    ស៊ីឌី paa-streaming-api-client-examples
  • ចម្លងវិញ្ញាបនបត្រ CA root ca-cert ទៅក្នុងថតបច្ចុប្បន្ន។
  • បង្កើត client.properties file ជាមួយនឹងខ្លឹមសារដូចខាងក្រោម៖
    security.protocol=SASL_SSL
    ssl.ca.location=ca-cert
    sasl.mechanism=PLAIN
    sasl.username={CLIENT_USER}
    sasl.password={CLIENT_PASSWORD}
    កន្លែងដែល {CLIENT_USER} និង {CLIENT_PASSWORD} គឺជាព័ត៌មានសម្គាល់អ្នកប្រើប្រាស់សម្រាប់អតិថិជន។
  • ដំណើរការមូលដ្ឋាន ឧamples:
    នាំចេញ KAFKA_FQDN=
    ./build.sh run-basic –kafka-brokers ${KAFKA_FQDN}:9093 \
    – គណនី ACCOUNT_SHORTNAME
    - កំណត់រចនាសម្ព័ន្ធ -file client.properties
    ដែល ACCOUNT_SHORTNAME គឺជាឈ្មោះខ្លីនៃគណនីដែលអ្នកចង់ទទួលបានម៉ែត្រពី។
  • ដំណើរការ ឧamples:
    នាំចេញ KAFKA_FQDN=
    ./build.sh run-advanced –kafka-brokers ${KAFKA_FQDN}:9093 \
    – គណនី ACCOUNT_SHORTNAME
    - កំណត់រចនាសម្ព័ន្ធ -file client.properties

ឧបសម្ព័ន្ធ
នៅក្នុងឧបសម្ព័ន្ធនេះ យើងពិពណ៌នាអំពីរបៀបបង្កើត៖

  • ឃ្លាំងសម្ងាត់ file សម្រាប់រក្សាទុកវិញ្ញាបនបត្រ SSL ឈ្មួញកណ្តាល Kafka
  • ហាងជឿទុកចិត្ត file សម្រាប់ការរក្សាទុកវិញ្ញាបនបត្ររបស់អាជ្ញាធរវិញ្ញាបនប័ត្រ (CA) ដែលប្រើដើម្បីចុះហត្ថលេខាលើវិញ្ញាបនបត្រឈ្មួញកណ្តាល Kafka ។

ការបង្កើតវិញ្ញាបនប័ត្រឈ្មួញកណ្តាល Kafka
បង្កើតវិញ្ញាបនប័ត្រដោយប្រើអាជ្ញាធរវិញ្ញាបនបត្រពិតប្រាកដ (បានណែនាំ)
វាត្រូវបានណែនាំឱ្យអ្នកទទួលបានវិញ្ញាបនបត្រ SSL ពិតប្រាកដពី CA ដែលអាចទុកចិត្តបាន។
នៅពេលដែលអ្នកបានសម្រេចចិត្តលើ CA សូមចម្លងវិញ្ញាបនបត្រឫសគល់ CA របស់ពួកគេ ca-cert file ទៅកាន់ផ្លូវរបស់អ្នកដូចបង្ហាញខាងក្រោម៖
នាំចេញ CA_PATH=~/my-ca
mkdir ${CA_PATH}
cp ca-cert ${CA_PATH}
បង្កើតអាជ្ញាធរវិញ្ញាបនបត្រផ្ទាល់ខ្លួនរបស់អ្នក។
ចំណាំ៖ ជាធម្មតា អ្នកគួរតែមានវិញ្ញាបនបត្ររបស់អ្នកចុះហត្ថលេខាដោយអាជ្ញាធរវិញ្ញាបនបត្រពិតប្រាកដ។ សូមមើលផ្នែករងមុន។ អ្វី​ដែល​បន្ទាប់​មក​គឺ​គ្រាន់​តែ​ជា​អតីតampលេ
នៅទីនេះយើងបង្កើតវិញ្ញាបនបត្ររបស់អាជ្ញាធរវិញ្ញាបនប័ត្រ (CA) ផ្ទាល់ខ្លួនរបស់យើង។ file មានសុពលភាព 999 ថ្ងៃ (មិនត្រូវបានណែនាំក្នុងការផលិត)៖
# បង្កើតថតឯកសារសម្រាប់រក្សាទុក CA
នាំចេញ CA_PATH=~/my-ca
mkdir ${CA_PATH}
# បង្កើតវិញ្ញាបនបត្រ CA
openssl req -new -x509 -keyout ${CA_PATH}/ca-key -out ${CA_PATH}/ca-cert -days 999

ការបង្កើត Client Truststore
ឥឡូវនេះអ្នកអាចបង្កើត Truststore បាន។ file ដែលមានវិញ្ញាបនបត្រ ca-cert ដែលបានបង្កើតឡើងខាងលើ។ នេះ។ file នឹងត្រូវការដោយអតិថិជន Kafka ដែលនឹងចូលប្រើ Streaming API៖

keytool -keystore kafka.client.truststore.jks \
- ឈ្មោះក្លែងក្លាយ CARoot \
- ឯកសារនាំចូល -file ${CA_PATH}/ca-cert

ឥឡូវនេះ វិញ្ញាបនបត្រ CA ស្ថិតនៅក្នុង truststore អតិថិជននឹងជឿជាក់លើវិញ្ញាបនបត្រណាមួយដែលបានចុះហត្ថលេខាជាមួយវា។
អ្នកគួរតែចម្លង file kafka.client.truststore.jks ទៅកាន់ទីតាំងដែលគេស្គាល់នៅលើកុំព្យូទ័រអតិថិជនរបស់អ្នក ហើយចង្អុលទៅវានៅក្នុងការកំណត់។
ការបង្កើត Keystore សម្រាប់ឈ្មួញកណ្តាល Kafka
ដើម្បីបង្កើតវិញ្ញាបនបត្រ SSL ឈ្មួញកណ្តាល Kafka ហើយបន្ទាប់មក keystore kafka.server.keystore.jks សូមបន្តដូចខាងក្រោម៖
ការបង្កើតវិញ្ញាបនបត្រ SSL
ខាងក្រោម 999 គឺជាចំនួនថ្ងៃនៃសុពលភាពរបស់ keystore ហើយ FQDN គឺជាឈ្មោះដែនដែលមានលក្ខណៈសម្បត្តិគ្រប់គ្រាន់របស់អតិថិជន (ឈ្មោះម៉ាស៊ីនសាធារណៈរបស់ថ្នាំង)។
ចំណាំ៖ វាមានសារៈសំខាន់ដែល FQDN ត្រូវនឹងឈ្មោះម៉ាស៊ីនពិតប្រាកដដែលអតិថិជន Kafka នឹងប្រើដើម្បីភ្ជាប់ទៅមជ្ឈមណ្ឌលបញ្ជា។
sudo mkdir -p /var/ssl/private
sudo chown -R $USER: /var/ssl/private
ស៊ីឌី /var/ssl/ឯកជន
នាំចេញ FQDN =
keytool -keystore kafka.server.keystore.jks \
- ម៉ាស៊ីនមេឈ្មោះក្លែងក្លាយ \\
សុពលភាព 999 \\
-genkey -keyalg RSA -ext SAN=dns:${FQDN}
បង្កើតសំណើចុះហត្ថលេខាលើវិញ្ញាបនបត្រ ហើយរក្សាទុកវានៅក្នុងប្រអប់ file ឈ្មោះ cert-server-request:
keytool -keystore kafka.server.keystore.jks \
- ម៉ាស៊ីនមេឈ្មោះក្លែងក្លាយ \\
-certreq \\
-file cert-server-request

ឥឡូវនេះអ្នកគួរតែផ្ញើ file cert-server-request ទៅអាជ្ញាធរវិញ្ញាបនបត្ររបស់អ្នក (CA) ប្រសិនបើអ្នកកំពុងប្រើពិតប្រាកដមួយ។ បន្ទាប់មកពួកគេនឹងប្រគល់វិញ្ញាបនបត្រដែលបានចុះហត្ថលេខា។ យើងនឹងយោងទៅនេះថាជា cert-server-signed ខាងក្រោម។
ការចុះហត្ថលេខាលើវិញ្ញាបនបត្រ SSL ដោយប្រើវិញ្ញាបនបត្រ CA ដែលបង្កើតដោយខ្លួនឯង។
ចំណាំ៖ ជាថ្មីម្តងទៀត ការប្រើប្រាស់ CA ផ្ទាល់ខ្លួនរបស់អ្នកមិនត្រូវបានណែនាំនៅក្នុងប្រព័ន្ធផលិតកម្មទេ។
ចុះហត្ថលេខាលើវិញ្ញាបនបត្រដោយប្រើ CA ដោយមធ្យោបាយនៃ file cert-server-request ដែលបង្កើតវិញ្ញាបនបត្រដែលបានចុះហត្ថលេខា cert-server-signed ។ មើល​ខាង​ក្រោម; ca-password គឺជាពាក្យសម្ងាត់ដែលបានកំណត់នៅពេលបង្កើតវិញ្ញាបនបត្រ CA ។

ស៊ីឌី /var/ssl/ឯកជន
openssl x509 -req \\
-CA ${CA_PATH}/ca-cert \\
-CAkey ${CA_PATH}/ca-key \\
-នៅក្នុង cert-server-request \\
ចេញវិញ្ញាបនបត្រ-ម៉ាស៊ីនមេ-ចុះហត្ថលេខា \\
-ថ្ងៃ 999 -CAcreateserial \
-passin pass:{ca-password}

ការនាំចូលវិញ្ញាបនបត្រដែលបានចុះហត្ថលេខាទៅក្នុង Keystore
នាំចូលវិញ្ញាបនបត្រឫសគល់ ca-cert ទៅក្នុងឃ្លាំងសម្ងាត់៖
keytool -keystore kafka.server.keystore.jks \
-alias ca-cert \\
- នាំចូល \\
-file ${CA_PATH}/ca-cert
នាំចូលវិញ្ញាបនបត្រដែលបានចុះហត្ថលេខា ហៅថា cert-server-signed៖
keytool -keystore kafka.server.keystore.jks \
- ម៉ាស៊ីនមេឈ្មោះក្លែងក្លាយ \\
- នាំចូល \\
-file ចុះហត្ថលេខាលើម៉ាស៊ីនមេ
នេះ។ file kafka.server.keystore.jks គួរតែត្រូវបានចម្លងទៅទីតាំងដែលគេស្គាល់នៅលើម៉ាស៊ីនមេរបស់មជ្ឈមណ្ឌលបញ្ជា ហើយបន្ទាប់មកត្រូវបានបញ្ជូនទៅក្នុង /etc/kafka/server.properties ។

ការប្រើប្រាស់ស្ទ្រីម API

ទូទៅ
API ស្ទ្រីមទាញយកទាំងទិន្នន័យសាកល្បង និងត្រួតពិនិត្យ។ វា​មិន​អាច​ទៅ​រួច​ក្នុង​ការ​ដាក់​ចេញ​មួយ​ក្នុង​ចំណោម​ប្រភេទ​ទាំង​នេះ​ទេ។
API ស្ទ្រីមមិនទាញយកទិន្នន័យពីការធ្វើតេស្តផ្អែកលើស្គ្រីបទេ (ដែលតំណាងដោយចតុកោណកែង ជំនួសឱ្យបំណែក jigsaw នៅក្នុង Control Center GUI) ដូចជាការធ្វើតេស្តធ្វើឱ្យសេវាអ៊ីសឺរណិត និងការធ្វើតេស្តតម្លាភាព។

ឈ្មោះប្រធានបទ Kafka
ឈ្មោះប្រធានបទ Kafka សម្រាប់ស្ទ្រីម API មានដូចខាងក្រោម ដែល %s ជាឈ្មោះខ្លីនៃគណនីមជ្ឈមណ្ឌលបញ្ជា (បង្ហាញនៅពេលបង្កើតគណនី)៖

const (
ឈ្មោះអ្នកនាំចេញ = "កាហ្វកា"
metadataTopicTpl = “paa.public.accounts.%s.metadata”
metricsTopicTpl = “paa.public.accounts.%s.metrics”
)

Examples នៃការប្រើប្រាស់ Streaming API
អតីតamples ដែលធ្វើតាមត្រូវបានរកឃើញនៅក្នុង tarball paa-streaming-api-client-examples.tar.gz មាននៅក្នុង tarball មជ្ឈមណ្ឌលបញ្ជា។
ទីមួយមានអតីតមូលដ្ឋានample បង្ហាញពីរបៀបដែលម៉ែត្រ និងទិន្នន័យមេតារបស់ពួកគេត្រូវបានផ្សាយដោយឡែកពីគ្នា ហើយគ្រាន់តែបោះពុម្ពសារដែលបានទទួលទៅកុងសូល។ អ្នកអាចដំណើរការវាដូចខាងក្រោមៈ
sudo ./build.sh run-basic –kafka-brokers localhost:9092 –គណនី ACCOUNT_SHORTNAME
មាន​អតីត​មនុស្ស​ដែល​ជឿនលឿន​ជាង​នេះ​ផង​ដែរ។ample ជាកន្លែងដែលម៉ែត្រ និងសារទិន្នន័យមេតាត្រូវបានទាក់ទងគ្នា។ ប្រើពាក្យបញ្ជានេះដើម្បីដំណើរការវា៖
sudo ./build.sh run-advanced –kafka-brokers localhost:9092 –គណនី ACCOUNT_SHORTNAME
អ្នកត្រូវប្រើ sudo ដើម្បីដំណើរការពាក្យបញ្ជា Docker ដូចពាក្យខាងលើ។ ជាជម្រើស អ្នកអាចអនុវត្តតាមជំហានក្រោយការដំឡើងលីនុច ដើម្បីអាចដំណើរការពាក្យបញ្ជា Docker ដោយមិនប្រើ sudo ។ សម្រាប់ព័ត៌មានលម្អិត សូមចូលទៅកាន់ docs.docker.com/engine/install/linux-postinstall.

Juniper Networks និមិត្តសញ្ញា Juniper Networks Juniper និង Junos គឺជាពាណិជ្ជសញ្ញាដែលបានចុះបញ្ជីរបស់ Juniper Networks, Inc. នៅសហរដ្ឋអាមេរិក និងប្រទេសដទៃទៀត។ រាល់ពាណិជ្ជសញ្ញា សញ្ញាសេវាកម្ម ម៉ាកដែលបានចុះបញ្ជី ឬសញ្ញាសម្គាល់សេវាកម្មដែលបានចុះបញ្ជី គឺជាកម្មសិទ្ធិរបស់ម្ចាស់រៀងៗខ្លួន។ Juniper Networks មិនទទួលខុសត្រូវចំពោះភាពមិនត្រឹមត្រូវណាមួយនៅក្នុងឯកសារនេះទេ។ Juniper Networks រក្សាសិទ្ធិក្នុងការផ្លាស់ប្តូរ កែប្រែ ផ្ទេរ ឬកែប្រែការបោះពុម្ពនេះដោយមិនចាំបាច់ជូនដំណឹងជាមុន។ រក្សាសិទ្ធិ © 2023 Juniper Networks, Inc. រក្សាសិទ្ធិគ្រប់យ៉ាង។

និមិត្តសញ្ញា Juniper NETWORKS

ឯកសារ/ធនធាន

Juniper NETWORKS Streaming API Active Assurance [pdf] ការណែនាំអ្នកប្រើប្រាស់
ស្ទ្រីម API Active Assurance, API Active Assurance, Active Assurance, Assurance

ឯកសារយោង

ទុកមតិយោបល់

អាសយដ្ឋានអ៊ីមែលរបស់អ្នកនឹងមិនត្រូវបានផ្សព្វផ្សាយទេ។ វាលដែលត្រូវការត្រូវបានសម្គាល់ *