ຄູ່ມືການຖ່າຍທອດ API
ຈັດພີມມາ
2023-07-07
ປ່ອຍ
4.2

ແນະນຳ

ຄູ່ມືນີ້ອະທິບາຍວິທີການສະກັດຂໍ້ມູນຈາກ Paragon Active Assurance ຜ່ານ API streaming ຂອງຜະລິດຕະພັນ.
API ເຊັ່ນດຽວກັນກັບລູກຄ້າການຖ່າຍທອດແມ່ນລວມຢູ່ໃນການຕິດຕັ້ງ Paragon Active Assurance.
ຢ່າງໃດກໍຕາມ, ການຕັ້ງຄ່າເລັກນ້ອຍແມ່ນຈໍາເປັນກ່ອນທີ່ທ່ານຈະສາມາດໃຊ້ API ໄດ້. ນີ້ແມ່ນກວມເອົາໃນ "ການຕັ້ງຄ່າ API ການຖ່າຍທອດ" ໃນຫນ້າ 1 ບົດ.

ຕັ້ງຄ່າ Streaming API

ເກີນview
ບົດນີ້ອະທິບາຍວິທີການປັບຄ່າ Streaming API ເພື່ອອະນຸຍາດໃຫ້ສະໝັກຮັບຂໍ້ຄວາມ metrics ຜ່ານ Kafka.
pr
ຂ້າງລຸ່ມນີ້ພວກເຮົາຈະຜ່ານ:

• ວິທີການເປີດໃຊ້ Streaming 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: ກອບທີ່ສະຫນອງກົນໄກສໍາລັບການຢັ້ງຢືນຜູ້ໃຊ້, ການກວດສອບຄວາມຖືກຕ້ອງຂອງຂໍ້ມູນ, ແລະການເຂົ້າລະຫັດ.
• Streaming API subscriber: ອົງປະກອບທີ່ຮັບຜິດຊອບສໍາລັບການດຶງຂໍ້ມູນເຫດການທີ່ເກັບໄວ້ໃນຫົວຂໍ້ທີ່ກໍານົດໄວ້ໃນ Paragon Active Assurance ແລະຫມາຍຄວາມວ່າສໍາລັບການເຂົ້າເຖິງພາຍນອກ.
• ໜ່ວຍງານຢັ້ງຢືນ: ໜ່ວຍງານທີ່ເຊື່ອຖືໄດ້ທີ່ອອກ ແລະຖອນໃບຮັບຮອງຫຼັກສາທາລະນະ.
• Certificate Authority ໃບ​ຢັ້ງ​ຢືນ: ໃບ​ຢັ້ງ​ຢືນ​ກະ​ແຈ​ສາ​ທາ​ລະ​ນະ​ທີ່​ລະ​ບຸ​ສິດ​ອໍາ​ນາດ​ໃບ​ຢັ້ງ​ຢືນ.

ວິທີການທີ່ Streaming API ເຮັດວຽກ
ດັ່ງທີ່ໄດ້ກ່າວກ່ອນຫນ້ານີ້, Streaming API ອະນຸຍາດໃຫ້ລູກຄ້າພາຍນອກດຶງຂໍ້ມູນກ່ຽວກັບ metrics ຈາກ Kafka.
ການວັດແທກທັງໝົດທີ່ເກັບກຳໂດຍ Test Agents ໃນລະຫວ່າງການທົດສອບ ຫຼືວຽກງານການຕິດຕາມແມ່ນຖືກສົ່ງໄປໃຫ້ບໍລິການ Stream.
ຫຼັງຈາກຂັ້ນຕອນການປຸງແຕ່ງ, ບໍລິການ Stream ເຜີຍແຜ່ metrics ເຫຼົ່ານັ້ນຢູ່ໃນ Kafka ພ້ອມກັບ metadata ເພີ່ມເຕີມ.ຫົວຂໍ້ Kafka
Kafka ມີແນວຄວາມຄິດຂອງຫົວຂໍ້ທີ່ຂໍ້ມູນທັງຫມົດຖືກເຜີຍແຜ່. ໃນ Paragon Active Assurance ມີຫຼາຍຫົວຂໍ້ Kafka ດັ່ງກ່າວທີ່ມີຢູ່; ແນວໃດກໍ່ຕາມ, ມີພຽງແຕ່ຊຸດຍ່ອຍຂອງສິ່ງເຫຼົ່ານີ້ແມ່ນຫມາຍເຖິງການເຂົ້າເຖິງພາຍນອກ.
ແຕ່ລະບັນຊີ Paragon Active Assurance ໃນສູນຄວບຄຸມມີສອງຫົວຂໍ້ທີ່ອຸທິດຕົນ. ຂ້າງລຸ່ມນີ້, ACCOUNT ແມ່ນຊື່ຫຍໍ້ຂອງບັນຊີ:

