Cách kết nối máy khách phân tán với cơ sở dữ liệu InfluxDB riêng

InfluxDB đã trở thành một cách phổ biến để các cảm biến và dịch vụ lưu trữ dữ liệu chuỗi thời gian và InfluxData giúp việc đó trở nên nhanh chóng và dễ dàng nhờ InfluxCloud. Tuy nhiên, một số khách hàng mà chúng tôi đã nói chuyện không lưu trữ mọi thứ trong dịch vụ đám mây được quản lý. Đôi khi, họ có lý do kinh doanh, quy định hoặc tuân thủ cụ thể để tự lưu trữ dữ liệu trong trung tâm dữ liệu của riêng họ. Những lần khác, họ đang sử dụng nhiều đầu ra trong Telegraf để gửi dữ liệu tới Đám mây InfluxDB như một phần trong kế hoạch khắc phục thảm họa của họ. cả Dù lý do là gì, việc để một máy khách kết nối với cơ sở dữ liệu InfluxDB riêng tư một cách an toàn có khả năng liên quan đến việc thiết lập các tuyến mạng, mở tường lửa, điều chỉnh NACL và các nhóm bảo mật. Chưa kể đến việc điều hướng bất kỳ quy trình nội bộ nào có thể liên quan để tất cả những thay đổi đó được phê duyệt và triển khai. Giá trị của InfluxDB không phải là thỉnh thoảng chỉ có một khách hàng ghi dữ liệu, mà là khả năng hỗ trợ hàng trăm hoặc nhiều hơn. Vì vậy, hãy lặp lại chi phí quản trị mạng đó cho từng thiết bị mới hoặc bất cứ khi nào cấu hình mạng của thiết bị thay đổi và bạn sẽ nhanh chóng gặp phải tình huống khiến việc duy trì các biện pháp kiểm soát mạng chặt chẽ đó trở nên không bền vững. Sau đó, hầu hết mọi người sẽ cân nhắc giữa một số tùy chọn: 1) Yêu cầu thiết lập VPN giữa máy khách từ xa và cơ sở dữ liệu InfluxDB của mạng. (Có thể) Quản trị viên mạng ít hoạt động hơn nơi InfluxDB đang chạy, nhưng một gánh nặng thiết lập cao hơn cho bất kỳ ai đang quản lý khách hàng. Và họ có thực sự muốn mạng của họ được kết nối với mạng của bạn thông qua VPN không? Hoặc 2) Hiển thị trực tiếp cơ sở dữ liệu InfluxDB với internet công cộng và tin tưởng hệ thống xác thực đủ để bảo vệ cơ sở dữ liệu đó. Hôm nay tôi sẽ đưa bạn qua một sự lựa chọn thứ ba. Sẽ chỉ mất vài phút để triển khai, không yêu cầu thay đổi mạng và sẽ giúp bạn không phải đưa cơ sở dữ liệu riêng tư của mình lên internet công cộng. Chúng tôi cũng sẽ nhận được rất nhiều lợi ích khác trong suốt quá trình mà tôi sẽ đề cập sau khi chúng tôi đã làm cho nó hoạt động. thiết lập ban đầu Nếu bạn muốn đi thẳng vào một ví dụ hoạt động về điều này, chúng tôi có sẵn trên GitHub một mà bạn có thể chạy cục bộ với Docker Compose. Nó sử dụng hình ảnh Docker chính thức cho InfluxDB và Telegraf, với các thay đổi đối với tập lệnh khởi động để mỗi dịch vụ sử dụng Ockam để thiết lập kết nối. Hướng dẫn đầy đủ về cách chạy nó được bao gồm trong . Bản demo InfluxDB + Telegraf + Ockam cho Docker README Để mô phỏng một ví dụ hoàn chỉnh về một ứng dụng khách gửi dữ liệu vào InfluxDB, chúng ta sẽ bắt đầu một phiên bản Telegraf, yêu cầu nó phát ra các sự kiện CPU tới InfluxDB, sau đó thay đổi cách hai kết nối đó để hiển thị cách chúng ta kết nối chúng trên các máy chủ hoặc mạng khác nhau. Vì lợi ích của ví dụ này, chúng tôi sẽ chạy mọi thứ trên một máy duy nhất. Okam Nếu trước đây bạn đã thiết lập Ockam, bạn có thể bỏ qua phần này và chuyển thẳng sang thiết lập InfluxDB bên dưới. brew install build-trust/ockam/ockam (nếu bạn không sử dụng brew để quản lý gói, chúng tôi có hướng dẫn cài đặt cho các hệ thống khác trong tài liệu của chúng tôi) Sau khi cài đặt, bạn cần đăng ký danh tính cục bộ của mình với Ockam Orchestrator, hãy chạy lệnh bên dưới và làm theo hướng dẫn được cung cấp: ockam enroll InfluxDB Nếu bạn đã chạy InfluxDB trên máy cục bộ của mình và có mã thông báo xác thực mà bạn có thể sử dụng để ghi vào đó, bạn có thể bỏ qua phần này và chuyển thẳng sang cài đặt Telegraf bên dưới. Điều kiện tiên quyết cho phần này là trước tiên phải cài đặt: InfluxDB dòng chảy CLI Sau khi cài đặt, chúng ta cần khởi động InfluxDB để có nơi lưu trữ dữ liệu số liệu mà chúng ta sẽ tạo. Trên hầu hết các hệ thống sẽ đơn giản như chạy: influxd Sau đó, bạn sẽ thấy một số đầu ra nhật ký, với dòng cuối cùng xác nhận rằng influxd hiện đang lắng nghe trên cổng : 8086 2023-02-21T23:49:43.106268Z info Listening {"log_id": "0fv9CURl000", "service": "tcp-listener", "transport": "http", "addr": ":8086", "port": 8086} Nếu dòng vào bắt đầu thành công thì bạn có thể mở một phiên cuối mới và để phiên này chạy ở chế độ nền. Nếu dòng vào không bắt đầu thành công, hãy kiểm tra cho các hệ điều hành khác nhau. tài liệu chính thức cho một số vấn đề phổ biến Bây giờ chúng ta sẽ sử dụng lệnh influx CLI để hoàn thành thiết lập cơ sở dữ liệu ban đầu để influxd có thể nhận dữ liệu của chúng ta. Chạy lệnh thiết lập và hoàn thành các lời nhắc bắt buộc, hãy nhớ tên tổ chức và bộ chứa mà bạn sử dụng vì chúng ta sẽ cần chúng sau này: influx setup Tiếp theo, bạn sẽ cần sao chép mã thông báo cho người dùng mà bạn vừa tạo, bạn có thể truy xuất bằng lệnh auth: influx auth list điện tín và sau khi được thiết lập, chúng tôi sẽ cần một tệp cấu hình xác định nguồn đầu vào và đích đầu ra của chúng tôi. Rất may, Telegraf bao gồm một lệnh để tạo một tệp như vậy, mà chúng tôi có thể chỉ định để được định cấu hình sẵn với việc sử dụng CPU của máy chủ của chúng tôi làm nguồn đầu vào và với InfluxDB làm đầu ra của chúng tôi. Cài đặt Telegraf Để tạo chạy cấu hình cơ sở: telegraf config \ --section-filter agent:inputs:outputs \ --input-filter cpu \ --output-filter influxdb_v2 > telegraf.conf Mở tệp telegraf.conf đã tạo và tìm phần có dạng như sau: [[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 = "" Thay thế các giá trị trống cho mã thông báo, tổ chức và nhóm bằng các giá trị từ phần trước về và lưu các thay đổi của bạn. Bây giờ bạn có thể bắt đầu Telegraf: thiết lập InfluxDB telegraf --config telegraf.conf Kiểm tra tất cả đều hoạt động Để dễ dàng sử dụng lại các giá trị của bạn cho các lệnh và thử nghiệm trong tương lai, hãy lưu trữ các giá trị phù hợp (nghĩa là thay thế các phần giữ chỗ bên dưới bằng các giá trị thực của bạn) vào một loạt các biến môi trường: export INFLUX_PORT=8086 \ INFLUX_TOKEN=your-token-here \ INFLUX_ORG=your-org \ INFLUX_BUCKET=your-bucket Bây giờ chúng ta có thể kiểm tra xem Telegraf có thường xuyên gửi dữ liệu đến InfluxDB hay không. Cấu hình chúng tôi đã tạo trước đó sẽ phát ra số liệu thống kê CPU cứ sau 10 giây, vì vậy chúng tôi có thể gửi truy vấn tới InfluxDB và vì nó sẽ trả về tất cả dữ liệu mà nó có trong 1 phút qua: 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 Kết nối an toàn Telegraf + InfluxDB riêng với Ockam Ví dụ trên kết nối hai dịch vụ này, chạy trên cùng một máy chủ, bằng cách sử dụng phương thức vận chuyển HTTP không được mã hóa mặc định. Hầu hết các cấu hình không tầm thường sẽ có InfluxDB chạy trên một máy chủ riêng biệt với một hoặc nhiều nút Telegraf gửi dữ liệu vào. Trong quá trình sản xuất, việc truyền tải không mã hóa có thể không được chấp nhận, cũng không phải lúc nào cũng mong muốn có khả năng đưa cổng InfluxDB ra internet công cộng. Trong phần này, chúng tôi sẽ chỉ cho bạn cách giải quyết cả hai vấn đề này với những thay đổi cấu hình rất nhỏ đối với bất kỳ dịch vụ hiện có nào. Tạo và đăng ký các nút của bạn Bước đầu tiên là đăng ký bản thân với Ockam, lưu thông tin dự án của bạn và tạo mã thông báo đăng ký cho các nút InfluxDB và Telegraf của bạn: 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) Bây giờ chúng ta có thể tạo một nút cho dịch vụ InfluxDB của mình: 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 Có một số điều đã xảy ra trong các lệnh đó, vì vậy hãy nhanh chóng giải nén chúng: Chúng tôi đã tạo một nút mới có tên là và đã đăng ký nút đó với Ockam bằng cách sử dụng mã thông báo mà chúng tôi đã tạo trước đó. Nếu bạn nhìn lại lệnh đã tạo mã thông báo, bạn sẽ thấy chúng tôi cũng đã gắn thẻ mã thông báo này với một thuộc tính là . influxdb component=influxdb Sau đó, chúng tôi đã thêm một chính sách vào nút , quy định rằng chỉ những nút có thuộc tính có giá trị mới có thể kết nối với ổ cắm TCP. influxdb component telegraf Tiếp theo, chúng tôi tạo một ổ cắm TCP. Đây giống như một đường dẫn từ nút mà chúng ta vừa tạo tới cổng TCP (nghĩa là cổng mà cơ sở dữ liệu InfluxDB của chúng ta đang lắng nghe). Nút Ockam này hiện sẽ chuyển bất kỳ dữ liệu nào mà nó nhận được từ các nút khác đến đích đó. Tuy nhiên, các nút duy nhất có thể thiết lập kết nối đó là những nút vượt qua chính sách được xác định ở bước trước. influxdb 127.0.0.1:8086 Cuối cùng, chúng tôi tạo một trình chuyển tiếp trong dự án của chúng tôi, hiện cho phép các nút khác trong dự án của chúng tôi phát hiện ra và định tuyến lưu lượng truy cập tới nó. influxdb Bây giờ là lúc thiết lập phía bên kia của kết nối này bằng cách tạo nút máy khách tương ứng cho Telegraf: 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 Bây giờ chúng ta có thể giải nén ba lệnh này và những gì chúng đã thực hiện: Như trước đây, chúng tôi đã sử dụng mã thông báo đăng ký mà chúng tôi đã tạo để tạo một nút mới và đăng ký nó với dự án của chúng tôi. Lần này là nút . telegraf Chúng tôi lại áp dụng một chính sách để cải thiện tình hình bảo mật của mình. Chính sách này cho phép tạo đầu vào TCP nhưng chỉ khi nút ở đầu kia có thuộc tính có giá trị là . component influxdb Cuối cùng, chúng tôi tạo đầu vào TCP. Đây là một cách xác định vị trí nút sẽ lắng nghe các kết nối (trong trường hợp này là trên cổng TCP ) và vị trí nút sẽ chuyển tiếp lưu lượng truy cập đó đến. Nút này sẽ chuyển tiếp dữ liệu qua trình chuyển tiếp mà chúng tôi đã tạo trước đó, nút này sẽ lần lượt chuyển dữ liệu tới nút influxdb của chúng tôi, sau đó nút này sẽ gửi dữ liệu tới cơ sở dữ liệu InfluxDB. 8087 Đó là nó! Trình nghe trên cổng của máy chủ cục bộ hiện đang chuyển tiếp tất cả lưu lượng truy cập đến InfluxDB, bất kể nó đang chạy ở đâu. Nếu cơ sở dữ liệu đó nằm trên một máy chủ khác, chạy trên đám mây hoặc trong một trung tâm dữ liệu riêng tư, việc đăng ký và chuyển tiếp sẽ vẫn đảm bảo thông tin liên lạc của chúng tôi với sẽ được kết nối an toàn với bất kỳ nơi nào cơ sở dữ liệu đó đang chạy. 8087 127.0.0.1:8087 Cập nhật cấu hình hiện có để sử dụng kết nối an toàn Ví dụ này đã tạo đầu vào TCP trên cổng chủ yếu vì dịch vụ dòng vào đang chạy trên cùng một máy chủ và đã được liên kết với cổng . Trong triển khai sản xuất nơi Telegraf và InfluxDB nằm trên các máy chủ riêng biệt, đầu vào TCP có thể lắng nghe trên cổng và cấu hình mặc định này sẽ không cần thay đổi. 8087 8086 8086 Mặc dù đây là một ví dụ đơn giản hóa chạy trên một máy chủ duy nhất, các hướng dẫn sau đây giống nhau bất kể triển khai của bạn là gì. Sau khi các nút và được đăng ký và đang chạy, thay đổi duy nhất bạn cần thực hiện là cập nhật telegraf.conf để trỏ đến cổng nghe cục bộ: influxdb telegraf [[outputs.influxdb_v2]] urls = ["http://127.0.0.1:8087"] Khởi động lại dịch vụ Telegraf và sau đó chúng tôi có thể kiểm tra xem nó có còn lưu trữ dữ liệu hay không bằng cách sử dụng cùng một lệnh mà chúng tôi đã sử dụng trước đó.z Các máy khách được kết nối an toàn và hơn thế nữa... Ví dụ ở đây, trong vòng chưa đầy 10 phút, đã giải quyết vấn đề cấp bách nhất của chúng tôi đồng thời bổ sung một số cải tiến có giá trị không rõ ràng ngay lập tức vì chúng đã được trừu tượng hóa: InfluxDB của bạn chưa có cổng tiếp xúc với internet công cộng và do đó, không có cách nào để các bên thứ ba truy cập Cơ sở dữ liệu riêng tư luôn ở chế độ riêng tư: Kênh bảo mật được thiết lập giữa các nút của bạn được mã hóa từ đầu đến cuối. Mỗi nút tạo các khóa mật mã riêng và được cấp thông tin xác thực duy nhất của riêng nó. Sau đó, họ sử dụng những thứ này để thiết lập một kênh an toàn đáng tin cậy lẫn nhau. Bằng cách loại bỏ sự phụ thuộc vào dịch vụ của bên thứ ba để lưu trữ hoặc phân phối khóa, bạn có thể giảm diện tích bề mặt dễ bị tổn thương và loại bỏ các điểm lỗi đơn lẻ. Được mã hóa khi chuyển tiếp: Việc ủy quyền thậm chí thiết lập tuyến đến cơ sở dữ liệu InfluxDB được gắn với danh tính duy nhất của ứng dụng khách yêu cầu quyền truy cập, điều này vừa linh hoạt hơn về mặt hỗ trợ, vừa là phương pháp triển khai năng động và hiện đại, đồng thời cũng phù hợp rõ ràng hơn với ý định của chúng tôi về kiểm soát truy cập. Nếu khách hàng của họ có thể thiết lập niềm tin rằng họ là người mà họ nói thì họ có thể định tuyến các gói của mình đến cơ sở dữ liệu. Ngược lại với các cách tiếp cận lịch sử mà một quyết định truy cập vĩnh viễn dựa trên các giả định về mạng từ xa (ví dụ: yêu cầu này có đến từ một địa chỉ IP mà chúng tôi đã ủy quyền trước không?). Điều này cho các kiểm soát xác thực và ủy quyền trên chính cơ sở dữ liệu InfluxDB sẽ tiếp tục hoạt động như bình thường. Kiểm soát truy cập dựa trên danh tính & thuộc tính: bổ sung Sự kết hợp của tất cả những điều trên có nghĩa là cách để truy cập cơ sở dữ liệu InfluxDB là qua một kênh bảo mật, có nghĩa là tất cả các giao tiếp đều được mã hóa khi truyền đi bất kể có bất kỳ cấu hình sai nào ở một trong hai đầu (ví dụ: HTTP/TLS không được kích hoạt). Và bởi vì mỗi nút trao đổi thông tin đăng nhập với nhau thay vì chia sẻ chứng chỉ chung hoặc khóa mã hóa dùng chung, bạn cũng có thể chắc chắn rằng: Bảo mật theo thiết kế: duy nhất Không có bên nào khác trong chuỗi cung ứng có thể sửa đổi dữ liệu trong quá trình vận chuyển. Dữ liệu bạn nhận được từ người tiêu dùng chính xác là những gì khách hàng của bạn đã gửi. Chỉ những khách hàng được ủy quyền mới có thể ghi vào InfluxDB, đảm bảo rằng dữ liệu trong chủ đề của bạn rất đáng tin cậy. Nếu bạn có các yêu cầu nghiêm ngặt hơn nữa, bạn có thể kiểm soát cơ quan cấp chứng chỉ của mình và thực thi các chính sách cấp quyền chi tiết. Ockam đơn giản hóa các mối quan tâm về quyền truy cập của khách hàng bằng cách hiển thị tất cả các dịch vụ từ xa dưới dạng dịch vụ cục bộ. chúng tôi gọi đây là . Khi tất cả các thành phần từ xa của một ứng dụng hầu như liền kề với mọi thành phần khác, thì độ phức tạp về bảo mật và tin cậy của toàn bộ mạng, toàn bộ cơ sở hạ tầng, toàn bộ internet sẽ hoàn toàn bị loại bỏ. Tất cả các trung gian bên thứ ba đều bị xóa khỏi bề mặt lỗ hổng của ứng dụng. Giảm diện tích bề mặt dễ bị tổn thương: lân cận ảo Bước tiếp theo Nếu bạn chưa làm theo ví dụ trong hướng dẫn này, bạn có thể miễn phí bằng cách làm theo hướng dẫn trong tài liệu của chúng tôi. bắt đầu sử dụng Ockam Nếu bạn muốn nói cụ thể về điều này hoặc các trường hợp sử dụng tiềm năng khác cho Ockam, nhóm sẽ rất sẵn lòng . tṛ chuyện với bạn Ngoài ra, bạn có thể tham gia cùng chúng tôi và cộng đồng các nhà phát triển ngày càng phát triển, những người muốn xây dựng lòng tin bằng cách tạo ra các ứng dụng an toàn theo thiết kế, trong hoặc trên . Xây dựng cộng đồng Trust Máy chủ Discord Github Cũng được xuất bản . ở đây