//

Aufbau eines Mesosphere DC/OS-Clusters mit Terraform

24.4.2016 | 5 Minuten Lesezeit

Der Ein oder Andere kennt höchstwahrscheinlich die Herausforderung, ein verteiltes System zu betreiben. Selbst der Betrieb von einem einfachen Online-Shop kann eine nicht triviale Aufgabe sein, wenn der Shop in einer Microservice-Architektur über mehrere Rechner hinweg betrieben wird – vor allem wenn es zudem wichtig ist, dass die vorhandenen Ressourcen bestmöglich ausgenutzt werden und unterschiedliche Software-Versionen für A/B Tests ausgeliefert werden müssen. In diesem Artikel möchte ich DC/OS (Data Center Operation System) vorstellen, welches das Betreiben von verteilten Web- und Big-Data-Anwendungen vereinfacht. Außerdem möchte ich zeigen, wie ein DC/OS Cluster in Amazon Webservices (AWS) mithilfe von Terraform aufgebaut werden kann.

Data Center Operation System

DC/OS wird von Mesosphere entwickelt und möchte ein Betriebssystem sein, das den Betrieb eines Rechenzentrums vereinfacht. DC/OS verfolgt das Ziel, dass die Benutzer die unterschiedlichen Server des Rechenzentrums wie ein einzelnes Gerät steuern können. Dazu stellt DC/OS eine Web-Oberfläche und ein Konsolen-Programm bereit.

DC/OS Architektur

DC/OS besteht aus unterschiedlichen Knotentypen. Es existieren Master- und Agenten-Knoten. Auf den Master-Knoten sind die folgenden Komponenten installiert:

Auf den Agenten-Knoten ist der Mesos-Agent-Prozess installiert, der für das Ausführen von Programmen verwendet wird. Ein Mesos-Agent verwendet entweder cgroups oder Docker als Laufzeitumgebung für Programme, um eine Trennung der Prozesse zu erreichen.

DC/OS Zonenkonzept

Die Standard-Installation von DC/OS erstellt eine Netzwerktopologie, die aus drei Zonen besteht. Es gibt eine Admin-, eine private und eine öffentliche Zone. Die Admin-Zone ist vom Internet über HTTP/HTTPS und SSH-Verbindungen erreichbar und stellt den Zugriff auf die Master-Knoten sicher. Außerdem kann man von dieser Zone aus auf die anderen Knoten zugreifen.

Die meisten Agenten-Knoten befinden sich in der privaten Zone. Die private Zone liegt in einem nicht öffentlich erreichbaren Subnetz. Diese Zone ist nur von der Admin-Zone oder einem Router in der öffentlichen Zone erreichbar. In der privaten Zone werden normalerweise alle Applikationen und Dienste im Cluster gestartet.

Die öffentliche Zone ist optional. Sie kann benutzt werden um Applikationen zu betreiben, die öffentlich zugänglich sein sollen, wie z.B. eine Web-Anwendung. In dieser Zone existieren in der Regel nur wenige Knoten. Die Knoten sind mit einem speziellen Label versehen, das von Marathon dazu benutzt wird, die Applikation auf den öffentlichen Knoten zu starten.

DC/OS Installation

Um ein DC/OS-Cluster in AWS zu erstellen, stellt Mesosphere ein CloudFormation-Template bereit. CloudFormation bietet Entwicklern die Möglichkeit, ohne viel Aufwand eine Sammlung von AWS-Ressourcen zu erstellen, zu verwalten, in geordneter Form bereitzustellen und aktualisieren zu können.

Im Mesosphere CloudFormation-Template sind alle Master-Knoten öffentlich ohne Verschlüsselung erreichbar. Dies kann ein Hindernis darstellen, wenn man einem POC mit DC/OS starten und mit eigenen Daten arbeiten möchte, die ggf. sensible Informationen enthalten. Deshalb habe ich ein eigenes Terraform-Template geschrieben, um ein DC/OS-Cluster zu erstellen, das zumindest über eine Basis-Absicherung durch einen VPN-Tunnel verfügt und die neueste DC/OS Version 1.7 enthält.

Terraform ist ein Tool zum Aufbauen von Cloud-Umgebungen, das von HashiCorp , dem Unternehmen hinter Vagrant , entwickelt wird. Ich verwende es vor allem, da ich das CloudFormation-Template für unwartbar halte, aber das ist meine persönliche Meinung. Funktional gesehen sind Terraform und CloudFormation ähnlich gut.

Der Standard DC/OS-Installation habe ich eine weitere Master-Zone hinzugefügt, die nicht vom Internet aus erreichbar ist und in der sich nun die Master-Knoten befinden. Außerdem ist jeder Benutzer gezwungen, sich über einen VPN-Server im Netzwerk anzumelden, um Zugriff auf die Master-Knoten zu erhalten.

Um mit dem Template eine DC/OS-Umgebung einzurichten, muss zunächst Terraform installiert werden. Eine Anleitung dafür befindet sich im Artikel “Install Terraform”. Als nächstes muss man das Template aus Github auschecken und in das Verzeichnis wechseln, in dem sich das Terraform-Code befindet:

1bz@cc ~ $ git clone https://github.com/zutherb/terraform-dcos
2bz@cc ~ $ cd terraform-dcos
3

Nachdem das Template ausgecheckt worden ist, muss die Datei terraform.tfvars erstellt und mit den Amazon-Zugangsdaten, der zu verwendenden Region, SSH-Keys und den Standard-Benutzer für OpenVPN konfiguriert werden. Im Beispiel befindet sich im folgenden Listing:

1bz@cc ~ $ vi terraform.tfvars
2aws_access_key="*****"
3aws_secret_key="*****"
4aws_region="eu-west-1"
5ssh_public_key="ssh-rsa ***** bernd.zuther@codecentric.de"
6 
7openvpn_admin_user="openvpn"
8openvpn_admin_pw="******"
9

Nun kann man das Cluster mit dem Befehl “terraform apply” erstellen.

1bz@cc ~ $ terraform apply
23aws_security_group_rule.public_slave_egress_all: Creation complete
4aws_security_group_rule.slave_ingress_slave: Creation complete
5aws_security_group_rule.master_egress_all: Creation complete
6aws_security_group_rule.public_slave_ingress_public_slave: Creation complete
7aws_security_group_rule.slave_ingress_public_slave: Creation complete
8aws_security_group_rule.master_ingress_public_slave: Creation complete
9aws_security_group_rule.public_slave_ingress_master: Creation complete
10aws_security_group_rule.slave_egress_all: Creation complete
11aws_security_group_rule.master_ingress_master: Creation complete
12aws_security_group_rule.public_slave_ingress_slave: Creation complete
13 
14Apply complete! Resources: 16 added, 0 changed, 16 destroyed.
15 
16The state of your infrastructure has been saved to the path
17below. This state is required to modify and destroy your
18infrastructure, so keep it safe. To inspect the complete state
19use the `terraform show` command.
20 
21State path: terraform.tfstate
22 
23Outputs:
24 
25  dcos_cli        = ssh ubuntu@10.0.5.227
26  internal_master = http://internal-master-load-balancer-1234567890.eu-central-1.elb.amazonaws.com
27  public_slave    = public-slave-load-balancer-1234567890.eu-central-1.elb.amazonaws.com
28  vpn             = https://vpn-load-balancer-1234567890.eu-central-1.elb.amazonaws.com
29

Dieser Vorgang dauert ungefähr 15 Minuten. In der Standard-Konfiguration wird eine Umgebung mit einen Master, fünf privaten und einem Public-Slave erstellt. Außerdem gibt es eine Instanz, die als VPN-Gateway dient und eine Instanz, auf der das DC/OS-Kommando-Zeilen-Programm installiert wird und als Terminal zum Administrieren des Clusters benutzt werden kann.

Wie man sieht ist es ziemlich einfach, ein DC/OS Cluster zu erstellen. Das folgende Video zeigt, wie man sich mit OpenVPN im Cluster anmelden kann. Um richtig mit dem Cluster arbeiten zu können, ist das Setzen eines Master-Knotens im OpenVPN als DNS-Server unumgänglich, sonst kann man nicht über den DNS-Namen http://leader.mesos auf das DC/OS-Dashboard zugreifen. Das folgendende Video zeigt, wie man den DNS-Server konfiguriert, sich im Cluster anmeldet und auf das DC/OS-Dashboard zugreift:

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren

Video laden

YouTube immer entsperren

DC/OS Deinstallation

Das Cluster kann mit dem Befehl “terraform destroy” ganz einfach wieder gelöscht werden.

1bz@cc ~ $ vi terraform.tfvars
2bz@cc ~ $ terraform destroy
3aws_subnet.public: Destruction complete
4aws_security_group.admin: Destruction complete
5aws_security_group.master: Destruction complete
6aws_security_group.master_lb: Destruction complete
7aws_security_group.slave: Destruction complete
8aws_security_group.public_slave: Destruction complete
9aws_subnet.master: Destruction complete
10aws_vpc.dcos: Destroying...
11aws_vpc.dcos: Destruction complete
12 
13Apply complete! Resources: 0 added, 0 changed, 76 destroyed.
14

Fazit

Wie man sieht ist das Einrichten eines DC/OS-Cluster sehr einfach und geht sehr schnell. DC/OS bietet eine perfekte Grundlage, um die SMACK-Plattform bestehend aus Spark, Mesos, Akka, Cassandra und Kafka aufzubauen. Dies beschreibt mein Kollege Florian Troßbach in seinen Artikel „The SMACK stack – hands on!“ . Es kann aber auch einfach nur benutzt werden, um verteilte Anwendungen auszuliefern. Dem Anspruch, das die Benutzer die unterschiedlichen Server des Rechenzentrums wie ein einzelnes Gerät steuern können, wird es auf jedenfall gerecht.

Beitrag teilen

Gefällt mir

0

//

Weitere Artikel in diesem Themenbereich

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

//

Gemeinsam bessere Projekte umsetzen

Wir helfen Deinem Unternehmen

Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.

Hilf uns, noch besser zu werden.

Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.