• paa.public.accounts.{ACCOUNT}.metrics
• ຂໍ້ຄວາມ metrics ທັງໝົດສໍາລັບບັນຊີທີ່ລະບຸນັ້ນຖືກເຜີຍແຜ່ໃນຫົວຂໍ້ນີ້
• ຂໍ້ມູນຈໍານວນຫຼວງຫຼາຍ
• ຄວາມຖີ່ຂອງການປັບປຸງສູງ
• paa.public.accounts.{ACCOUNT}.metadata
• ປະກອບດ້ວຍ metadata ທີ່ກ່ຽວຂ້ອງກັບຂໍ້ມູນ metrics, ສໍາລັບການຍົກຕົວຢ່າງample ການທົດສອບ, ຕິດຕາມກວດກາຫຼືຕົວແທນການທົດສອບທີ່ກ່ຽວຂ້ອງກັບ metrics
• ຂໍ້ມູນຈໍານວນນ້ອຍໆ
• ຄວາມຖີ່ຂອງການປັບປຸງຕໍ່າ

ເປີດໃຊ້ Streaming API
ໝາຍເຫດ: ຄໍາແນະນໍາເຫຼົ່ານີ້ຈະຖືກດໍາເນີນການຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຂອງສູນຄວບຄຸມໂດຍໃຊ້ sudo.
ເນື່ອງຈາກ Streaming API ເພີ້ມສ່ວນເກີນບາງຢ່າງໃຫ້ກັບສູນຄວບຄຸມ, ມັນບໍ່ໄດ້ຖືກເປີດໃຊ້ໂດຍຄ່າເລີ່ມຕົ້ນ. ເພື່ອເປີດໃຊ້ API, ກ່ອນອື່ນ ໝົດ ພວກເຮົາຕ້ອງເປີດໃຊ້ການເຜີຍແຜ່ metrics ກັບ Kafka ໃນການຕັ້ງຄ່າຕົ້ນຕໍ file:

• /etc/netrounds/netrounds.conf

KAFKA_METRICS_ENABLED = ຖືກ
ຄຳເຕືອນ: ການເປີດໃຊ້ຄຸນສົມບັດນີ້ອາດຈະສົ່ງຜົນກະທົບຕໍ່ປະສິດທິພາບຂອງສູນຄວບຄຸມ. ໃຫ້ແນ່ໃຈວ່າທ່ານໄດ້ປັບຂະຫນາດຕົວຢ່າງຂອງທ່ານຕາມຄວາມເຫມາະສົມ.
ຕໍ່ໄປ, ເພື່ອເຮັດໃຫ້ການສົ່ງຕໍ່ຂອງ metrics ເຫຼົ່ານີ້ໄປຫາຫົວຂໍ້ Kafka ທີ່ຖືກຕ້ອງ:

• /etc/netrounds/metrics.yaml

streaming-api: ຈິງ
ເພື່ອເປີດໃຊ້ ແລະເລີ່ມການບໍລິການ Streaming API, ໃຫ້ແລ່ນ:
sudo ncc ບໍລິການເປີດໃຊ້ການວັດແທກ timescaledb
sudo ncc ບໍລິການເລີ່ມຕົ້ນການວັດແທກ timescaledb
ສຸດທ້າຍ, ເລີ່ມຕົ້ນການບໍລິການຄືນໃໝ່:
sudo ncc ບໍລິການ restart
ຢືນຢັນວ່າ Streaming API ເຮັດວຽກຢູ່ໃນສູນຄວບຄຸມ
ໝາຍເຫດ: ຄໍາແນະນໍາເຫຼົ່ານີ້ຈະຖືກດໍາເນີນການຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຂອງສູນຄວບຄຸມ.
ໃນປັດຈຸບັນທ່ານສາມາດກວດສອບວ່າທ່ານໄດ້ຮັບ metrics ກ່ຽວກັບຫົວຂໍ້ Kafka ທີ່ຖືກຕ້ອງ. ເພື່ອເຮັດສິ່ງນີ້, ຕິດຕັ້ງອຸປະກອນ kafkacat:
sudo apt-get ອັບເດດ
sudo apt-get ຕິດຕັ້ງ kafkacat
ຖ້າທ່ານມີການທົດສອບຫຼືຕິດຕາມກວດກາທີ່ເຮັດວຽກຢູ່ໃນສູນຄວບຄຸມ, ທ່ານຄວນສາມາດໃຊ້ kafkacat ເພື່ອຮັບ metrics ແລະ metadata ໃນຫົວຂໍ້ເຫຼົ່ານີ້.
ແທນທີ່ບັນຊີຂອງຂ້ອຍດ້ວຍຊື່ຫຍໍ້ຂອງບັນຊີຂອງທ່ານ (ນີ້ແມ່ນສິ່ງທີ່ທ່ານເຫັນຢູ່ໃນສູນຄວບຄຸມຂອງເຈົ້າ URL):
ສົ່ງອອກ METRICS_TOPIC=paa.public.accounts.myaccount.metrics
ສົ່ງອອກ METADATA_TOPIC=paa.public.accounts.myaccount.metadata
ຕອນນີ້ເຈົ້າຄວນຈະເຫັນ metrics ໂດຍການແລ່ນຄໍາສັ່ງນີ້:
kafkacat -b ${KAFKA_FQDN}:9092 -t ${METRICS_TOPIC} -C -e
ເຖິງ view metadata, ດໍາເນີນການຄໍາສັ່ງຕໍ່ໄປນີ້ (ສັງເກດວ່ານີ້ຈະບໍ່ປັບປຸງເລື້ອຍໆ):
kafkacat -b ${KAFKA_FQDN}:9092 -t ${METADATA_TOPIC} -C -e
ໝາຍເຫດ:
kafkacat”Client Examples” ຢູ່ໃນ ໜ້າ ທີ 14
ນີ້ຢັ້ງຢືນວ່າພວກເຮົາມີ Streaming API ທີ່ເຮັດວຽກຈາກພາຍໃນສູນຄວບຄຸມ. ແນວໃດກໍ່ຕາມ, ສ່ວນຫຼາຍແມ່ນເຈົ້າສົນໃຈໃນການເຂົ້າເຖິງຂໍ້ມູນຈາກລູກຄ້າພາຍນອກແທນ. ພາກຕໍ່ໄປອະທິບາຍວິທີການເປີດ Kafka ສໍາລັບການເຂົ້າເຖິງພາຍນອກ.
ເປີດ Kafka ສໍາລັບເຈົ້າພາບພາຍນອກ
ໝາຍເຫດ: ຄໍາແນະນໍາເຫຼົ່ານີ້ຈະຖືກດໍາເນີນການຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຂອງສູນຄວບຄຸມ.
ໂດຍຄ່າເລີ່ມຕົ້ນ Kafka ແລ່ນຢູ່ໃນສູນຄວບຄຸມແມ່ນຖືກຕັ້ງຄ່າໃຫ້ຟັງພຽງແຕ່ຢູ່ໃນ localhost ສໍາລັບການນໍາໃຊ້ພາຍໃນ.
ມັນເປັນໄປໄດ້ທີ່ຈະເປີດ Kafka ສໍາລັບລູກຄ້າພາຍນອກໂດຍການດັດແກ້ການຕັ້ງຄ່າ Kafka.
ການເຊື່ອມຕໍ່ກັບ Kafka: ຄໍາເຕືອນ
ຂໍ້ຄວນລະວັງ: ກະລຸນາອ່ານນີ້ຢ່າງລະມັດລະວັງ, ເພາະວ່າມັນງ່າຍທີ່ຈະດໍາເນີນການເຂົ້າໄປໃນບັນຫາການເຊື່ອມຕໍ່ກັບ 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:
*) ການ​ກວດ​ສອບ​ຊື່​ຜູ້​ໃຊ້ / ລະ​ຫັດ​ຜ່ານ​ປະ​ຕິ​ບັດ​ຢູ່​ໃນ​ຊ່ອງ​ທາງ​ການ​ເຂົ້າ​ລະ​ຫັດ SSL​

