Einheit 1.2: Terraform-Anbieter und Kernmuster

Einführung

In Einheit 1.1 haben Sie einen Server auf drei Arten bereitgestellt: Roh-API mit curl, die Python-SDK und ionosctl. Alle drei sind imperativ. Sie geben einen POST aus, pollen /requests/{id}/status, bis DONE, und geben dann den nächsten Aufruf aus. Das funktioniert, aber es gibt Ihnen keine reproduzierbare, versionierte Beschreibung Ihrer Infrastruktur. Für TaskBoard, das Task-Management-API und die Frontend, die Sie im Laufe dieses Kurses erstellen, benötigen Sie eine Infrastruktur, die in Git lebt, wie Code überprüft wird und sauber abgebaut wird, damit Testumgebungen Sie nie stillschweigend in Rechnung stellen.

Diese Einheit bringt Sie zur deklarativen Bereitstellung mit dem IONOS-Terraform-Anbieter. Sie werden die HCL schreiben, die TaskBoards Basis-Virtuelles Rechenzentrum erstellt, beobachten, was Terraform unter der Haube mit dem asynchronen IONOS-API macht, den Zustand remote in Object Storage speichern und das Muster der ephemeren Umgebung übernehmen, das die Kosten unter Kontrolle hält. Das asynchrone Polling, das Sie manuell in 1.1 gehandhabt haben, ist jetzt die Aufgabe des Anbieters.

1. Anbieter-Einrichtung und Authentifizierung

Der IONOS-Anbieter für Terraform interagiert mit IONOS Cloud-Rechenressourcen, Speicher und Netzwerkressourcen. Er unterstützt derzeit die neuesten V5- und V6-API-Angebote und wird im Terraform-Registrierungssystem unter ionos-cloud/ionoscloud veröffentlicht. Bevor etwas funktioniert, müssen Sie ein IONOS-Konto haben, dessen Anmeldedaten gegen die Cloud-API authentifiziert werden, genau wie in Einheit 1.1.

1.1 Deklaration und Fixierung des Anbieters

Fixieren Sie immer die Anbieter-Version. Der required_providers-Block von Terraform sperrt Sie auf eine bekannte gute Version, sodass ein terraform init im nächsten Monat keine Änderung in Ihre Pipeline zieht.

# versions.tf
terraform {
  required_version = ">= 1.5.0"

  required_providers {
    ionoscloud = {
      source  = "ionos-cloud/ionoscloud"
      version = "~> 6.4"
    }
  }
}

Das ~> 6.4-Constraint ermöglicht Patch- und Minor-Updates innerhalb der 6.x-Linie, blockiert jedoch einen Sprung auf 7.0. Führen Sie terraform init aus, um den festgelegten Anbieter in .terraform/ herunterzuladen. Committen Sie die generierte .terraform.lock.hcl-Datei, damit jeder Teammitglied und jeder CI-Runner den identischen Anbieterbuild auflöst.

1.2 Authentifizierung: Umgebungsvariable vs Anbieterblock

Das sauberste Muster ist die Authentifizierung mit dem Bearer-Token von Token Manager (in Einheit 1.1 behandelt) über die IONOS_TOKEN-Umgebungsvariable. Dann berührt nichts Geheimes Ihre HCL oder Ihre Git-Verlaufsdaten.

export IONOS_TOKEN="eyJ0eXAiOiJKV1QiLCJraWQiO..."
terraform plan

Mit der festgelegten Variable kann der Provider-Block leer sein:

# provider.tf
provider "ionoscloud" {}

Sie können auch Anmeldeinformationen explizit im Provider-Block übergeben, was nützlich ist, wenn eine einzelne Konfiguration Ressourcen über mehr als ein Konto hinweg verwaltet. Benutzername und Passwort (Basic-Auth) werden als Alternative zum Token unterstützt.

provider "ionoscloud" {
  token = var.ionos_token   # never hardcode; pass via TF_VAR_ionos_token
}

Bevorziehen Sie die IONOS_TOKEN-Umgebungsvariable gegenüber einem Token, das in einer .tfvars-Datei committet wurde. Wenn Sie unbedingt eine Variable verwenden müssen, markieren Sie sie als sensitive = true und übergeben Sie sie durch TF_VAR_ionos_token in Ihrer Shell oder dem CI-Geheimnis-Speicher.

