Get best of the week

Das Buch "Terraform: Infrastruktur auf Codeebene"

BildHallo habrozhiteli! Das Buch richtet sich an alle, die für den bereits geschriebenen Code verantwortlich sind. Dies gilt für Systemadministratoren, Betriebsspezialisten, Release-, SR-, DevOps-Ingenieure, Infrastrukturentwickler, Vollzyklusentwickler, Leiter von Entwicklungsteams und technische Direktoren. Unabhängig von Ihrer Position ist dieses Buch genau das Richtige für Sie, wenn Sie an der Infrastruktur beteiligt sind, Code bereitstellen, Server konfigurieren, Cluster skalieren, Daten sichern, Anwendungen überwachen und Anrufe um drei Uhr morgens beantworten.

Zusammen werden diese Verantwortlichkeiten üblicherweise als operative Aktivitäten (oder Systemadministration) bezeichnet. Zuvor wurden Entwickler, die wissen, wie man Code schreibt, aber die Systemadministration nicht verstanden, häufig getroffen. Systemadministratoren stießen häufig auf die Fähigkeit, Code zu schreiben. Sobald diese Trennung akzeptabel war, aber in der modernen Welt, die ohne Cloud Computing und die DevOps-Bewegung nicht mehr vorstellbar ist, benötigt fast jeder Entwickler administrative Fähigkeiten, und jeder Systemadministrator muss programmieren können.

Sie lernen nicht nur, wie Sie die Infrastruktur in Form von Code mit Terraform verwalten, sondern auch, wie sie in das Gesamtkonzept von DevOps passt. Hier sind einige Fragen, die Sie durch Lesen dieses Buches beantworten können.

  • Warum überhaupt IaC verwenden?
  • , , ?
  • Terraform, Chef, Ansible, Puppet, Salt, CloudFormation, Docker, Packer Kubernetes?
  • Terraform ?
  • Terraform, ?
  • Terraform, ?
  • Terraform?
  • Terraform ?
  • Terraform ?

2017 . 2019- , ! . , .

, , , Terraform, .

  • Terraform. , Terraform 0.8. Terraform 0.12. , . , !
  • . Terraform. , , , , , , , .
  • . Terraform . , , — , .
  • . 8 , Terraform . , , , : , .
  • HCL2. Terraform 0.12 HCL HCL2. ( ${…}!), , , null, for_each for, . HCL2, 5 6.
  • . Terraform 0.9 . Terraform . Terraform 0.9 , ; 0.10 . 3.
  • Terraform. Terraform 0.10 ( AWS, GCP, Azure . .). , . terraform init , . 2 7.
  • . 2016 Terraform (AWS, GCP Azure). 100, , , 1. (, Alicloud, Oracle Cloud Infrastructure, VMware vSphere .), , (GitHub, GitLab BitBucket), (MySQL, PostreSQL InfluxDB), ( DataDog, New Relic Grafana), Kubernetes, Helm, Heroku, Rundeck Rightscale . , : , AWS , , CloudFormation!
  • Terraform. 2017 HashiCorp Terraform (registry.terraform.io) — , Terraform, . 2018 . Terraform 0.11 . « » . 153.
  • . Terraform 0.9 : , , errored.tfstate. Terraform 0.12 . , , .
  • . , (. « » . 144), « » (, « Terraform» . 242), plan apply (. « » . 64), create_before_destroy, count, (. «» . 160), , provider .

. Terraform


(Die Probleme des automatischen Testens werden später in diesem Buch viel mehr beachtet.)

Die DevOps-Welt ist voller unterschiedlicher Ängste: Jeder hat Angst, Dinge funktionieren zu lassen, Daten zu verlieren oder gehackt zu werden. Wenn Sie Änderungen vornehmen, fragen Sie sich immer, welche Konsequenzen dies haben wird. Wird es sich in allen Umgebungen gleich verhalten? Wird es einen weiteren Ausfall verursachen? Und wenn dies passiert, wie viel müssen Sie diesmal bei der Arbeit bleiben, um das Problem zu beheben? Mit dem Wachstum des Unternehmens steht mehr auf dem Spiel, was den Bereitstellungsprozess noch verschlimmert und das Fehlerrisiko erhöht. Viele Unternehmen versuchen, dieses Risiko durch weniger häufige Bereitstellungen zu minimieren. Infolgedessen wird jede einzelne Bereitstellung größer und fehleranfälliger.

