Der Cassandra Effekt oder wie man NoSQL-Datenbanken in Container integriert

Apache Cassandra befindet sich weiterhin unter den Top 10 der NoSQL-Datenbanken und ist sowohl frei als auch kostenpflichtig in der DataStax Distribution erhältlich. Größere Unternehmen wie Netflix und Apple verwenden Cassandra stets für die Organisation von großen Datenmengen, wie z.B. der Empfehlung von weiteren Serien im eigenen Netflix Dashboard.

Solch eine Produktivumgebung aufzubauen, setzt die Grundlagen interner Prozesse voraus und sollte vorab mithilfe eines Testsystems geprüft und untersucht werden.

Somit werden wir in diesem Blogbeitrag eine Apache-Cassandra-Umgebung in Docker bereitstellen. Dies ermöglicht es uns, auf einfachstem Wege ein Cassandra Cluster lokal testen zu können. Hierbei bietet Docker eine moderne Alternative zu dem bereits bekannten Cassandra Cluster Manager (ccm), der mithilfe von Skripten und Bibliotheken ein Apache Cassandra Cluster auf dem localhost erstellen, betreiben und wieder entfernen kann. Die Umgebung, welche wir hier mit Docker aufbauen, basiert auf dem offiziellen Cassandra Image. Demzufolge sind alle Releases von Cassandra als Image erhältlich und somit als Container verfügbar.
Das Konfigurieren und Verwalten von Cassandra wird durch das Mounten von Verzeichnissen (Volumes) ermöglicht. Dies ist eine einfache und schnelle Variante Umgebungskonfigurationen vorzunehmen, ohne das Image neu aufbauen zu müssen.

Was wir benötigen