2. Kernressourcen: Erstellung eines virtuellen Rechenzentrums

Eine TaskBoard-Basisumgebung benötigt ein virtuelles Rechenzentrum, ein LAN, einen Server, ein Boot-Volume und eine NIC, die den Server mit dem LAN verbindet. Jede IONOS-Terraform-Ressource wird mit ionoscloud_ vorangestellt, was sie eindeutig macht, wenn eine Konfiguration Anbieter mischt.

2.1 Rechenzentrum, LAN, Server, Volume, NIC

Die Ressourcennamen unten (ionoscloud_datacenter, ionoscloud_lan, ionoscloud_server, ionoscloud_nic) und ihre Attributschemata folgen der IONOS-Terraform-Anbieterdokumentation. Der Ortswert und die Bildauswahl basieren auf den Datenquellensektionen dieser Einheit.

# main.tf
resource "ionoscloud_datacenter" "taskboard" {
  name        = "taskboard-base"
  location    = "de/fra"
  description = "TaskBoard base VDC, managed by Terraform"
}

resource "ionoscloud_lan" "app" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  name          = "taskboard-app-lan"
  public        = true
}

resource "ionoscloud_server" "api" {
  name              = "taskboard-api"
  datacenter_id     = ionoscloud_datacenter.taskboard.id
  cores             = 2
  ram               = 4096
  cpu_family        = "INTEL_SKYLAKE"
  availability_zone = "AUTO"

  volume {
    name           = "taskboard-api-boot"
    size           = 20
    disk_type      = "SSD"
    image_name     = data.ionoscloud_image.ubuntu.id
    image_password = var.server_password
  }

  nic {
    lan  = ionoscloud_lan.app.id
    dhcp = true
  }
}

Beachten Sie, dass die inline volume und nic Blöcke es Ihnen ermöglichen, die Boot-Disk und Netzwerk-Anbindung als Teil des Servers auszudrücken. Für eine Daten Volume, die Sie nach dem Booten anhängen, oder um den Lebenszyklus einer Disk unabhängig zu verwalten, deklarieren Sie stattdessen einen eigenständigen ionoscloud_volume.

2.2 Eigenständige Volume und NIC

resource "ionoscloud_volume" "data" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  server_id     = ionoscloud_server.api.id
  name          = "taskboard-data"
  size          = 50
  disk_type     = "SSD"
  licence_type  = "OTHER"
}

resource "ionoscloud_nic" "extra" {
  datacenter_id = ionoscloud_datacenter.taskboard.id
  server_id     = ionoscloud_server.api.id
  lan           = ionoscloud_lan.app.id
  dhcp          = true
}

Die Referenzen wie ionoscloud_datacenter.taskboard.id und ionoscloud_server.api.id sind es, die Terraform seine Reihenfolge geben. Da die Volume's server_id von der Server-Ressource liest, weiß Terraform, dass der Server zuerst existieren muss. Sie schreiben nie explizite "warte auf das Rechenzentrum"-Logik. Dieser Abhängigkeitsgraph ist der ganze Zweck des Umstiegs von den imperativen Skripten aus Einheit 1.1.

3. Der Plan/Ausführen/Zerstören-Lebenszyklus

Die drei Befehle, die Sie ständig ausführen, sind terraform plan, terraform apply und terraform destroy. Das Verständnis dessen, was jeder gegen den asynchronen IONOS API ausführt, spart Stunden der Verwirrung.

3.1 Was Passiert Unter Der Haube

terraform plan liest Ihre HCL, liest den aktuellen Zustand, fragt den IONOS API nach dem Live-Zustand jedes gemanagten Ressourcens und gibt die Differenz aus. Es ändert nichts. terraform apply führt diese Differenz aus, indem es die gleichen POST-, PUT- und DELETE-Aufrufe wie von Hand in 1.1 ausführt.

Hier ist der wichtige Punkt: IONOS API-Operationen sind asynchron. Ein POST gibt eine Anforderungs-ID zurück und die Ressource ist noch nicht bereit. In Einheit 1.1 haben Sie /requests/{id}/status abgefragt, bis DONE vor dem nächsten Aufruf. Der IONOS Terraform-Anbieter führt diese Abfrage intern für jede Ressource durch. Wenn apply eine Ressource als noch erstellend zeigt, wartet es genau auf diesen Anforderungsstatus, bevor es zu den abhängigen Ressourcen übergeht.

terraform plan -out=taskboard.tfplan
terraform apply taskboard.tfplan

Das Erfassen des Plans in einer Datei mit -out und das Anwenden dieser exakten Datei garantiert, dass apply genau das ausführt, was Sie überprüft haben, mit keiner Abweichung zwischen Plan und Ausführung. Dies ist das sichere Muster für CI/CD.

3.2 Zerstören und Gezielte Operationen

# Preview what will be torn down
terraform plan -destroy

# Tear it all down
terraform destroy

# Operate on a single resource (use sparingly)
terraform apply -target=ionoscloud_server.api

terraform destroy geht den Abhängigkeitsgraphen in umgekehrter Reihenfolge durch: NICs und Volumes vor dem Server, der Server vor dem LAN, das LAN vor dem Rechenzentrum. Diese umgekehrte Reihenfolge ist der Grund, warum Sie den Terraform den vollen Stapel verwalten lassen sollten, anstatt Ressourcen manuell im DCD zu löschen, was den Terraform-Zustand aus der Synchronisation mit der Realität bringen kann.

4. Remote-Zustand auf Object Storage

Standardmäßig schreibt Terraform den Zustand in eine lokale terraform.tfstate-Datei. Das funktioniert nicht für ein Team oder eine Pipeline. Der Zustand muss an einem gemeinsam genutzten Ort gespeichert werden, und IONOS Cloud Object Storage ist mit S3 kompatibel, so dass es als Terraform-Backend dient.

4.1 Konfiguration des S3-Backends

IONOS Object Storage authentifiziert sich mit einem Zugriffsschlüssel und einem Geheimschlüssel, nicht mit Bearer-Tokens. Diese sind die gleichen S3-Anmeldedaten, die Sie im Object Storage-Schlüsselmanagement generieren. Object Storage ist in mehreren Regionen verfügbar, jede mit ihrem eigenen Endpunkt, einschließlich Frankfurt (de) bei s3.eu-central-1.ionoscloud.com, Berlin (eu-central-2) bei s3.eu-central-2.ionoscloud.com und Logroño (eu-south-2) bei s3.eu-south-2.ionoscloud.com.

# backend.tf
terraform {
  backend "s3" {
    bucket   = "taskboard-tfstate"
    key      = "base/terraform.tfstate"
    region   = "eu-central-1"
    endpoints = {
      s3 = "https://s3.eu-central-1.ionoscloud.com"
    }
    skip_credentials_validation = true
    skip_region_validation      = true
    skip_requesting_account_id  = true
    skip_s3_checksum            = true
  }
}

Die skip_*-Flags sind erforderlich, da es sich um einen externen (nicht-AWS) S3-Anbieter handelt. Ohne diese Flags versucht der Backend-Server, auf AWS-spezifische Endpunkte wie den Security Token Service zuzugreifen, und schlägt fehl. Übergeben Sie die Anmeldedaten über die Standard-S3-Umgebungsvariablen, damit sie niemals in Ihre HCL eingetragen werden:

export AWS_ACCESS_KEY_ID="your-object-storage-access-key"
export AWS_SECRET_ACCESS_KEY="your-object-storage-secret-key"
terraform init   # migrates local state into the bucket

4.2 Überlegungen zur Statussperre

Die Statussperre verhindert, dass zwei apply-Läufe den Status gleichzeitig beschädigen. AWS S3-Backends verlassen sich traditionell auf eine DynamoDB-Tabelle für Sperren, die IONOS Object Storage nicht bereitstellt. Behandeln Sie das IONOS S3-Backend als ungesperrt: Serialisieren Sie die Anwendungen durch eine einzelne CI/CD-Pipeline, führen Sie nie gleichzeitige Anwendungen gegen denselben Statusschlüssel aus und verwenden Sie eine separate Status-key pro Umgebung (zum Beispiel base/, staging/, prod/), damit unabhängige Stapel nie um Ressourcen konkurrieren.

5. Datenquellen, Importe und Kostenvorbeugung

