Aufbau eines Mesosphere DC/OS-Clusters mit Terraform

2 Kommentare

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.

DCOS

DC/OS Architektur

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

  • der Mesos-Master-Prozess für die Ressourcenverwaltung auf den unterschiedlichen Rechner,
  • eine Marathon-Instanz, die als Init-System (ähnlich Systemd) für Services verwendet wird,
  • ein Mesos-DNS für die Service Discovery und
  • Zookeeper für die Koordination und das Verwalten der installierten DC/OS Services.

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.

Enterprise Architecture

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.

security-zones-ce

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:

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

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:

bz@cc ~ $ vi terraform.tfvars
aws_access_key="*****"
aws_secret_key="*****"
aws_region="eu-west-1"
ssh_public_key="ssh-rsa ***** bernd.zuther@codecentric.de"
 
openvpn_admin_user="openvpn"
openvpn_admin_pw="******"

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

bz@cc ~ $ terraform apply
…
aws_security_group_rule.public_slave_egress_all: Creation complete
aws_security_group_rule.slave_ingress_slave: Creation complete
aws_security_group_rule.master_egress_all: Creation complete
aws_security_group_rule.public_slave_ingress_public_slave: Creation complete
aws_security_group_rule.slave_ingress_public_slave: Creation complete
aws_security_group_rule.master_ingress_public_slave: Creation complete
aws_security_group_rule.public_slave_ingress_master: Creation complete
aws_security_group_rule.slave_egress_all: Creation complete
aws_security_group_rule.master_ingress_master: Creation complete
aws_security_group_rule.public_slave_ingress_slave: Creation complete
 
Apply complete! Resources: 16 added, 0 changed, 16 destroyed.
 
The state of your infrastructure has been saved to the path
below. This state is required to modify and destroy your
infrastructure, so keep it safe. To inspect the complete state
use the `terraform show` command.
 
State path: terraform.tfstate
 
Outputs:
 
  dcos_cli        = ssh ubuntu@10.0.5.227
  internal_master = http://internal-master-load-balancer-1234567890.eu-central-1.elb.amazonaws.com
  public_slave    = public-slave-load-balancer-1234567890.eu-central-1.elb.amazonaws.com
  vpn             = https://vpn-load-balancer-1234567890.eu-central-1.elb.amazonaws.com

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:

DC/OS Deinstallation

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

bz@cc ~ $ vi terraform.tfvars
bz@cc ~ $ terraform destroy
aws_subnet.public: Destruction complete
aws_security_group.admin: Destruction complete
aws_security_group.master: Destruction complete
aws_security_group.master_lb: Destruction complete
aws_security_group.slave: Destruction complete
aws_security_group.public_slave: Destruction complete
aws_subnet.master: Destruction complete
aws_vpc.dcos: Destroying...
aws_vpc.dcos: Destruction complete
 
Apply complete! Resources: 0 added, 0 changed, 76 destroyed.

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.

Bernd Zuther

Kampferprobter Projektveteran, der immer fokussiert auf die Lieferung von funktionierender Software in der vorgegebenen Zeit ist. Zu seinen stärksten Waffen gehören ein sicherer Umgang mit agilen Methoden wie Scrum und sein breit gestreutes IT-Wissen, das er gezielt dazu einsetzt, auch die schwierigsten Problemstellungen pragmatisch und einfach zu lösen.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentare

  • Juni 20, 2016 von Shashi

    Hi ,

    i was able to successfully launch the cluster but somehow how my open vpn instance and master instances are not registering with their respective load balancers . I would really appreciate if you could point me in the right direction .

    i cannot get the to open VPN page nor the admin page for dc/os form my browser because the elb don’t have the instances registered (health check fails )

    • Bernd Zuther

      Hi Shashi,

      you have to login to the openvpn instance and accept the terms of condition with the new release of openvpn.


      ssh openvpnas@ -i path/to/key

      after you have followed the instructions the loadbalancer comes up.

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *