DEV Community: esga1102

Setup OpenSearch,Logstash,Kafka locally with Docker Compose (windows)

esga1102 — Thu, 17 Oct 2024 03:09:58 +0000

Directory tree


  D:/
 -  opensearch
       + kafka
          - docker-compose.yaml
       + logstash
         + pipeline
            - input.conf
         - docker-compose.yaml
    - .env
    - docker-compose.yaml

opensearch

add docker-compose file with content :

version: '3'
services:
  opensearch-node1: # This is also the hostname of the container within the Docker network (i.e. https://opensearch-node1/)
    image: opensearchproject/opensearch:latest # Specifying the latest available image - modify if you want a specific version
    container_name: opensearch-node1
    environment:
      - cluster.name=opensearch-cluster # Name the cluster
      - node.name=opensearch-node1 # Name the node that will run in this container
      - discovery.seed_hosts=opensearch-node1,opensearch-node2 # Nodes to look for when discovering the cluster
      - cluster.initial_cluster_manager_nodes=opensearch-node1,opensearch-node2 # Nodes eligible to serve as cluster manager
      - bootstrap.memory_lock=true # Disable JVM heap memory swapping
      - "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m" # Set min and max JVM heap sizes to at least 50% of system RAM
      - OPENSEARCH_INITIAL_ADMIN_PASSWORD=${OPENSEARCH_INITIAL_ADMIN_PASSWORD}    # Sets the demo admin user password when using demo configuration, required for OpenSearch 2.12 and later
    ulimits:
      memlock:
        soft: -1 # Set memlock to unlimited (no soft or hard limit)
        hard: -1
      nofile:
        soft: 65536 # Maximum number of open files for the opensearch user - set to at least 65536
        hard: 65536
    volumes:
      - opensearch-data1:/usr/share/opensearch/data # Creates volume called opensearch-data1 and mounts it to the container
    ports:
      - 9200:9200 # REST API
      - 9600:9600 # Performance Analyzer
    networks:
      - opensearch-net # All of the containers will join the same Docker bridge network
  opensearch-node2:
    image: opensearchproject/opensearch:latest # This should be the same image used for opensearch-node1 to avoid issues
    container_name: opensearch-node2
    environment:
      - cluster.name=opensearch-cluster
      - node.name=opensearch-node2
      - discovery.seed_hosts=opensearch-node1,opensearch-node2
      - cluster.initial_cluster_manager_nodes=opensearch-node1,opensearch-node2
      - bootstrap.memory_lock=true
      - "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m"
      - OPENSEARCH_INITIAL_ADMIN_PASSWORD=${OPENSEARCH_INITIAL_ADMIN_PASSWORD}
    ulimits:
      memlock:
        soft: -1
        hard: -1
      nofile:
        soft: 65536
        hard: 65536
    volumes:
      - opensearch-data2:/usr/share/opensearch/data
    networks:
      - opensearch-net
  opensearch-dashboards:
    image: opensearchproject/opensearch-dashboards:latest # Make sure the version of opensearch-dashboards matches the version of opensearch installed on other nodes
    container_name: opensearch-dashboards
    ports:
      - 5601:5601 # Map host port 5601 to container port 5601
    expose:
      - "5601" # Expose port 5601 for web access to OpenSearch Dashboards
    environment:
      OPENSEARCH_HOSTS: '["https://opensearch-node1:9200","https://opensearch-node2:9200"]' # Define the OpenSearch nodes that OpenSearch Dashboards will query
    networks:
      - opensearch-net
volumes:
  opensearch-data1:
  opensearch-data2:
networks:
  opensearch-net:
  kafka_opensearch-net:
    external: true

then add .env file with your password :
OPENSEARCH_INITIAL_ADMIN_PASSWORD=mypassword1@2

kafka

add docker-compose file with content :

version: '3'