Wenn Sie Ihre Infrastruktur in Form von Code verwalten, können Sie Risiken besser minimieren: Tests. Ihr Ziel ist es, Ihnen genügend Vertrauen zu geben, um Änderungen vorzunehmen. Das Schlüsselwort hier ist Vertrauen: Keine Tests können keine Fehler garantieren, sodass Sie eher mit der Wahrscheinlichkeit umgehen. Wenn Sie alle Ihre Infrastruktur- und Bereitstellungsprozesse als Code erfassen können, können Sie diesen Code in einer Testumgebung testen. Bei Erfolg besteht eine große Chance, dass derselbe Code in einer industriellen Umgebung funktioniert. In einer Welt der Angst und Unsicherheit sind hohe Wahrscheinlichkeit und Vertrauen teuer.

In diesem Kapitel werden wir den Prozess des Testens von Infrastrukturcode sowohl manuell als auch automatisch durchlaufen, wobei letzterer im Vordergrund steht.

Manuelle Tests:

  • Grundlagen des manuellen Testens;
  • Reinigungsressourcen nach Tests.

Automatisierte Tests:

  • Unit-Tests;
  • Integrationstests;
  • End-to-End-Tests;
  • andere Testansätze.

Manuelle Tests


Wenn Sie darüber nachdenken, wie Sie Terraform-Code testen, ist es hilfreich, einige Parallelen zum Testen von Code zu ziehen, der in universellen Programmiersprachen wie Ruby geschrieben wurde. Stellen Sie sich vor, Sie schreiben einen einfachen Ruby-Webserver in die Datei web-server.rb:

class WebServer < WEBrick::HTTPServlet::AbstractServlet
  def do_GET(request, response)
     case request.path
     when "/"
         response.status = 200
         response['Content-Type'] = 'text/plain'
         response.body = 'Hello, World'
     else
         response.status = 404
         response['Content-Type'] = 'text/plain'
         response.body = 'Not Found'
     end
  end
end

Dieser Code gibt eine 200-OK-Antwort mit dem Text Hello, World für die URL / zurück. Für jede andere Adresse lautet die Antwort 404. Wie würden Sie diesen Code manuell testen? In der Regel wird etwas mehr Code hinzugefügt, um den Webserver lokal auszuführen:

#   ,      
#  ,       
if __FILE__ == $0
  #      8000
  server = WEBrick::HTTPServer.new :Port => 8000
  server.mount '/', WebServer

  #    Ctrl+C
  trap 'INT' do server.shutdown end

  #  
  server.start
end

Wenn Sie diese Datei im Terminal ausführen, wird der Webserver auf Port 8000 geladen:

$ ruby web-server.rb
[2019-05-25 14:11:52] INFO WEBrick 1.3.1
[2019-05-25 14:11:52] INFO ruby 2.3.7 (2018-03-28) [universal.x86_64-darwin17]
[2019-05-25 14:11:52] INFO WEBrick::HTTPServer#start: pid=19767 port=8000

Um den Betrieb dieses Servers zu überprüfen, können Sie den Browser oder Curl verwenden:

$ curl localhost:8000/
Hello, World

$ curl localhost:8000/invalid-path
Not Found

Stellen Sie sich nun vor, wir hätten diesen Code geändert, indem wir einen / api-Einstiegspunkt hinzugefügt haben, der 201 Created und einen Body im JSON-Format zurückgibt:

class WebServer < WEBrick::HTTPServlet::AbstractServlet
  def do_GET(request, response)
     case request.path
     when "/"
         response.status = 200
         response['Content-Type'] = 'text/plain'
         response.body = 'Hello, World'
     when "/api"
         response.status = 201
         response['Content-Type'] = 'application/json'
         response.body = '{"foo":"bar"}'
     else
         response.status = 404
         response['Content-Type'] = 'text/plain'
         response.body = 'Not Found'
     end
  end
end

Um diesen aktualisierten Code manuell zu testen, drücken Sie Strg + C und starten Sie den Webserver neu, indem Sie das Skript erneut ausführen:

$ ruby web-server.rb
[2019-05-25 14:11:52] INFO WEBrick 1.3.1
[2019-05-25 14:11:52] INFO ruby 2.3.7 (2018-03-28) [universal.x86_64-darwin17]
[2019-05-25 14:11:52] INFO WEBrick::HTTPServer#start: pid=19767 port=8000
^C
[2019-05-25 14:15:54] INFO going to shutdown ...
[2019-05-25 14:15:54] INFO WEBrick::HTTPServer#start done.

$ ruby web-server.rb
[2019-05-25 14:11:52] INFO WEBrick 1.3.1
[2019-05-25 14:11:52] INFO ruby 2.3.7 (2018-03-28) [universal.x86_64-darwin17]
[2019-05-25 14:11:52] INFO WEBrick::HTTPServer#start: pid=19767 port=8000

Um die neue Version zu überprüfen, können Sie erneut den Befehl curl verwenden:

$ curl localhost:8000/api
{"foo":"bar"}

Grundlagen des manuellen Testens


Wie sieht diese Art des manuellen Testens in Terraform aus? In den vorherigen Kapiteln steht beispielsweise noch der Code für die Bereitstellung von ALB zur Verfügung. Hier ist ein Ausschnitt aus der Datei modules / network / alb / main.tf:

resource "aws_lb" "example" {
   name                     = var.alb_name
   load_balancer_type = "application"
   subnets                  = var.subnet_ids
   security_groups      = [aws_security_group.alb.id]
}

resource "aws_lb_listener" "http" {
   load_balancer_arn = aws_lb.example.arn
   port                      = local.http_port
   protocol                = "HTTP"

   #      404
   default_action {
      type = "fixed-response"

      fixed_response {
        content_type = "text/plain"
        message_body = "404: page not found"
        status_code = 404
      }
    }
}

resource "aws_security_group" "alb" {
   name = var.alb_name
}

# (...)

Wenn Sie diese Liste mit Ruby-Code vergleichen, sehen Sie einen ziemlich offensichtlichen Unterschied: AWS ALB, Zielgruppen, Listener, Sicherheitsgruppen und andere Ressourcen können nicht auf Ihrem eigenen Computer bereitgestellt werden.

Die wichtigste Schlussfolgerung zum Testen Nr. 1 folgt daraus: Terraform-Code-Tests können nicht lokal durchgeführt werden.

Dies gilt nicht nur für Terraform, sondern auch für die meisten IaC-Tools. Die einzige praktische Möglichkeit, manuelle Tests in Terraform durchzuführen, besteht darin, den Code in einer realen Umgebung (d. H. In AWS) bereitzustellen. Mit anderen Worten, das unabhängige Starten der Terraform Apply- und Terraform Destroy-Befehle, an denen Sie beim Lesen des Buches gearbeitet haben, ist ein manuelles Testen in Terraform.

Dies ist einer der Gründe, warum es so wichtig ist, einfach zu implementierende Beispiele im Beispielordner jedes Moduls zu haben (siehe Kapitel 6). Um das Alb-Modul zu testen, verwenden Sie am einfachsten den Demo-Code, den Sie in examples / alb erstellt haben:

provider "aws" {
   region = "us-east-2"

   #     AWS  2.x
   version = "~> 2.0"
}

module "alb" {
    source = "../../modules/networking/alb"

    alb_name = "terraform-up-and-running"
    subnet_ids = data.aws_subnet_ids.default.ids
}

Um dieses Beispiel bereitzustellen, müssen Sie den Befehl terraform apply ausführen, wie Sie es wiederholt getan haben:

$ terraform apply

(...)

Apply complete! Resources: 5 added, 0 changed, 0 destroyed.

Outputs:

alb_dns_name = hello-world-stage-477699288.us-east-2.elb.amazonaws.com

Am Ende der Bereitstellung können Sie ein Tool wie Curl verwenden, um beispielsweise sicherzustellen, dass ALB standardmäßig 404 zurückgibt:

$ curl \
   -s \
   -o /dev/null \
   -w "%{http_code}" \
hello-world-stage-477699288.us-east-2.elb.amazonaws.com

404

Infrastrukturprüfung

, HTTP, , , curl HTTP-. . , MySQL, MySQL. VPN-, VPN. , , SSH - . . , , . , .

Ich möchte Sie daran erinnern: ALB gibt 404 zurück, da in der Konfiguration keine anderen Listener-Regeln vorhanden sind, und die Standardaktion im alb-Modul hat die Antwort 404:

resource "aws_lb_listener" "http" {
   load_balancer_arn = aws_lb.example.arn
   port                      = local.http_port
   protocol                = "HTTP"

   #      404
   default_action {
      type = "fixed-response"

      fixed_response {
       content_type = "text/plain"
       message_body = "404: page not found"
       status_code = 404
      }
   }
}

Sie wissen also bereits, wie Sie Ihren Code ausführen und testen. Jetzt können Sie Änderungen vornehmen. Jedes Mal, wenn Sie etwas ändern (so dass beispielsweise die Standardaktion 401 zurückgibt), müssen Sie den Befehl terraform apply verwenden, um den neuen Code bereitzustellen:

$ terraform apply

(...)

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

Outputs:

alb_dns_name = hello-world-stage-477699288.us-east-2.elb.amazonaws.com

Um die neue Version zu überprüfen, können Sie curl neu starten:

$ curl \
   -s \
   -o /dev/null \
   -w "%{http_code}" \
   hello-world-stage-477699288.us-east-2.elb.amazonaws.com
401

Wenn Sie fertig sind, führen Sie den Befehl terraform destroy aus, um die Ressourcen zu entfernen:

$ terraform destroy

(...)

Apply complete! Resources: 0 added, 0 changed, 5 destroyed.

Mit anderen Worten, wenn Sie mit Terraform arbeiten, benötigt jeder Entwickler gute Codebeispiele zum Testen und eine reale Entwicklungsumgebung (wie ein AWS-Konto), die als Äquivalent zu einem lokalen Computer dient und zum Ausführen von Tests verwendet wird. Beim manuellen Test müssen Sie höchstwahrscheinlich eine große Anzahl von Infrastrukturkomponenten erstellen und entfernen. Dies kann zu vielen Fehlern führen. In dieser Hinsicht sollte die Umgebung vollständig von stabileren Umgebungen isoliert sein, die für Endtests und insbesondere für industrielle Anwendungen vorgesehen sind.

Vor diesem Hintergrund empfehle ich jedem Entwicklungsteam dringend, eine isolierte Umgebung vorzubereiten, in der Sie jede Infrastruktur ohne Konsequenzen erstellen und entfernen können. Um die Wahrscheinlichkeit von Konflikten zwischen verschiedenen Entwicklern zu minimieren (stellen Sie sich vor, zwei Entwickler versuchen, einen Load Balancer mit demselben Namen zu erstellen), wäre die ideale Lösung, jedem Teammitglied eine separate, vollständig isolierte Umgebung zu geben. Wenn Sie beispielsweise Terraform in Verbindung mit AWS verwenden, sollte jeder Entwickler idealerweise über ein eigenes Konto verfügen, in dem er alles testen kann, was er möchte.

Ressourcenbereinigung nach Tests