ເພື່ອເຂົ້າໃຈຢ່າງເຕັມສ່ວນວິທີການເຂົ້າລະຫັດ SSL/TLS ເຮັດວຽກສໍາລັບ Kafka, ກະລຸນາເບິ່ງເອກະສານທາງການ: docs.confluent.io/platform/current/kafka/encryption.html
ໃບຢັ້ງຢືນ SSL/TLS ສິ້ນສຸດລົງview
ໝາຍເຫດ: ໃນພາກຍ່ອຍນີ້ພວກເຮົາຈະໃຊ້ຄຳສັບຕໍ່ໄປນີ້:
ໃບຢັ້ງຢືນ: ໃບຢັ້ງຢືນ SSL ທີ່ເຊັນໂດຍອົງການໃບຢັ້ງຢືນ (CA). ແຕ່ລະນາຍຫນ້າ Kafka ມີຫນຶ່ງ.
Keystore: ທີ່ເກັບກະແຈ file ທີ່ເກັບຮັກສາໃບຢັ້ງຢືນ. ທີ່ເກັບກະແຈ file ມີກະແຈສ່ວນຕົວຂອງໃບຢັ້ງຢືນ; ດັ່ງນັ້ນ, ມັນຈໍາເປັນຕ້ອງເກັບຮັກສາໄວ້ຢ່າງປອດໄພ.
Truststore: A file ປະກອບມີໃບຢັ້ງຢືນ CA ທີ່ເຊື່ອຖືໄດ້.
ເພື່ອຕັ້ງຄ່າການພິສູດຢືນຢັນລະຫວ່າງລູກຄ້າພາຍນອກແລະ Kafka ແລ່ນຢູ່ໃນສູນຄວບຄຸມ, ທັງສອງຝ່າຍຕ້ອງມີ keystore ທີ່ຖືກກໍານົດດ້ວຍໃບຢັ້ງຢືນທີ່ກ່ຽວຂ້ອງທີ່ເຊັນໂດຍ Certificate Authority (CA) ຮ່ວມກັບໃບຢັ້ງຢືນຮາກ CA.
ນອກຈາກນັ້ນ, ລູກຄ້າຍັງຕ້ອງມີ truststore ທີ່ມີໃບຢັ້ງຢືນຮາກ CA.
ໃບຢັ້ງຢືນຮາກ CA ແມ່ນທົ່ວໄປກັບນາຍຫນ້າ Kafka ແລະລູກຄ້າ Kafka.
ການສ້າງໃບຢັ້ງຢືນທີ່ຕ້ອງການ
ນີ້ແມ່ນກວມເອົາໃນ “ເອກະສານຊ້ອນທ້າຍ” ໃນໜ້າ 17.
ການຕັ້ງຄ່າ Kafka Broker SSL/TLS ໃນສູນຄວບຄຸມ
ຫມາຍເຫດ: ຄໍາແນະນໍາເຫຼົ່ານີ້ຈະຖືກດໍາເນີນການຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຂອງສູນຄວບຄຸມ.
ໝາຍເຫດ: ກ່ອນທີ່ຈະສືບຕໍ່, ທ່ານຕ້ອງສ້າງ keystore ທີ່ປະກອບດ້ວຍໃບຢັ້ງຢືນ SSL ໂດຍປະຕິບັດຕາມຄໍາແນະນໍາໃນ "ເອກະສານຊ້ອນທ້າຍ" ໃນຫນ້າ 17. ເສັ້ນທາງທີ່ໄດ້ກ່າວມາຂ້າງລຸ່ມນີ້ແມ່ນມາຈາກຄໍາແນະນໍາເຫຼົ່ານີ້.
SSL keystore ເປັນ file ເກັບ​ໄວ້​ໃນ​ແຜ່ນ​ທີ່​ມີ​ file ສ່ວນຂະຫຍາຍ .jks.
ເມື່ອທ່ານມີໃບຢັ້ງຢືນທີ່ຈໍາເປັນທີ່ສ້າງຂຶ້ນສໍາລັບທັງນາຍຫນ້າ Kafka ແລະລູກຄ້າ Kafka ທີ່ມີຢູ່, ທ່ານສາມາດສືບຕໍ່ໂດຍການກໍາຫນົດຄ່ານາຍຫນ້າ Kafka ແລ່ນຢູ່ໃນສູນຄວບຄຸມ. ທ່ານຈໍາເປັນຕ້ອງຮູ້ດັ່ງຕໍ່ໄປນີ້:

• : ຊື່ເຈົ້າພາບສາທາລະນະຂອງສູນຄວບຄຸມ; ນີ້ຕ້ອງເປັນການແກ້ໄຂແລະສາມາດເຂົ້າເຖິງໄດ້ໂດຍລູກຄ້າ Kafka.
• : ລະ​ຫັດ​ຜ່ານ keystore ທີ່​ສະ​ຫນອງ​ໃຫ້​ໃນ​ເວ​ລາ​ທີ່​ການ​ສ້າງ​ໃບ​ຢັ້ງ​ຢືນ SSL.
• ແລະ : ເຫຼົ່ານີ້ແມ່ນລະຫັດຜ່ານທີ່ທ່ານຕ້ອງການທີ່ຈະກໍານົດສໍາລັບຜູ້ໃຊ້ admin ແລະລູກຄ້າຕາມລໍາດັບ. ໃຫ້ສັງເກດວ່າທ່ານສາມາດເພີ່ມຜູ້ໃຊ້ເພີ່ມເຕີມ, ດັ່ງທີ່ລະບຸໄວ້ໃນ exampເລ.

ແກ້ໄຂ ຫຼືຕໍ່ທ້າຍ (ດ້ວຍການເຂົ້າເຖິງ sudo) ຄຸນສົມບັດຂ້າງລຸ່ມນີ້ໃນ /etc/kafka/server.properties, ໃສ່ຕົວແປຂ້າງເທິງດັ່ງທີ່ສະແດງ:
ຄຳເຕືອນ: ຢ່າເອົາ PLAINTEXT://localhost:9092; ນີ້ຈະທໍາລາຍການທໍາງານຂອງສູນຄວບຄຸມເນື່ອງຈາກການບໍລິການພາຍໃນຈະບໍ່ສາມາດສື່ສານໄດ້.

…
# ທີ່ຢູ່ທີ່ນາຍຫນ້າ Kafka ຟັງ.
listeners=PLAINTEXT://localhost:9092,SASL_SSL://0.0.0.0:9093
# ເຫຼົ່ານີ້ແມ່ນເຈົ້າພາບທີ່ໂຄສະນາກັບຄືນໄປບ່ອນລູກຄ້າໃດໆທີ່ເຊື່ອມຕໍ່.
advertised.listeners=PLAINTEXT://localhost:9092,SASL_SSL:// :9093
…
####### ການຕັ້ງຄ່າແບບກຳນົດເອງ
# ການຕັ້ງຄ່າ SSL
ssl.endpoint.identification.algorithm=
ssl.keystore.location=/var/ssl/private/kafka.server.keystore.jks
ssl.keystore.password=
ssl.key.password=
ssl.client.auth=none
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 ໃນ localhost
ຄຳເຕືອນ: ທໍາອິດພວກເຮົາຕ້ອງຕັ້ງຄ່າ 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 ອ່ານ –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 ອ່ານ –operation describe \
-ຫົວຂໍ້ paa.public. -resource-pattern-type prefixed

ເມື່ອເຮັດໄດ້ກັບສິ່ງນີ້, ທ່ານຈໍາເປັນຕ້ອງປິດການບໍລິການໃຫມ່:
sudo ncc ບໍລິການ restart
ເພື່ອກວດສອບວ່າລູກຄ້າສາມາດສ້າງການເຊື່ອມຕໍ່ທີ່ປອດໄພໄດ້, ດໍາເນີນການຄໍາສັ່ງຕໍ່ໄປນີ້ຢູ່ໃນຄອມພິວເຕີລູກຄ້າພາຍນອກ (ບໍ່ແມ່ນຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຂອງສູນຄວບຄຸມ). ຂ້າງລຸ່ມນີ້, PUBLIC_HOSTNAME ແມ່ນຊື່ໂຮສຂອງສູນຄວບຄຸມ:
openssl s_client -debug -connect ${PUBLIC_HOSTNAME}:9093 -tls1_2 | grep "ການເຈລະຈາຄືນໃຫມ່ທີ່ປອດໄພແມ່ນໄດ້ຮັບການສະຫນັບສະຫນູນ"
ໃນ​ການ​ອອກ​ຄໍາ​ສັ່ງ​ທີ່​ທ່ານ​ຄວນ​ຈະ​ເບິ່ງ​ໃບ​ຢັ້ງ​ຢືນ​ຂອງ​ເຄື່ອງ​ແມ່​ຂ່າຍ​ເຊັ່ນ​ດຽວ​ກັນ​ກັບ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:
ການເຈລະຈາທີ່ປອດໄພ IS ໄດ້ຮັບການສະຫນັບສະຫນູນ
ເພື່ອຮັບປະກັນວ່າການບໍລິການພາຍໃນໄດ້ຮັບການອະນຸຍາດໃຫ້ເຂົ້າເຖິງເຄື່ອງແມ່ຂ່າຍ Kafka, ກະລຸນາກວດເບິ່ງບັນທຶກຕໍ່ໄປນີ້files:

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

ການກວດສອບການເຊື່ອມຕໍ່ລູກຄ້າພາຍນອກ
kafkacat
ໝາຍເຫດ: ຄໍາແນະນໍາເຫຼົ່ານີ້ຈະຖືກດໍາເນີນການຢູ່ໃນຄອມພິວເຕີລູກຄ້າ (ບໍ່ແມ່ນຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຂອງສູນຄວບຄຸມ).
ໝາຍເຫດ: ເພື່ອສະແດງຂໍ້ມູນ metrics, ໃຫ້ແນ່ໃຈວ່າມີຈໍສະແດງຜົນຢ່າງຫນ້ອຍຫນຶ່ງຈໍສະແດງຜົນຢູ່ໃນສູນຄວບຄຸມ.
ເພື່ອກວດສອບແລະກວດສອບການເຊື່ອມຕໍ່ເປັນລູກຄ້າພາຍນອກ, ມັນເປັນໄປໄດ້ທີ່ຈະໃຊ້ kafkacat utility ທີ່ຖືກຕິດຕັ້ງຢູ່ໃນພາກ "ການກວດສອບວ່າ streaming 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=ທຳມະດາ
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. .metrics
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:

Debug ການສື່ສານຜູ້ບໍລິໂພກ
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.
ຮູບແບບຂໍ້ຄວາມ
ຂໍ້ຄວາມທີ່ໃຊ້ສໍາລັບຫົວຂໍ້ metrics ແລະ metadata ໄດ້ຖືກຈັດລໍາດັບໃນຮູບແບບ Protocol buffers (protobuf) (ເບິ່ງ. developers.google.com/protocol-buffers). schemas ສໍາລັບຂໍ້ຄວາມເຫຼົ່ານີ້ປະຕິບັດຕາມຮູບແບບດັ່ງຕໍ່ໄປນີ້:

Metrics Protobuf Schema

syntax = “proto3”;
ນຳເຂົ້າ “google/protobuf/timestamp.proto”;
ຊຸດ paa.streamingapi;
ທາງເລືອກ go_package = “.;paa_streamingapi”;
ຂໍ້​ຄວາມ Metrics {
google.protobuf.ເວລາທີ່ສຸດamp ເວລາທີ່ສຸດamp = 1;
ແຜນທີ່ ຄ່າ = 2;
int32 stream_id = 3;
}
/**
* ຄ່າ metric ສາມາດເປັນຈໍານວນເຕັມຫຼື float.
*/
ຂໍ້ຄວາມ MetricValue {
ປະເພດໃດນຶ່ງ {
int64 int_val = 1;
float_val = 2;
}
}

Metadata Protobuf Schema

syntax = “proto3”;
ຊຸດ paa.streamingapi;
ທາງເລືອກ go_package = “.;paa_streamingapi”;
ຂໍ້​ຄວາມ Metadata {
int32 stream_id = 1;
string stream_name = 2;
ແຜນທີ່ tags = 13;
}

ລູກຄ້າ Examples

ໝາຍເຫດ: ຄໍາສັ່ງເຫຼົ່ານີ້ແມ່ນມີຈຸດປະສົງເພື່ອດໍາເນີນການກັບລູກຄ້າພາຍນອກ, ສໍາລັບການຍົກຕົວຢ່າງampໃຫ້ແລັບທັອບຂອງເຈົ້າຫຼືຄ້າຍຄືກັນ, ແລະບໍ່ໄດ້ຢູ່ໃນສູນຄວບຄຸມ.
ໝາຍເຫດ: ເພື່ອໃຫ້ມີການສະແດງຂໍ້ມູນ metrics, ໃຫ້ແນ່ໃຈວ່າມີຈໍສະແດງຜົນຢ່າງຫນ້ອຍຫນຶ່ງຈໍສະແດງຜົນຢູ່ໃນສູນຄວບຄຸມ.
Control Center tarball ປະກອບມີ archive paa-streaming-api-client-examples.tar.gz (ລູກຄ້າ-examples), ເຊິ່ງປະກອບດ້ວຍ example Python script ສະແດງວິທີການໃຊ້ Streaming API.
ການຕິດຕັ້ງ ແລະກຳນົດຄ່າລູກຄ້າ Examples
ທ່ານຊອກຫາ client-examples ໃນໂຟນເດີ 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
# ສະກັດເນື້ອໃນຂອງລູກຄ້າ examples tarball
tar xzf paa-streaming-api-client-examples.tar.gz -C paa-streaming-api-client-examples
# ໄປທີ່ໄດເລກະທໍລີທີ່ສ້າງໃຫມ່
cd paa-streaming-api-client-examples
client-examples ຮຽກຮ້ອງໃຫ້ Docker ດໍາເນີນການ. ການດາວໂຫຼດ ແລະຄໍາແນະນໍາການຕິດຕັ້ງ Docker ສາມາດພົບໄດ້ທີ່ https://docs.docker.com/engine/install.

ການນໍາໃຊ້ Client Examples
ລູກຄ້າ-examples ເຄື່ອງ​ມື​ສາ​ມາດ​ດໍາ​ເນີນ​ການ​ໃນ​ຮູບ​ແບບ​ພື້ນ​ຖານ​ຫຼື​ຂັ້ນ​ສູງ​ໃນ​ການ​ກໍ່​ສ້າງ examples ຂອງ​ຄວາມ​ສັບ​ສົນ​ທີ່​ແຕກ​ຕ່າງ​ກັນ​. ໃນທັງສອງກໍລະນີ, ມັນກໍ່ເປັນໄປໄດ້ທີ່ຈະດໍາເນີນການ examples ທີ່ມີການຕັ້ງຄ່າ file ປະກອບດ້ວຍຄຸນສົມບັດເພີ່ມເຕີມສໍາລັບການປັບແຕ່ງເພີ່ມເຕີມຂອງຝ່າຍລູກຄ້າ.
ໂໝດພື້ນຖານ
ໃນຮູບແບບພື້ນຖານ, metrics ແລະ metadata ຂອງພວກມັນຖືກຖ່າຍທອດແຍກຕ່າງຫາກ. ເພື່ອເຮັດສິ່ງນີ້, ລູກຄ້າຟັງແຕ່ລະຫົວຂໍ້ Kafka ທີ່ມີຢູ່ສໍາລັບການເຂົ້າເຖິງພາຍນອກແລະພຽງແຕ່ພິມຂໍ້ຄວາມທີ່ໄດ້ຮັບໃນ console.
ເພື່ອເລີ່ມຕົ້ນການປະຕິບັດຂອງ ex ພື້ນຖານamples, run:
./build.sh run-basic –kafka-brokers localhost:9092 –account ACCOUNT_SHORTNAME
ບ່ອນທີ່ ACCOUNT_SHORTNAME ເປັນຊື່ຫຍໍ້ຂອງບັນຊີທີ່ທ່ານຕ້ອງການທີ່ຈະເອົາມາຕຣິກເບື້ອງຈາກ.
ເພື່ອຢຸດການປະຕິບັດຂອງ ex ໄດ້ample, ກົດ Ctrl + C. (ອາດຈະມີຄວາມລ່າຊ້າເລັກນ້ອຍກ່ອນທີ່ການປະຕິບັດຈະຢຸດເຊົາເພາະວ່າລູກຄ້າລໍຖ້າເຫດການຫມົດເວລາ.)
ໂໝດຂັ້ນສູງ
ໝາຍເຫດ: Metrics ແມ່ນສະແດງພຽງແຕ່ສໍາລັບຈໍ HTTP ທີ່ເຮັດວຽກຢູ່ໃນສູນຄວບຄຸມ.
ການປະຕິບັດໃນໂຫມດຂັ້ນສູງສະແດງໃຫ້ເຫັນຄວາມກ່ຽວຂ້ອງກັນລະຫວ່າງ metrics ແລະຂໍ້ຄວາມ metadata. ນີ້ເປັນໄປໄດ້ຍ້ອນມີຢູ່ໃນແຕ່ລະຂໍ້ຄວາມ metrics ຂອງຊ່ອງ id stream ທີ່ຫມາຍເຖິງຂໍ້ຄວາມ metadata ທີ່ສອດຄ້ອງກັນ.
ເພື່ອປະຕິບັດ ex ຂັ້ນສູງamples, run:
./build.sh run-advanced –kafka-brokers localhost:9092 –ບັນຊີ ACCOUNT_SHORTNAME
ບ່ອນທີ່ ACCOUNT_SHORTNAME ເປັນຊື່ຫຍໍ້ຂອງບັນຊີທີ່ທ່ານຕ້ອງການທີ່ຈະເອົາມາຕຣິກເບື້ອງຈາກ.
ເພື່ອຢຸດການປະຕິບັດຂອງ ex ໄດ້ample, ກົດ Ctrl + C. (ອາດຈະມີຄວາມລ່າຊ້າເລັກນ້ອຍກ່ອນທີ່ການປະຕິບັດຈະຢຸດເຊົາເພາະວ່າລູກຄ້າລໍຖ້າເຫດການຫມົດເວລາ.)
ການຕັ້ງຄ່າເພີ່ມເຕີມ
ມັນເປັນໄປໄດ້ທີ່ຈະດໍາເນີນການ examples ກັບການຕັ້ງຄ່າເພີ່ມເຕີມຂອງລູກຄ້າໂດຍໃຊ້ -config-file ທາງ​ເລືອກ​ປະ​ຕິ​ບັດ​ຕາມ​ໂດຍ a file ຊື່ທີ່ປະກອບດ້ວຍຄຸນສົມບັດໃນຮູບແບບ key=value.
./build.sh run-advanced \
–kafka-ນາຍໜ້າ localhost:9092 \
– ບັນຊີ ACCOUNT_SHORTNAME \
-config-file client_config.properties