Das Hartcodieren von Bild-IDs und Regionenzeichenfolgen macht Konfigurationen brüchig. Datenquellen Abfragen den IONOS API bei der Planung, damit Ihre HCL portabel bleibt. Importe bringen Ressourcen, die außerhalb von Terraform erstellt wurden, unter Verwaltung. Und eine disziplinierte Zerstörung hält Ihre Rechnung ehrlich.

5.1 Bild- und Standort-Datenquellen

data "ionoscloud_location" "frankfurt" {
  name    = "fra"
  feature = "SSD"
}

data "ionoscloud_image" "ubuntu" {
  type     = "HDD"
  location = "de/fra"
  cloud_init = "V1"
  image_alias = "ubuntu:latest"
}

Die ionoscloud_image-Datenquelle löst ein aktuelles Bild auf, damit Sie nicht eine veraltete Bild-UUID festlegen, die möglicherweise nicht mehr gültig ist. Die ionoscloud_location-Datenquelle bestätigt eine Region und ihre Funktionsverfügbarkeit, bevor Sie darin bereitstellen. Verweisen Sie auf das Ergebnis mit data.ionoscloud_image.ubuntu.id im volume-Block des Servers, wie in Abschnitt 2 gezeigt.

Die folgende Tabelle fasst die vier Möglichkeiten zur Steuerung der IONOS-Bereitstellung zusammen, die Sie nun in den Einheiten 1.1 und 1.2 gesehen haben.

Verwenden Sie Terraform, wenn die Infrastruktur wiederholbar und überprüfbar sein muss. Greifen Sie auf SDK oder ionosctl zurück, wenn es um Laufzeitoperationen und schnelle Überprüfungen geht, die nicht in Ihrem deklarativen Stapel gehören.

5.2 Importieren bestehender Ressourcen

Wenn ein Rechenzentrum oder ein Server bereits existiert, vielleicht in DCD erstellt oder durch ein früheres curl-Skript, importieren Sie es, anstatt es neu zu erstellen. Schreiben Sie zunächst einen entsprechenden Ressourcenblock und importieren Sie ihn dann. IONOS-Importe verwenden eine zusammengesetzte ID, die die Rechenzentrum-ID und die Ressourcen-ID verbindet.

# Import an existing server: format is datacenter_id/server_id
terraform import ionoscloud_server.api \
  3fa85f64-5717-4562-b3fc-2c963f66afa6/9bc92f81-1234-4cde-8901-abcdef012345

# Import a datacenter (single ID)
terraform import ionoscloud_datacenter.taskboard 3fa85f64-5717-4562-b3fc-2c963f66afa6

Nach dem Import führen Sie terraform plan aus. Wenn der Plan Änderungen zeigt, stimmt Ihre HCL noch nicht mit der Realität überein. Stellen Sie die Attribute des Ressourcenblocks mit der Live-Konfiguration in Einklang, bis plan keine Änderungen mehr meldet. Erst dann ist die Ressource sicher unter Verwaltung.

5.3 Kostenvorbeugung und ephemere Umgebungen

Jede Ressource, die Terraform auf apply bereitstellt, verursacht ab dem Moment ihrer Existenz Kosten. Der disziplinierte Arbeitsablauf ist: Immer plan vor apply, immer destroy, was Sie zum Testen starten. Das Muster der ephemeren Umgebung erstellt einen vollständigen Stapel für einen Testlauf und baut ihn dann wieder ab.

# Spin up a throwaway environment for a feature branch
terraform workspace new pr-142
terraform apply -auto-approve

# ... run integration tests against the live infrastructure ...

# Tear it all down so it stops billing
terraform destroy -auto-approve
terraform workspace delete pr-142

Das Einbinden von terraform destroy in den Abbau-Schritt eines CI-Jobs garantiert, dass eine vergessene Umgebung nicht stillschweigend Kosten für Wochen ansammeln kann.

API Referenz-Quick-Card

Der IONOS Terraform-Anbieter bezeichnet diese Cloud-API-Endpunkte intern. Die Kenntnis davon hilft Ihnen bei der Fehlersuche, wenn ein apply feststeckt.

Basis-URL: https://api.ionos.com/cloudapi/v6 Authentifizierung: Authorization: Bearer <token> (Anbieter liest IONOS_TOKEN)

Code-Lab

Ziel: Baue TaskBoards Basis-VDC mit Terraform: ein Rechenzentrum, ein LAN und einen Server mit einem angehängten Volume. Plane, wende an, überprüfe und zerstöre.