Das Vorhandensein vieler isolierter Umgebungen ist für die hohe Produktivität von Entwicklern erforderlich. Wenn Sie jedoch keine Vorsicht walten lassen, können Sie viele zusätzliche Ressourcen ansammeln, die alle Ihre Umgebungen überladen und Sie eine runde Summe kosten.
Reinigen Sie Ihre isolierten Umgebungen regelmäßig, um die Kosten unter Kontrolle zu halten. Dies ist die wichtigste Schlussfolgerung zum Testen von Nummer 2 .

Sie sollten mindestens eine solche Kultur im Team erstellen, wenn die Entwickler nach dem Testen alles löschen, was sie mit dem Befehl terraform destroy bereitgestellt haben. Es kann möglich sein, Werkzeuge zum Aufräumen überschüssiger oder alter Ressourcen zu finden, die regelmäßig ausgeführt werden können (z. B. mit cron). Hier einige Beispiele für verschiedene Bereitstellungsumgebungen.

  • cloud-nuke (http://bit.ly/2OIgM9r). , . AWS ( Amazon EC2 Instances, ASG, ELB . .). (Google Cloud, Azure) . — , . , cloud-nuke cron, . , , , :

    $ cloud-nuke aws --older-than 48h
  • Janitor Monkey (http://bit.ly/2M4GoLB). , AWS , ( — ). , , , . Netflix Simian Army, Chaos Monkey . , Simian Army , : , Janitor Monkey Swabbie (http://bit.ly/2OLrOLb).
  • aws-nuke (http://bit.ly/2ZB8lOe). Dies ist ein Open Source-Tool zum Löschen aller Inhalte eines AWS-Kontos. Die zu löschenden Konten und Ressourcen werden in der Konfigurationsdatei im YAML-Format angegeben:

    #   
regions:
- us-east-2

#    
accounts:
   "111111111111": {}

#    
resource-types:
   targets:
   - S3Object
   - S3Bucket
   - IAMRole

    Aws-Nuke beginnt wie folgt:

    $ aws-nuke -5c config.yml

Automatisierte Tests


Das Konzept des automatischen Testens besteht darin, dass Tests geschrieben werden, um das Verhalten von echtem Code zu testen. In Kapitel 8 erfahren Sie, dass diese Tests mithilfe des CI-Servers nach jedem einzelnen Commit ausgeführt werden können. Wenn sie nicht abgeschlossen sind, kann die Fixierung sofort rückgängig gemacht oder korrigiert werden. Somit ist Ihr Code immer betriebsbereit.

Es gibt drei Arten von automatisierten Tests.

  • . — . , . (, , - ) mock-. (, mock- , ) , .
  • . . , . mock-: , , , , , , , mock-.
  • . (, , , ) . : , Selenium . - mock-, ( , ).

Jede Art von Test hat ihren eigenen Zweck. Mit ihrer Hilfe können Sie alle Arten von Fehlern identifizieren. Daher sollten sie zusammen verwendet werden. Unit-Tests sind schnell und ermöglichen es Ihnen, sich sofort ein Bild von den vorgenommenen Änderungen zu machen und eine Vielzahl von Kombinationen zu überprüfen. Dies gibt Ihnen die Gewissheit, dass sich die elementaren Komponenten Ihres Codes (einzelne Module) wie erwartet verhalten. Die Tatsache, dass die Module separat korrekt funktionieren, bedeutet jedoch keineswegs, dass sie zusammenarbeiten können. Um sicherzustellen, dass Ihre Elementarkomponenten kompatibel sind, sind Integrationstests erforderlich. Auf der anderen Seite garantiert das korrekte Verhalten verschiedener Teile des Systems nicht, dass dieses System nach der Bereitstellung in einer industriellen Umgebung ordnungsgemäß funktioniert. Daher sind Tests erforderlich, um Ihren Code unter Bedingungen zu testen, die den tatsächlichen Bedingungen nahe kommen.

»Weitere Informationen zum Buch finden Sie auf der Website des Herausgebers.
» Inhalt
» Auszug

für Khabrozhiteley 25% Gutscheinrabatt - Terraform

Nach Zahlung der Papierversion des Buches wird ein elektronisches Buch per E-Mail verschickt.

More articles:


All Articles