ໝາຍເຫດ: ທັງໝົດ files ອ້າງອີງໃນຄໍາສັ່ງຂ້າງເທິງຈະຕ້ອງຢູ່ໃນໄດເລກະທໍລີປະຈຸບັນແລະອ້າງອີງໂດຍໃຊ້ພຽງແຕ່ເສັ້ນທາງທີ່ກ່ຽວຂ້ອງ. ນີ້ໃຊ້ທັງສອງກັບ -config-file argument ແລະທຸກລາຍການໃນການຕັ້ງຄ່າ file ທີ່ອະທິບາຍ file ສະຖານທີ່.
ການກວດສອບການກວດສອບລູກຄ້າພາຍນອກ
ເພື່ອກວດສອບຄວາມຖືກຕ້ອງຂອງລູກຄ້າຈາກພາຍນອກສູນຄວບຄຸມໂດຍໃຊ້ client-examples, ປະຕິບັດຂັ້ນຕອນຕໍ່ໄປນີ້:

• ຈາກໂຟນເດີ Paragon Active Assurance Control Center, ສະຫຼັບໄປຫາ paa-streaming-api-clientexamples folder:
  cd 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} ເປັນຂໍ້ມູນປະຈໍາຕົວຂອງຜູ້ໃຊ້ສໍາລັບລູກຄ້າ.
• ດໍາເນີນການພື້ນຖານ examples:
  ສົ່ງອອກ KAFKA_FQDN=
  ./build.sh run-basic –kafka-brokers ${KAFKA_FQDN}:9093 \
  – ບັນຊີ ACCOUNT_SHORTNAME
  -config-file client.properties
  ບ່ອນທີ່ ACCOUNT_SHORTNAME ເປັນຊື່ຫຍໍ້ຂອງບັນຊີທີ່ທ່ານຕ້ອງການທີ່ຈະເອົາມາຕຣິກເບື້ອງຈາກ.
• ດໍາເນີນການຂັ້ນສູງ examples:
  ສົ່ງອອກ KAFKA_FQDN=
  ./build.sh run-advanced –kafka-brokers ${KAFKA_FQDN}:9093 \
  – ບັນຊີ ACCOUNT_SHORTNAME
  -config-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}