services:
  zookeeper:
    container_name: zookeeper-cntr
    image: confluentinc/cp-zookeeper:7.2.0
    environment:
      ZOOKEEPER_CLIENT_PORT: 2181
      ZOOKEEPER_TICK_TIME: 2000
    networks:
      - opensearch-net
  kafka:
    container_name: kafka-cntr
    image: confluentinc/cp-kafka:7.2.0
    depends_on:
      - zookeeper
    ports:
      - 29092:29092
    environment:
      KAFKA_BROKER_ID: 1
      KAFKA_ZOOKEEPER_CONNECT: zookeeper-cntr:2181
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://kafka-cntr:9092,PLAINTEXT_HOST://localhost:29092
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: PLAINTEXT:PLAINTEXT,PLAINTEXT_HOST:PLAINTEXT
      KAFKA_INTER_BROKER_LISTENER_NAME: PLAINTEXT
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
      KAFKA_ADVERTISED_HOST_NAME: localhost
    networks:
      - opensearch-net
    healthcheck:
      test: nc -vz kafka-cntr 9092 || exit -1
      # start_period: 15s
      interval: 5s
      timeout: 10s
      retries: 10
networks:
  opensearch-net:

logstash

add docker-compose file with content :

version: '3'

services:
  logstash:
    image: opensearchproject/logstash-oss-with-opensearch-output-plugin:8.4.0
    ports:
      - "5044:5044"
    expose:
      - "5044"
    volumes:
      - ./pipeline:/usr/share/logstash/pipeline
    networks:
      - opensearch_opensearch-net  
      - kafka_opensearch-net
networks:
  opensearch_opensearch-net:
    external: true
  kafka_opensearch-net:
    external: true

pipeline

add input.conf file with content :

input {
 kafka
    {
        bootstrap_servers => "kafka-cntr:9092"
        topics => "ServiceCentrallog"
        codec => json
    }
}

filter {
    mutate {
      remove_field => ["event"]
    }  
}
output {
  opensearch {
    hosts       => ["https://opensearch-node1:9200"]
    user        => "admin"
    password    => "mypassword1@2"
    index       => "service-centrallog-%{+YYYY.MM.dd}"
    ssl_certificate_verification => false
    ecs_compatibility => disabled
  }
}

Step 1 : Run opensearch docker-compose
Step 2 : Run kafka docker-compose
Step 3 : Run logtash after kafka has finished starting
Local application can send log to kafka via: 127.0.0.1:29092
If opensearch fails to
start : https://stackoverflow.com/questions/51445846/elasticsearch-max-virtual-memory-areas-vm-max-map-count-65530-is-too-low-inc

Oracle REST

esga1102 — Mon, 22 Jan 2024 15:51:14 +0000

Biến Oracle database thành một dịch vụ Restful API là một trong những tiện ích được ORACLE cung cấp dưới tên gọi ORDS (Oracle REST data service), là một dịch vụ REST API nhưng bản thân ORDS sẽ không thể thay thế hoàn toàn một web api server thực sự ( giao tiếp giữa các dịch vụ, xử dụng cache…), tuy nhiên ORDS vẫn có một số lợi thế nhất định trong phát triển ứng dụng web mà chúng ta có thể xem xét.

Trên tư tưởng của API . Khi giải quyết các chủ đề kỹ thuật, thật dễ dàng để chỉ tập trung vào công nghệ. Nhưng sự phát triển ưu tiên API không chỉ là các tiêu chuẩn kỹ thuật. Đó là một cách làm việc và cộng tác. Thay vì chỉ quan tâm đến các chi tiết cụ thể của từng API, cách tiếp cận ưu tiên API thiên về việc xem xét các nhóm và hoạt động xung quanh các API đó của bạn.

I.Oracle REST data service là gì?

Oracle REST data service là một ứng dụng dạng mid-tier, ORDS sẽ cung cấp API theo tiêu chuẩn REST cho cơ sở dữ liệu Oracle. Với ORDS chúng ta có thể biến cơ sở dữ liệu Oracle thành dịch vụ API RESTful. Một mô hình triển khai thường sẽ như sau :

Trong hình ORDS sẽ đóng vai trò làm API web server để kết nối đến CSDL. ORDS chỉ chứa config và không giữ logic nghiệp vụ
Logic nghiệp vụ lúc này sẽ chỉ nằm trên database.
ORDS có thể kết nối đến nhiều CSDL.
ORDS hỗ trợ authentication dựa trên OAuth2, một số tính năng được hỗ trợ : a. HTTP Basic Authentication b. API Key Authentication c. OAuth Authentication and Authorization d. Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) with Identity Domains Authentication e. Oracle Identity Cloud Service (IDCS) Authentication

