Kafka and Ansible

Kafka mit Ansible automatisieren

In allen Bereichen des Lebens gibt es viele Probleme, die uns nicht bewusst sind. Um diese Probleme zu messen, verwenden wir die sogenannte Erfüllungsrate (Fulfillment Rate). Beispiele: Bei einer Erfüllungsrate von 90% würde ein Herzschlag alle 85 Sekunden aussetzen und auf einer durchschnittlichen A4-Seite Text wären 30 Tippfehler. Eine Erfüllungsrate von 99,9% (was sehr viel erscheint) bedeutet immer noch 22.000 falsche Bankbuchungen pro Stunde und insgesamt 32.000 verpasste Herzschläge pro Jahr. Die Antwort auf diese Problematik lautet: Automatisierung und Standardisierung! Diese Ansätze helfen, Probleme zu lösen, von denen wir oft gar nichts wissen.

ebook Infrastucture Automation

Kostenloses E-Book

Infrastructure Automation mit Linux und Open Source Tools

Das kostenlose E-Book zeigt praxisnah, wie Sie mit Linux und Open-Source-Tools wiederkehrende Aufgaben vereinfachen, Fehler reduzieren und skalierbare IT-Prozesse aufbauen.
Jetzt entdecken.

Jetzt kostenlos herunterladen

Mit Automatisierung und Standardisierung können wir die Innovationslücke schließen, d. h. die Diskrepanz zwischen dem Innovationsbedarf der Unternehmen und der Innovationsfähigkeit, die die traditionelle IT bieten kann. Standardisierung bedeutet eine gemeinsame IT-Sprache, von der Entwicklung bis zur Produktion. Um dies zu erreichen, ist Ansible das beste Werkzeug. Es ist „radikal einfach“, hat niedrige Anforderungen, benötigt keinen Agenten und ist visuell lesbar.

Ansible

Ansible besteht aus einem Kontrollknoten, einem Playbook und einem Inventory mit Servern. Das Inventory verwendet eine ini- oder YAML-Syntax, um die Infrastruktur zu definieren, Server in Gruppen zusammenzufassen und bestimmte Variablen festzulegen.

[kafkaserver]
web1.server.com ansible_host=13.12.2.1
web2.server.com ansible_host=13.12.2.2
web3.server.com ansible_host=13.12.2.3
[appserver]
app1.server.com ansible_host=10.10.12.1

Das Playbook ist in (visuell lesbarem) YAML geschrieben und bildet Rollen auf Systemen ab. Es wird zur Standardisierung verwendet und idealerweise mit VCS kombiniert.

---
- hosts: kafkaserver # mapping role to host
  become: true # run as root
  roles:
   - preflight # role1
   - zookeeper # role2
   - kafkabroker # role3

Ein Rolle ist eine Kombination von Tasks. Sie ist idempotent und sollte idealerweise mit VCS kombiniert werden.

---
#preflight confluent role
- name: Add open JDK repo
  apt_repository:
    repo: ppa:openjdk-r/ppa


- name: Install Java
  apt:
    name: "openjdk-8-jdk"
    update_cache: yes
...

Kafka

Mit Ansible ist es möglich, eine Kafka-Bereitstellung zu verwalten. Man kann verschiedene Kafka-bezogene Aufgaben automatisieren, einheitliche Konfigurationen in einem Cluster sicherstellen und die Kafka-Infrastruktur einfach skalieren und steuern. Zur gleichen Zeit, als Ansible ins Leben gerufen wurde, entstand 2012 Confluent Kafka. Kafka Playbooks sind eine Reihe von Ansible Playbooks und -Rollen, die bei der Bereitstellung und Verwaltung von Kafka Clusters mit Ansible helfen. Diese Playbooks sollen den Prozess der Einrichtung und Konfiguration eines Kafka Cluster vereinfachen, einschließlich der Installation von Kafka, ZooKeeper und anderen zugehörigen Komponenten.

Das folgende Inventory könnte für das Bereitstellen von einem Kafka Cluster verwendet werden:

---
#inventory.yaml
  zookeeper:
   hosts:
    host1:
     ansible_host: 13.12.2.1
    host2:
     ansible_host: 13.12.2.2
    host3:
     ansible_host: 13.12.2.3
  broker:
   hosts:
    host1:
     ansible_host: 13.12.2.1
    host2:
     ansible_host: 13.12.2.2
    host3:
     ansible_host: 13.12.2.3

Die Confluent Kafka Playbooks bieten eine hochgradige Abstraktion für die Verwaltung der Kafka-Infrastruktur. Sie kapseln die von Confluent bereitgestellten Best Practices und Konfigurationsempfehlungen und können an spezifische Bereitstellungsanforderungen angepasst werden. Sie können die Playbooks verwenden, um Rollen Servern zuzuordnen:


- hosts: preflight
  tasks:
  - import_role:
      name: confluent.preflight

- hosts: ssl_CA
  tasks:
  - import_role:
      name: confluent.ssl_CA

- hosts: zookeeper
  tasks:
  - import_role:
      name: confluent.zookeeper

- hosts: broker
  tasks:
  - import_role:
      name: confluent.kafka-broker

- hosts: schema-registry
  tasks:
  - import_role:
      name: confluent.schema-registry

Innerhalb einer Rolle können Variablen …


---
#defaults/main.yml
kafka:
  broker:
    user: "cp-kafka"
    group: "confluent"
    config_file: "/etc/kafka/server.properties"
    systemd_file: |
     "/usr/lib/systemd/system/kafka.service"
    service_name: "kafka"
    datadir:
      - "/var/lib/kafka/data"
    systemd:
      enabled: yes
      state: "started"
    environment:
      KAFKA_HEAP_OPTS: "-Xmx1g"
    config:
      group.initial.rebalance.delay.ms: 0
      log.retention.check.interval.ms: 300000
      num.partitions: 1
      num.recovery.threads.per.data.dir: 2
      offsets.topic.replication.factor: 3
      transaction.state.log.min.isr: 2
      zookeeper.connection.timeout.ms: 6000
      # [...] many more

… und Code getrennt werden:

---
# [...] tasks to create user,group and dirs
# tasks/main.yml
- name: broker ssl config
  template:
    src: server_ssl.properties.j2
    dest: "{{kafka.broker.config_file}}"
    mode: 0640
    owner: "{{kafka.broker.user}}"
    group: "{{kafka.broker.group}}"
  when: security_mode == "ssl"
  notify:
    - restart kafka


- name: create systemd override file
  file:
    path: "{{kafka.broker.systemd_override}}"
    owner: "{{kafka.broker.user}}"
    group: "{{kafka.broker.group}}"
    state: directory
    mode: 0640


- name: broker configure service
  systemd:
    name: "{{kafka.broker.service_name}}"
    enabled: "{{kafka.broker.systemd.enabled}}"
    state: "{{kafka.broker.systemd.state}}"

Docker

Im Jahr 2013 kam Docker auf den Markt. Docker bietet eine Menge Vorteile, wie Portabilität, Skalierbarkeit, Sicherheit, Effizienz und Reproduzierbarkeit. Es gibt ein Ansible-Modul für die Verwaltung von Docker-Containern. Dies ermöglicht es, eine generische Rolle mehrmals mit immer verschiedenen Variablen zu nutzen.

- hosts: zookeeper
  tasks:
    - name: Deploy Zookeeper
    include_role:
      name: confluent_component
      vars_from: zookeeper

- hosts: kafka
    - name: Deploy Kafka
    include_role:
      name: confluent_component
      vars_from: kafka

- hosts: control-center
    - name: Deploy Control-Center
    include_role:
      name: confluent_component
      vars_from: control-center

Generische Docker-Rolle, Daten und Code getrennt:

---
- name: "Start Docker-Container"
  docker_container:
    name: "{{ kafka_component_name }}"
    image: "{{ kafka_component_container_image }}"
    state: "{{ kafka_component_container_state }}"
    restart: "{{ config_changed.changed }}"
    published_ports: "{{ published_ports }}"
    restart_policy: "{{ container_restart_policy }}"
    env_file: "{{ kafka_component_env_file }}"
    volumes: "{{ kafka_component_volumes }}"


