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.

Tuesday, April 30, 11:00 ‚Äď 11:45 a.m. CEST
Webinar: Driving Efficiency with Event-Driven Ansible: An Introduction

Unravel the theoretical foundations of Event-Driven Ansible alongside a practical demonstration.
Presented by our blog author Dr. Ottavia Balducci.

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 }}"

ansible

Ansible-Schulung

ATIX bietet Ansible-Schulungen f√ľr Anf√§nger und Fortgeschrittene an, in denen Teilnehmer:innen lernen, wie man Ansible als Konfigurationsmanagement-Tool nutzt. So k√∂nnen sie ihre Infrastruktur mit Ansible-Rollen effizienter verwalten und finden heraus, wie sie Ansible-Rollen, Inventories und Playbooks bestm√∂glich erstellen, nutzen und pflegen.

The following two tabs change content below.

ATIX-Crew

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