ສ້າງອົງການໃບຢັ້ງຢືນຂອງທ່ານເອງ
ໝາຍເຫດ: ປົກກະຕິແລ້ວທ່ານຄວນມີໃບຢັ້ງຢືນຂອງທ່ານລົງນາມໂດຍອົງການໃບຢັ້ງຢືນທີ່ແທ້ຈິງ; ເບິ່ງສ່ວນຍ່ອຍກ່ອນໜ້ານີ້. ສິ່ງທີ່ຕໍ່ໄປນີ້ແມ່ນພຽງແຕ່ exampເລ.
ທີ່ນີ້ພວກເຮົາສ້າງໃບຢັ້ງຢືນການຮາກທີ່ເກີດຂອງພວກເຮົາ (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 ແມ່ນຊື່ໂດເມນທີ່ມີຄຸນສົມບັດຢ່າງເຕັມທີ່ຂອງລູກຄ້າ (ຊື່ໂຮດສາທາລະນະຂອງ node).
ໝາຍເຫດ: ມັນເປັນສິ່ງສໍາຄັນທີ່ FQDN ກົງກັບຊື່ໂຮດທີ່ແນ່ນອນທີ່ລູກຄ້າ Kafka ຈະໃຊ້ເພື່ອເຊື່ອມຕໍ່ກັບສູນຄວບຄຸມ.
sudo mkdir -p /var/ssl/private
sudo chown -R $USER: /var/ssl/private
cd /var/ssl/private
ສົ່ງອອກ FQDN=
keytool -keystore kafka.server.keystore.jks \
-alias server \
- ຄວາມຖືກຕ້ອງ 999 \
-genkey -keyalg RSA -ext SAN=dns:${FQDN}
ສ້າງຄໍາຮ້ອງຂໍການເຊັນໃບຢັ້ງຢືນແລະເກັບໄວ້ໃນ file ຊື່ cert-server-request:
keytool -keystore kafka.server.keystore.jks \
-alias server \
-certreq \
-file cert-server-request

ໃນປັດຈຸບັນທ່ານຄວນສົ່ງ file cert-server-request to your Certificate Authority (CA) ຖ້າທ່ານກໍາລັງໃຊ້ອັນແທ້ຈິງ. ຫຼັງຈາກນັ້ນເຂົາເຈົ້າຈະສົ່ງຄືນໃບຢັ້ງຢືນທີ່ໄດ້ເຊັນ. ພວກເຮົາຈະອ້າງເຖິງນີ້ເປັນ cert-server-signed ຂ້າງລຸ່ມນີ້.
ການເຊັນໃບຢັ້ງຢືນ SSL ໂດຍໃຊ້ໃບຢັ້ງຢືນ CA ທີ່ສ້າງເອງ
ໝາຍເຫດ: ອີກເທື່ອຫນຶ່ງ, ການນໍາໃຊ້ CA ຂອງທ່ານເອງບໍ່ໄດ້ຖືກແນະນໍາໃນລະບົບການຜະລິດ.
ເຊັນໃບຢັ້ງຢືນໂດຍໃຊ້ CA ໂດຍວິທີການ file cert-server-request, ເຊິ່ງຜະລິດໃບຢັ້ງຢືນທີ່ໄດ້ເຊັນ cert-server-signed. ເບິ່ງຂ້າງລຸ່ມນີ້; ca-password ແມ່ນລະຫັດຜ່ານທີ່ກໍານົດໄວ້ໃນເວລາສ້າງໃບຢັ້ງຢືນ CA.

cd /var/ssl/private
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 ເຂົ້າໄປໃນ keystore:
keytool -keystore kafka.server.keystore.jks \
-alias ca-cert \
- ການ​ນໍາ​ເຂົ້າ \
-file ${CA_PATH}/ca-cert
ນໍາເຂົ້າໃບຢັ້ງຢືນທີ່ໄດ້ເຊັນເອີ້ນວ່າ cert-server-signed:
keytool -keystore kafka.server.keystore.jks \
-alias server \
- ການ​ນໍາ​ເຂົ້າ \
-file cert-server-ເຊັນ
ໄດ້ file kafka.server.keystore.jks ຄວນຖືກຄັດລອກໄປທີ່ສະຖານທີ່ທີ່ຮູ້ຈັກໃນເຊີບເວີສູນຄວບຄຸມ, ແລະຫຼັງຈາກນັ້ນອ້າງອີງໃສ່ໃນ /etc/kafka/server.properties.

ການໃຊ້ Streaming API

ທົ່ວໄປ
API streaming ດຶງຂໍ້ມູນທັງການທົດສອບ ແລະການຕິດຕາມ. ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະແຍກອອກຈາກຫນຶ່ງໃນປະເພດເຫຼົ່ານີ້.
API streaming ບໍ່ໄດ້ດຶງຂໍ້ມູນຈາກການທົດສອບທີ່ອີງໃສ່ສະຄຣິບ (ທີ່ສະແດງໂດຍຮູບສີ່ຫລ່ຽມແທນທີ່ຈະເປັນຊິ້ນສ່ວນ jigsaw ໃນ Control Center GUI), ເຊັ່ນ: ການທົດສອບການເປີດໃຊ້ບໍລິການ Ethernet ແລະການທົດສອບຄວາມໂປ່ງໃສ.

ຊື່ຫົວຂໍ້ Kafka
ຊື່ຫົວຂໍ້ Kafka ສໍາລັບ streaming API ແມ່ນມີດັ່ງນີ້, ເຊິ່ງ %s ເປັນຊື່ສັ້ນຂອງບັນຊີ Control Center (ລະບຸໃນເວລາສ້າງບັນຊີ):

const (
exporterName = "kafka"
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 ສູນຄວບຄຸມ.
ຫນ້າທໍາອິດ, ມີ ex ພື້ນຖານample ສະແດງໃຫ້ເຫັນວິທີການ metrics ແລະ metadata ຂອງພວກມັນຖືກຖ່າຍທອດແຍກຕ່າງຫາກແລະພຽງແຕ່ພິມຂໍ້ຄວາມທີ່ໄດ້ຮັບໄປຫາ console. ທ່ານ​ສາ​ມາດ​ດໍາ​ເນີນ​ການ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:
sudo ./build.sh run-basic –kafka-brokers localhost:9092 –ບັນຊີ ACCOUNT_SHORTNAME
ນອກຈາກນີ້ຍັງມີ ex ກ້າວຫນ້າທາງດ້ານຫຼາຍample ບ່ອນທີ່ metrics ແລະຂໍ້ຄວາມ metadata ມີຄວາມກ່ຽວຂ້ອງກັນ. ໃຊ້ຄໍາສັ່ງນີ້ເພື່ອດໍາເນີນການມັນ:
sudo ./build.sh run-advanced –kafka-brokers localhost:9092 –ບັນຊີ ACCOUNT_SHORTNAME
ທ່ານຈໍາເປັນຕ້ອງໃຊ້ sudo ເພື່ອດໍາເນີນການຄໍາສັ່ງ Docker ເຊັ່ນຄໍາສັ່ງຂ້າງເທິງ. ທາງເລືອກອື່ນ, ທ່ານສາມາດປະຕິບັດຕາມຂັ້ນຕອນການຕິດຕັ້ງ Linux ເພື່ອສາມາດດໍາເນີນການຄໍາສັ່ງ 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 Streaming API Active Assurance [pdf] ຄູ່ມືຜູ້ໃຊ້ Streaming API Active Assurance, API Active Assurance, Active Assurance, ການ​ຮັບ​ປະ​ກັນ

ເອກະສານອ້າງອີງ

• ຄູ່ມືຜູ້ໃຊ້