---
kafka_component_name: "zookeeper"
image: "confluentinc/cp-kafka"
published_ports:
  - 12888:2888
  - 13888:3888

Ein Jahr später folgte Docker Compose, das die Bereitstellung von mehreren Containern ermöglicht. Dies erfolgt über eine Compose-Datei:

---
version: '2'
services:
  zookeeper:
    image: "confluentinc/cp-zookeeper:latest"
    environment:
      ZOOKEEPER_CLIENT_PORT: 2181
      ZOOKEEPER_TICK_TIME: 2000
  kafka:
    image: "confluentinc/cp-kafka:latest"
    depends_on:
      - "zookeeper"
    ports:
      - 9092:9092
    environment:
      KAFKA_BROKER_ID: 1
      KAFKA_ZOOKEEPER_CONNECT: "zookeeper:2181"
    # [...] more kafka broker settings 

So kann man dann Docker Compose in einem Ansible-Playbook nutzen:


- hosts: kafka-server
  tasks:
    - name: "Spin up Kakfa-Cluster"
      docker_compose:
        project_src: "cp_kafka"
        state: absent
      register: output


- name: "Ensure Stack is running"
  assert:
    that:
      - kafka.cp_kafka_kafka_1.state.running
      - zookeeper.cp_kafka_zookeeper_1.state.running

In den folgenden Jahren kamen viele andere Anbieter hinzu, wie Kubernetes, Red Hat OpenShift, Rancher …

Kafka und Ansible

Man kann Kafka nicht nur mit Ansible bereitstellen, sondern auch verwalten. Es gibt ein Ansible-Modul für Topics und ACIs, und es ist keine SSH-Verbindung zu einem Remote Broker nötig.

---
- name: "create topic"
  kafka_lib:
    resource: 'topic'
    name: 'test'
    partitions: 2
    replica_factor: 1
    options:
      retention.ms: 574930
      flush.ms: 12345
    state: 'present'
    zookeeper: >
      "{{ zookeeper_ip }}:2181"
    bootstrap_servers: >
      "{{ kafka_ip_1 }}:9092, {{ kafka_ip2 }}:9092"
    security_protocol: 'SASL_SSL'
    sasl_plain_username: 'username'
    sasl_plain_password: 'password'
    ssl_cafile: '{{ content_of_ca_cert_file_or_path_to_ca_cert_file }}

Kafka Topics verwalten:

Der Rest Proxy kann keine Topics erstellen, manuelle Idempotenz ist erforderlich und der Zugriff ist auf einen Kafka-Broker beschränkt.


# Definition of topic
  topic:
   name: "test"
   partitions: 2
   replica_factor: 1
   configuration:
    retention.ms: 574930
    flush.ms: 12345


---
- name: "Get topic information"
  uri:
   url: "{{ 'kafka_rest_proxy_url' + ':8082/topics/' + topic.name }}"
  register: result


- name: "Create new topic"
  command: "{{ 'kafka-topics --zookeeper ' + zookeeper +
                   ' --create' +
                   ' --topic ' + topic.name +
                   ' --partitions ' + topic.partitions +
                   ' --replication-factor ' + topic.replica_factor +
                   topic.configuration }}"

Das könnte Sie auch interessieren:
Saltstack LogoSaltStack: Salzige Alternative zum Puppetspieler
ansibleAnsible Best Practices
Erstellung von Foreman-RPM-Paketen mit Docker-ContainerErstellung von Foreman-RPM-Paketen mit Docker-Container
awx ansible github webhooks blogAWX und GitLab Webhooks
GitHub-Elemente und Module fließen via Pfeil in Ansible-Container, verdeutlichen strukturierte Collections und Community-IntegrationAnsible Collections – Mehr Übersichtlichkeit und einfachere Teilhabe bei Ansible
Ansible-Werkzeugkasten mit Roles, Modules und Docs, symbolisiert die modulare Struktur von Collections.Die Zukunft von Ansible
+ posts

Der ATIX-Crew besteht aus Leuten, die in unterschiedlichen Bereichen tätig sind: Consulting, Development/Engineering, Support, Vertrieb und Marketing.