2 ORDS & API first & Database first

Oracle REST data service là một công cụ ánh xạ trực tiếp giữa thiết kế database và API, linh hoạt cho nghiệp vụ doanh nghiệp. Bất kì thay đổi của cơ sở dữ liệu sẽ được cập nhật ngay cho dịch vụ API, điều này là một lợi thế rất lớn và nó đặc biệt hữu dụng trong trường hợp ứng dụng được phát triển dưới dạng chiến lược API (API First) song hành với Database First.
Chiến lược ưu tiên API là lý tưởng cho kiến trúc vi dịch vụ vì chiến lược này đảm bảo hệ sinh thái ứng dụng bắt đầu dưới dạng hệ thống mô-đun và có thể tái sử dụng. Bằng cách nhấn mạnh các API từ sớm, cấu trúc của các yêu cầu và dữ liệu API được làm nổi bật. Điều này cho phép API cung cấp những gì nhà phát triển cần nhất và tránh dành thời gian của nhà phát triển cho các tính năng mà sau này hóa ra là không mong muốn.

2.1 Use case

Mặc dù ORDS có thể phát triển ứng dụng REST API rất nhanh, nhưng bản thân nó cũng có một nhược điểm rất lớn. Hệ thống API bên ngoài có thể dễ dàng call API của ORDS nhưng không có chiều ngược lại, ORDS không được thiết kế để giao tiếp với server nào khác ngoài oracle database server

2.1.1 Vì vậy hãy dùng ORDS khi

ORDS là tầng cung cấp dịch vụ dữ liệu ngoài cùng.
Là dịch vụ stateless và cô lập.
ORDS lý tưởng cho ứng dụng dạng database first. Đơn giản bởi vì khi thay thế nó bởi một hệ thống backend mạnh mẽ hơn, thì cũng không tốn chi phí cho việc test lại nghiệp vụ.
Có thể cân nhắc build-in tiến trình ORDS trong phát triển dịch vụ dạng low-code.
Trong trường hợp cần tích hợp với nhiều dịch vụ API, vẫn có thể sử dụng ORDS để tạo API logic nghiệp vụ cho các bên tích hợp trước cho đến khi hệ thống backend server được hoàn thành ( không bị duplicate công việc bởi ORDS không chứa code logic ).

3.Cách cấu hình ORDS

Link : https://www.oracle.com/database/technologies/appdev/rest-data-services-downloads-2043.html

Bước 1 : Run file ords, cấu hình theo các step như ảnh dưới

Bước 2 : Enable Rest service trong Oracle Database

Bước 3: Tạo Rest module

3.1 Rest module trong Rest data service

3.2 Tạo demo module và publish

3.3 Tạo api trên module

3.4 Kết quả

3.4 Xử lý logic nghiệp vụ bằng cách tạo 1 handler cho api vừa tạo

Chọn phương thức REST

3.5 Tạo logic và lưu kết quả

Kết quả cuối cùng

4 Tính năng mở rộng

Bên cạnh tính năng cấu hình làm REST service, ORDS cũng cung cấp giải pháp cho authentication, cache, HA … Chúng ta có thể xem hướng dẫn tại đây :
https://www.oracle.com/database/technologies/appdev/rest/best-practices/

Kafka KRaft Mode

esga1102 — Mon, 22 Jan 2024 15:36:34 +0000

Apache Kafka without Zookeeper

Tài liệu này sẽ nói về Kafka ở chế độ KRAFT. KRAFT có ý nghĩa giờ đây Kafka sẽ tổ chức lại hoạt động của cluster dựa theo concept của thuật toán RAFT, lý do cho việc thay đổi này là do những hạn chế của Zookeeper trong các phiên bản cũ.

Về RAFT, RAFT là thuật toán đồng thuận được sử dụng phổ biến cho các hệ thống phân tán, một số hệ thống phổ biến :