Für die Umsetzung benötigen wir eine lauffähige Version von Docker [https://docs.docker.com/get-docker/]. Außerdem sollte sichergestellt werden, dass ausreichend RAM zum Betrieb der Umgebung zur Verfügung steht. Empfohlen werden hier mindestens 6GB RAM für das Cassandra Cluster mit insgesamt drei Knoten. Zu guter Letzt brauchen wir ein Cassandra Image. An dieser Stelle ist zu erwähnen, dass Docker auf einer Windowsmaschine installiert und somit auch nur mit dieser Umgebung gearbeitet wurde. Es könnte also zu Abweichungen kommen, sollte das hier beschriebene Beispiel auf einer nicht Windowsmaschine nachgebaut werden. Um das Cassandra Image herunterzuladen, wird die Windows PowerShell als Administrator ausgeführt und in das Verzeichnis navigiert, in dem das Testsystem aufgebaut werden soll.

docker image pull cassandra:3.11.10

Da es nicht möglich ist, Dateien direkt aus einem Docker Image herauszukopieren, erstellen wir einen temporären Container basierend auf dem vorab heruntergeladenen Image. Dieser wird verworfen, sobald alle Konfigurationen kopiert wurden.

docker run --rm –d --name tmp cassandra:3.11.10
docker cp tmp:/etc/cassandra cassandra-3.11.10_base
docker stop tmp

Somit sollten wir die Templates der Konfigurationen lokal in unserem Verzeichnis einsehen können. Diese werden im Laufe des Blogartikels noch benötigt.

Erstellung der Cassandra Services

Für die Erstellung unseres Test-Clusters und der Konfiguration von sowohl Docker als auch cassandra-internen Umgebungsvariablen, wird eine docker-compose.yml-Datei benötigt. Diese erlaubt es uns, mehrere Cassandra-Knoten (Services) zu deklarieren, welche sich anschließend in einem "Docker Netzwerk" (bridge) befinden. Der zu erkennende Vorteil ist, dass sich die Knoten bereits untereinander kennen und somit auch miteinander kommunizieren können.

version: '2.4'
networks:
  cassandra: # docker network indem sich alle Cassandra Knoten befinden werden  
services: 
  knotenA: 
    image: cassandra:3.11.10 # best practice: immer Version angeben
    container_name: knotenA
    hostname: knotenA  
    networks: 
      - cassandra 
    ports: 
      - "9042:9042" # Expose native binary CQL port for your apps 
    volumes: 
      - ./data/knotenA:/var/lib/cassandra # Persistene Daten für KnotenA
      - ./etc/knotenA:/etc/cassandra # Konfigurationsdateien 
    environment: &environment # Umgebungsvariablen werden in "environment" gespeichert    
      CASSANDRA_SEEDS: "knotenA,knotenB" 
      CASSANDRA_CLUSTER_NAME: TestCluster 
      CASSANDRA_DC: TestDatacenter 
      CASSANDRA_RACK: TestRack 
      CASSANDRA_ENDPOINT_SNITCH: GossipingPropertyFileSnitch 
      CASSANDRA_NUM_TOKENS: 128
 

Die vollständige docker-compose-Datei können Sie am Ende des Beitrags als PDF herunterladen und einsehen. Jeder Knoten wird mit zwei gemounteten Verzeichnissen versehen und aufgebaut. Diese beinhalten zum einen die Daten, welche sich im Cluster befinden und zum anderen die Konfigurationsdateien, die je nach Wunsch angepasst werden können.
Wie vorab angekündigt benötigen wir die Templates der Konfigurationsdateien. Die Templates sollen sich schlussendlich in den Verzeichnissen befinden, die wir in der docker-compose als zu mountende Volumes angegeben haben. Dazu müssen die Verzeichnisse manuell angelegt und die Templates hineinkopiert werden:

mkdir –p etc
copy cassandra-3.11.10_base/* etc/knotenA
copy cassandra-3.11.10_base/* etc/knotenB
copy cassandra-3.11.10_base/* etc/knotenC

Anschließend kann das Cluster gestartet und getestet werden. Starten lässt sich das Cluster über die Windows PowerShell wie folgt:

docker-compose up –d

Mit Hilfe des "docker ps"-Kommandos kann sichergestellt werden, dass die definierte Cassandra-Container gestartet sind:

CONTAINER ID   IMAGE              COMMAND                  CREATED          STATUS          PORTS                                                                          NAMES
7fc9213030ee   cassandra:3.11.10   "docker-entrypoint.s…"   29 seconds ago   Up 28 seconds   7000-7001/tcp, 7199/tcp, 9160/tcp, 0.0.0.0:9042->9042/tcp, :::9042->9042/tcp   knotenA
277987e6e6d7   cassandra:3.11.10   "docker-entrypoint.s…"   29 seconds ago   Up 28 seconds   7000-7001/tcp, 7199/tcp, 9160/tcp, 0.0.0.0:9044->9042/tcp, :::9044->9042/tcp   knotenC
5b6513005c8d   cassandra:3.11.10   "docker-entrypoint.s…"   29 seconds ago   Up 28 seconds   7000-7001/tcp, 7199/tcp, 9160/tcp, 0.0.0.0:9043->9042/tcp, :::9043->9042/tcp   knotenB
 

Nun lassen sich noch weitere Tests mit internen Cassandra-Funktionen ausführen:

docker exec knotenA nodetool status # Überwachen des Cassandra Clusters
docker exec –it knotenA cqlsh –e "describe keyspaces" #Überprüfung der Lauffähigkeit von cqlsh

Sollten hierbei keine Fehler aufgetreten sein, so steht das erste eigene Cassandra Cluster vollständig zur Verfügung und kann weiter angepasst werden.

Konfiguration und Starten des Cassandra Clusters

Durch den Ansatz, der von Docker geboten wird, können Konfigurationen, je nach Bedarf, gesetzt und verändert werden. Anschließend kann die cassandra-interne Benutzerauthentifizierung aktiviert werden. Dazu muss unter dem lokalen Verzeichnis ./etc für jeden Knoten die cassandra.yaml-Datei angepasst werden.

./etc/knotenA/cassandra.yaml
./etc/knotenB/cassandra.yaml
./etc/knotenC/cassandra.yaml

Die Benutzerauthentifizierung lässt sich in Cassandra wie folgt konfigurieren:

authenticator: PasswordAuthenticator
authorizer: CassandraAuthorizer

Um die Änderungen wirksam zu machen, muss das Cluster neu gestartet werden. Dies erfolgt in der Windows PowerShell über:

docker-compose restart

Alternativ kann jeder Cassandra-Knoten einzeln neugestartet werden:

docker-compose knotenA restart
docker-compose knotenB restart
docker-compose knotenC restart

Anschließend kann der Versuch gestartet werden, sich erneut mit CQLSH zu verbinden:

Docker exec –it knotenA cqlsh –e "describe keyspaces"

An dieser Stelle sollten Sie eine Fehlermeldung erhalten: "Connection error: ('Unable to connect to any servers', {'127.0.0.1': error(111, "Tried connecting to [('127.0.0.1', 9042)]. Last error: Connection refused")})". Falls keine Fehlermeldung aufgetreten ist, müssen die vorherigen Schritte noch einmal überprüft und durchgeführt werden.
Eine erfolgreiche Verbindung zur CQLSH sieht wie folgt aus:

Docker exec –it knotenA cqlsh –u cassandra –p cassandra –e "describe keyspaces"

Fazit

Durch die Umsetzung eines Apache Cassandra Clusters in Docker haben wir den Vorteil, eine saubere und reproduzierbare Cassandra-Umgebung aufbauen zu können. Aufgrund der Tatsache, dass offizielle Cassandra Images verwendet und zwischen den unterschiedlichen Versionen getauscht werden kann, können erste Schritte in Richtung einer Produktivumgebung vorgenommen und getestet werden (TLS, Replikationsfaktor). Ein weiterer Vorteil ist, dass beim Booten kein Datenverlust entsteht, da alles lokal und nicht etwa im Container selbst abgelegt wird. Der Aufwand, der hier betrieben werden muss, ist im Gegensatz zur Verwendung von virtuellen Maschinen sehr gering und aufgrund der doch recht überschaubaren Komplexität sehr empfehlenswert.

Sollten Sie Fragen rund um das Thema Docker oder Apache Cassandra haben, wenden Sie sich gerne an uns oder schauen Sie auf unser Kursangebot (Einführung in Docker – Webinar, Cassandra Quickstart – Webinar, Apache Cassandra Administration).