Voraussetzungen:

• IONOS Cloud-Konto mit einem API-Token, der als IONOS_TOKEN exportiert wurde
• Terraform 1.5 oder später lokal installiert
• ionosctl konfiguriert (aus Einheit 1.1) für die Überprüfung

Schritt 1: Konfiguration vorbereiten

mkdir taskboard-base && cd taskboard-base
touch versions.tf provider.tf main.tf

Erwartete Ausgabe:

(no output; three empty files created)

Schritt 2: Anbieter hinzufügen und Version festlegen

Füge den versions.tf-Inhalt aus Abschnitt 1.1 und provider "ionoscloud" {} aus Abschnitt 1.2 in deine Dateien ein, dann initialisiere.

terraform init

Erwartete Ausgabe:

Initializing provider plugins...
- Installing ionos-cloud/ionoscloud v6.4.x...
Terraform has been successfully initialized!

Schritt 3: VDC-Ressourcen schreiben

Füge die ionoscloud_datacenter-, ionoscloud_lan- und ionoscloud_server-Blöcke aus Abschnitt 2.1 sowie die ionoscloud_image-Datenquelle aus Abschnitt 5.1 zu main.tf hinzu.

Schritt 4: Planen und überprüfen

export TF_VAR_server_password="ChangeMe-Strong-Pw-1"
terraform plan -out=taskboard.tfplan

Erwartete Ausgabe:

Plan: 3 to add, 0 to change, 0 to destroy.

Schritt 5: Anwenden

terraform apply taskboard.tfplan

Erwartete Ausgabe:

ionoscloud_datacenter.taskboard: Creation complete after 25s [id=3fa85f64-...]
ionoscloud_server.api: Still creating... [1m20s elapsed]
ionoscloud_server.api: Creation complete after 2m10s [id=9bc92f81-...]
Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

Schritt 6: Überprüfen mit ionosctl

terraform output -raw datacenter_id 2>/dev/null || true
ionosctl server list --datacenter-id $(terraform state show ionoscloud_datacenter.taskboard | grep -m1 'id ' | awk '{print $3}' | tr -d '"')

Erwartete Ausgabe:

ServerId   Name            State       Cores   Ram
9bc92f81   taskboard-api   AVAILABLE   2       4096

Schritt 7: Zustand überprüfen

terraform state list

Erwartete Ausgabe:

data.ionoscloud_image.ubuntu
ionoscloud_datacenter.taskboard
ionoscloud_lan.app
ionoscloud_server.api

Validierungs-Checkliste:

• [ ] terraform apply abgeschlossen mit 3 hinzugefügten Ressourcen
• [ ] ionosctl server list zeigt den Server als AVAILABLE an
• [ ] terraform state list zeigt alle gemanagten Ressourcen an

Aufräumen:

terraform destroy -auto-approve

Häufige Fallstricke

1. Löschen von Ressourcen im DCD, die von Terraform verwaltet werden

   • Problem: Sie löschen den Server manuell in der Web-Benutzeroberfläche, dann treten terraform apply-Fehler auf oder es werden unabhängige Ressourcen neu erstellt.
   • Warum es passiert: Der Zustand von Terraform enthält den gelöschten Server noch immer. Der aktuelle API-Zustand enthält ihn jedoch nicht mehr, so dass sich Zustand und Realität voneinander entfernen.
   • Lösung: Entfernen Sie den veralteten Eintrag aus dem Zustand, dann lassen Sie Terraform die Zustände angleichen:

   terraform state rm ionoscloud_server.api
   terraform plan   # now matches reality
   

2. Vergessen der S3-Backend-Skip-Flags

   • Problem: terraform init gegen das Object Storage-Backend hängt oder schlägt mit einem STS- oder Konto-ID-Fehler fehl.
   • Warum es passiert: Das S3-Backend geht davon aus, dass AWS verwendet wird, und versucht AWS-spezifische Aufrufe, die IONOS Object Storage nicht implementiert.
   • Lösung: Fügen Sie die Skip-Flags und den expliziten Endpunkt zum Backend-Block hinzu:

   skip_credentials_validation = true
   skip_region_validation      = true
   skip_requesting_account_id  = true
   endpoints = { s3 = "https://s3.eu-central-1.ionoscloud.com" }
   