RabbitMQsử dụng Raft để thay thế loại hang đợi mirror (replicated) sang quorum queue.
MongoDBsử dụng một biến thể Raft trong replication set.
SplunkEnterprise sử dụng Raft trong cơ chế Search Head Cluster (SHC)…v.v.

Với RAFT, đây là thuật toán rất thú vị trong tư tưởng về lập trình hệ thống phân tán. Tài liệu này không mô tả về RAFT tuy nhiên để tiếp cận nhanh nhất thuật toán này trong vài phút thì dưới đây là đường dẫn visualization mô phỏng thuật toán :
http://thesecretlivesofdata.com/raft/

1.Vấn đề của Zookeeper

Zookeeper dường như là một phần không thể tách rời khi vận hành một hệ thống phân tán như Kafka nhưng nó có một số hạn chế khiến Kafka không thể phát huy hết khả năng của mình. Quy mô Kafka gặp phải bottleneck hiệu suất với Zookeeper

Hãy nhìn vào kiến trúc sau (hình ảnh từ confluence kafka):

Kafka metadata : mô tả các borkers hiện có,thông tin về máy chủ và port . Đồng thời cung cấp thông tin về vị trí lưu trữ của borker host nào đang lưu trữ partition nào.
Kafka controller: node đóng vai trò làm bộ điều khiển còn gọi là bộ điều khiển kafka

• Đối với mô hình Zookeeper trên, mỗi cụm có một node duy nhất đóng vai trò là bộ điều khiển (controller) được bầu chọn bởi những ZooKeeper watchers.
• Nó lưu trữ partition logs, xử lý consume/produce giống như các broker khác và duy trì siêu dữ liệu cụm như ID broker, racks, topic, partition, leader, thông tin ISR(in-sync replicas) và cấu hình toàn cụm theo mỗi topic, cũng như thông tin đăng nhập bảo mật.
• Kết quả là phần lớn lưu lượng đọc và ghi của ZooKeeper được thực hiện bởi node controller.
• Controller đọc trạng thái của zookeeper và cập nhật metadata cho từng brokers một cách lần lượt và tuần tự. Zookeeper là nguồn metadata cho kafka, giữ thông tin trạng thái cụm kafka.
• Giả sử một node trong cụm bị tắt dẫn đến metadata thay đổi, controller sẽ phải ghi lại metadata mới vào Zookeeper đồng thời controller sẽ update lần lượt metadata cho lần lượt từng borker, trong quá trình đó vấn đề ở đây khi client cố gắng tìm kiếm leader bằng cách query thông tin từ broker client có khả năng sẽ không có câu trả lời, vì broker mà client đang tham khảo chưa được cập nhật lại thông tin trạng thái cụm.
• Việc thiết lập cụm kafka sẽ phụ thuộc vào zookeeper, vấn đề lớn nhất ở đây là 2 hệ thống hoàn toàn khác biệt. Zookeeper là hệ thống bên ngoài kafka có nghĩa nó đi kèm với cú pháp tập lệnh điều khiển, cấu hình riêng của nó. Do đó khi bạn triển khai cụm cluster kafka bạn cũng phải quản lý, triển khai và giám sát Zookeeper.
• Kafka & zookeeper triển khai 2 hệ thống sẽ không hiệu quả về mặt tài nguyên.
• Với Zookeeper khả năng mở rộng của Kafka bị hạn chế. Mỗi khi khởi động cluster ,controller node Kafka phải tải trạng thái cluster từ Zookeeper, điều tương tự cũng xảy khi một Kafka broker tham gia vào cluster hoặc rời khỏi cluster , Zookeeper sẽ thực hiện lại việc bầu chọn leader, khi tiến trình này diễn ra Zookeeper sẽ làm chậm cụm (cluster), lượng metadata lớn dần theo thời gian dẫn đến việc tải lại metadata trở nên dần kém hiệu quả và làm hạn chế số lượng phân vùng mà cụm có thể lưu trữ theo confluent số lượng này tối đa là 200.000.
• Để vượt qua các thách thức của Zookeeper ở Kafka , một KIP (Kafka improvement plan) đã được xuất bản đó là KIP-500 (https://cwiki.apache.org/confluence/display/KAFKA/KIP-500%3A+Replace+ZooKeeper+with+a+Self-Managed+Metadata+Quorum). Trong phiên bản phát hành mới nhất , Zookeeper có thể được thay thế bằng một nhóm bộ điều khiển RAFT nội bộ. Bắt đầu từ phiên bản thử nghiệm 2.8.0 . Tuy nhiên cho đến khi phiên bản 4.0.0 phát hành trong tương lai thì các phiên bản hiện tại mới chỉ là bridge release.

2.Các thay đổi về kiến trúc cluster Kafka

Hình ảnh dưới đây mô tả sự khác biệt giữa kiến trúc cũ và kiến trúc mới được khuyến nghị

• Trong kiến trúc được đề xuất, ba nút điều khiển thay thế cho ba nút ZooKeeper.
• Trong kiến trúc cũ zoopkeeper , node controller sẽ phải chủ động update trạng thái cho các node broker trong cụm theo hướng mũi tên.
• Giờ đây thay vì controller đưa ra các bản cập nhật cho các borker node, các borker node sẽ tự lấy metadata từ leader này . Trong các node controller , các node controller đang là follower (màu xanh) sẽ follow metadata từ controller leader (màu cam), tất cả controller sẽ cùng theo dõi trạng thái mới nhất metadata , điều này làm cho quá trình chuyển đổi dự phòng hầu như không bị tải lại metadata khi chuyển sang trạng thái mới. Cũng giống như Zookeeper, Raft yêu cầu phần lớn các node chạy để tiếp tục chạy, do đó cần tối thiểu 3 node cho một mô hình cụm cluster raft.
Mặc dù các quy trình của controller tách biệt về mặt logic với các quy trình của borker, nhưng chúng không cần phải tách biệt về mặt vật lý

2.2 Mô hình triển khai

Một cụm tối thiểu sẽ triển khai như sau :

Các broker A và broker B sẽ lắng nghe event từ metadata topic , broker C leader sẽ là nguồn ghi event vào metadata topic. Khi leader C bị lỗi việc tải lại metadata sẽ không còn mất thời gian vì cả broker A và B đều đã có metadata trong bộ nhớ của nó. Ngoài ra Broker C có 1 một chu kì snapshot để hạn chế kích thước của metadata topic.

Hình bên dưới là kiến trúc nếu ta triển khai tách biệt vai trò giữa các nút trong cụm.

file setup docker-compose :

version: '3'
networks:
  default:
    name: kafka_raft
services:
 kafka-1:
    image: bitnami/kafka:3.2.3
    container_name: kafka1
    hostname: node1
    user: root
    ports:
      - 19092:19092 #controller port
      - 9094:9094  
    environment:
      - KAFKA_BROKER_ID=1
      - KAFKA_CFG_NODE_ID=1
      - KAFKA_ENABLE_KRAFT=yes 
      - KAFKA_CFG_PROCESS_ROLES=controller,broker
      - KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAP=CONTROLLER:PLAINTEXT,EXTERNAL:PLAINTEXT,CLIENT:PLAINTEXT
      - KAFKA_CFG_LISTENERS=CLIENT://0.0.0.0:9092,CONTROLLER://0.0.0.0:19092,EXTERNAL://:9094
      - KAFKA_CFG_ADVERTISED_LISTENERS=CLIENT://127.0.0.1:9092,EXTERNAL://127.0.0.1:9094
      - KAFKA_KRAFT_CLUSTER_ID=kkdhsaJUsdnnxjNNjjddtr  
      - ALLOW_PLAINTEXT_LISTENER=yes
      - KAFKA_CFG_CONTROLLER_QUORUM_VOTERS=1@node1:19092,2@node2:19093,3@node3:19094
      - KAFKA_CFG_CONTROLLER_LISTENER_NAMES=CONTROLLER
      - KAFKA_CFG_BROKER_LISTENER_NAMES=PLAINTEXT
      - KAFKA_HEAP_OPTS=-Xmx256m -Xms256m
      - BITNAMI_DEBUG=true
      - KAFKA_CFG_INTER_BROKER_LISTENER_NAME=CLIENT
 kafka-2:
    image: bitnami/kafka:3.2.3
    container_name: kafka2
    hostname: node2
    user: root
    ports:
      - 19093:19093 #external port controller
      - 9095:9095    
    environment:
      - KAFKA_BROKER_ID=2
      - KAFKA_CFG_NODE_ID=2
      - KAFKA_ENABLE_KRAFT=yes 
      - KAFKA_CFG_PROCESS_ROLES=controller,broker
      - KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAP=CONTROLLER:PLAINTEXT,EXTERNAL:PLAINTEXT,CLIENT:PLAINTEXT
      - KAFKA_CFG_LISTENERS=CLIENT://0.0.0.0:9092,CONTROLLER://0.0.0.0:19093,EXTERNAL://0.0.0.0:9095
      - KAFKA_CFG_ADVERTISED_LISTENERS=CLIENT://127.0.0.1:9092,EXTERNAL://127.0.0.1:9095
      - KAFKA_KRAFT_CLUSTER_ID=kkdhsaJUsdnnxjNNjjddtr  
      - ALLOW_PLAINTEXT_LISTENER=yes
      - KAFKA_CFG_CONTROLLER_QUORUM_VOTERS=1@node1:19092,2@node2:19093,3@node3:19094
      - KAFKA_CFG_CONTROLLER_LISTENER_NAMES=CONTROLLER
      - KAFKA_CFG_BROKER_LISTENER_NAMES=PLAINTEXT
      - KAFKA_HEAP_OPTS=-Xmx256m -Xms256m
      - BITNAMI_DEBUG=true
      - KAFKA_CFG_INTER_BROKER_LISTENER_NAME=CLIENT
 kafka-3:
    image: bitnami/kafka:3.2.3
    container_name: kafka3
    hostname: node3
    user: root
    ports:
      - 19094:19094 #external port controller
      - 9096:9096  
    environment:
      - KAFKA_BROKER_ID=3
      - KAFKA_CFG_NODE_ID=3
      - KAFKA_ENABLE_KRAFT=yes 
      - KAFKA_CFG_PROCESS_ROLES=controller,broker
      - KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAP=CONTROLLER:PLAINTEXT,EXTERNAL:PLAINTEXT,CLIENT:PLAINTEXT
      - KAFKA_CFG_LISTENERS=CLIENT://0.0.0.0:9092,CONTROLLER://0.0.0.0:19094,EXTERNAL://0.0.0.0:9096
      - KAFKA_CFG_ADVERTISED_LISTENERS=CLIENT://127.0.0.1:9092,EXTERNAL://127.0.0.1:9096
      - KAFKA_KRAFT_CLUSTER_ID=kkdhsaJUsdnnxjNNjjddtr  
      - ALLOW_PLAINTEXT_LISTENER=yes
      - KAFKA_CFG_CONTROLLER_QUORUM_VOTERS=1@node1:19092,2@node2:19093,3@node3:19094
      - KAFKA_CFG_CONTROLLER_LISTENER_NAMES=CONTROLLER
      - KAFKA_CFG_BROKER_LISTENER_NAMES=PLAINTEXT
      - KAFKA_HEAP_OPTS=-Xmx256m -Xms256m
      - BITNAMI_DEBUG=true
      - KAFKA_CFG_INTER_BROKER_LISTENER_NAME=CLIENT

Cài đặt

Run docker file với lệnh : docker-compose -f multi-node.yml up
Bật cửa sổ cmd truy cập vào node để tạo topic thep các bước sau :

Step 1. Chạy lệnh :
docker exec -it kafka2 /bin/bash
Step 2.Truy cập vào folder chứa tập lệnh điều khiển của kafka
cd /opt/bitnami/kafka/bin
Step 3.Tạo topic trên 3 node của cụm
./kafka-topics.sh --bootstrap-server localhost:9092 --create --topic worldcapitals --partitions 3 --replication-factor 3
Kiểm tra thông tin topic vừa tạo:
a. ./kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic worldcapitals
Lúc này 3 phân vùng sẽ được tạo ra, mỗi phân vùng sẽ có bản sao ở các phân vùng còn lại