3. Fixieren einer veralteten Bild-UUID anstelle der Verwendung einer Datenquelle

   • Problem: terraform apply schlägt mit einem Bild-nicht-gefunden-Fehler monate nachdem die Konfiguration zuletzt funktioniert hat, fehl.
   • Warum es passiert: Eine hartcodierte Bild-UUID wurde upstream pensioniert. Die asynchrone Servererstellung wird abgebrochen, weil ihre Boot-Volume auf ein fehlendes Bild verweist.
   • Lösung: Lösen Sie das Bild zur Planungszeit mit der Datenquelle auf und verweisen Sie darauf:

   data "ionoscloud_image" "ubuntu" {
     type        = "HDD"
     location    = "de/fra"
     image_alias = "ubuntu:latest"
   }
   # volume { image_name = data.ionoscloud_image.ubuntu.id }
   

Zusammenfassung

Sie können jetzt die IONOS-Infrastruktur deklarativ beschreiben und deren gesamten Lebenszyklus über Code verwalten. Sie haben den IONOS Terraform-Anbieter konfiguriert und versionsspezifisch festgelegt, sich mit IONOS_TOKEN authentifiziert und die Basis-VDC von TaskBoard aus ionoscloud_datacenter, ionoscloud_lan, ionoscloud_server, ionoscloud_volume und ionoscloud_nic-Ressourcen aufgebaut. Sie haben den Zustand in ein S3-kompatibles Object Storage-Backend verschoben, Datenquellen verwendet, um Bilder und Standorte dynamisch aufzulösen, vorhandene Ressourcen importiert und das Muster für ephemere Umgebungen übernommen, damit die Testinfrastruktur sauber heruntergefahren wird.

Das asynchrone Bereitstellungsmodell, das Sie in Einheit 1.1 manuell behandelt haben, ist jetzt ein inneres Anliegen des Anbieters: Terraform überwacht den Anfragestatus für Sie und ordnet Operationen über seinen Abhängigkeitsgraphen an. Von hier aus baut jede Infrastrukturreinheit in diesem Kurs auf dieser gleichen Terraform-Basis auf.

Wichtige Punkte:

• Der IONOS-Anbieter unterstützt V5- und V6-API-Angebote; immer die Version mit required_providers festlegen und die Lock-Datei committen
• Sich mit IONOS_TOKEN authentifizieren, damit kein Geheimnis in Ihre HCL eingibt; alle Ressourcen sind mit ionoscloud_ vorangestellt
• Terraform überwacht das asynchrone /requests/{id}/status-Endpunkt intern und ordnet Operationen über den Ressourcen-Abhängigkeitsgraphen an
• Das Object Storage-S3-Backend benötigt die skip_*-Flags und einen expliziten IONOS-Endpunkt und authentifiziert sich mit Zugriffsschlüssel plus Geheimschlüssel, nicht mit einem Bearer-Token
• Immer plan vor apply und destroy ephemere Umgebungen, um die Kosten zu kontrollieren

Wichtige Begriffe:

• Anbieter: Das Plugin, das HCL-Ressourcen in IONOS Cloud-API-Aufrufe übersetzt, veröffentlicht als ionos-cloud/ionoscloud
• Zustand: Terraform's Aufzeichnung davon, welche realen IONOS-Ressourcen es verwaltet, lokal oder in einem Object Storage-Backend gespeichert
• Datenquelle: Eine schreibgeschützte Abfrage gegen die IONOS-API bei der Planung, wie z.B. ionoscloud_image, verwendet, um die Hartcodierung von IDs zu vermeiden
• Import: Ein vorhandenes IONOS-Ressourcen unter Terraform-Verwaltung bringen, indem ein zusammengesetztes datacenter_id/resource_id verwendet wird
• Ephemere Umgebung: Ein vollständiger Stack, der für einen Testlauf erstellt und mit terraform destroy heruntergefahren wird, um verbleibende Gebühren zu vermeiden

Nächste Schritte

Weiterlernen: Einheit 1.3: Wissensprüfung - Programmatische Grundlagen

Verwandte Themen:

• Einheit 1.1: IONOS API, Authentifizierung und asynchrone Modell
• Einheit 2.1: Compute und Serverautomatisierung