Buku "Terraform: infrastruktur di tingkat kode"

gambarHalo, habrozhiteli! Buku ini ditujukan untuk semua orang yang bertanggung jawab atas kode yang sudah ditulis. Ini berlaku untuk administrator sistem, spesialis operasi, rilis, SR, insinyur DevOps, pengembang infrastruktur, pengembang siklus penuh, pemimpin tim teknik dan direktur teknis. Apa pun posisi Anda, jika Anda terlibat dalam infrastruktur, menyebarkan kode, mengkonfigurasi server, cluster skala, mencadangkan data, memantau aplikasi, dan menjawab panggilan pada pukul tiga pagi, buku ini cocok untuk Anda.

Bersama-sama, tanggung jawab ini biasanya disebut sebagai kegiatan operasional (atau administrasi sistem). Sebelumnya, pengembang yang tahu cara menulis kode tetapi tidak mengerti administrasi sistem sering bertemu; administrator sistem cukup sering menjumpai tanpa kemampuan untuk menulis kode. Setelah pemisahan ini dapat diterima, tetapi di dunia modern, yang tidak lagi dapat dibayangkan tanpa cloud computing dan pergerakan DevOps, hampir semua pengembang membutuhkan keterampilan administratif, dan setiap administrator sistem harus dapat memprogram.

Anda tidak hanya akan belajar bagaimana mengelola infrastruktur dalam bentuk kode menggunakan Terraform, tetapi juga belajar bagaimana hal itu cocok dengan konsep keseluruhan DevOps. Berikut beberapa pertanyaan yang dapat Anda jawab dengan membaca buku ini.

  • Mengapa menggunakan IaC?
  • , , ?
  • 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


(perhatian lebih banyak diberikan pada masalah pengujian otomatis dalam buku nanti)

Dunia DevOps penuh dengan ketakutan yang berbeda: semua orang takut untuk membiarkan hal-hal bekerja, kehilangan data atau diretas. Saat melakukan perubahan, Anda selalu bertanya pada diri sendiri apa konsekuensi yang akan ditimbulkannya. Apakah akan berperilaku sama di semua lingkungan? Apakah akan menyebabkan pemadaman lagi? Dan, jika itu terjadi, berapa banyak Anda harus tetap bekerja saat ini untuk memperbaikinya? Seiring pertumbuhan perusahaan, semakin banyak yang dipertaruhkan, membuat proses penyebaran semakin buruk dan meningkatkan risiko kesalahan. Banyak perusahaan mencoba untuk meminimalkan risiko ini melalui penyebaran yang lebih jarang, tetapi sebagai hasilnya, setiap penyebaran individu menjadi lebih besar dan lebih rentan terhadap kesalahan.

Jika Anda mengelola infrastruktur Anda dalam bentuk kode, Anda memiliki cara yang lebih baik untuk meminimalkan risiko: tes. Tujuan mereka adalah memberi Anda kepercayaan diri yang cukup untuk melakukan perubahan. Kata kuncinya di sini adalah kepercayaan diri: tidak ada tes yang dapat menjamin tidak ada kesalahan, sehingga Anda lebih mungkin untuk menghadapi kemungkinan. Jika Anda dapat menangkap semua infrastruktur dan proses penyebaran Anda sebagai kode, Anda dapat menguji kode ini di lingkungan pengujian. Jika berhasil, ada kemungkinan besar bahwa kode yang sama akan bekerja di lingkungan industri. Dalam dunia ketakutan dan ketidakpastian, probabilitas dan kepercayaan diri yang tinggi itu mahal.

Dalam bab ini, kita akan melalui proses pengujian kode infrastruktur, baik manual maupun otomatis, dengan penekanan pada yang terakhir.

Tes manual:

  • dasar-dasar pengujian manual;
  • sumber daya pembersihan setelah tes.

Tes otomatis:

  • unit test;
  • tes integrasi;
  • tes end-to-end;
  • pendekatan pengujian lainnya.

Tes manual


Saat berpikir tentang cara menguji kode Terraform, akan sangat berguna untuk menggambar beberapa persamaan dengan kode pengujian yang ditulis dalam bahasa pemrograman untuk tujuan umum seperti Ruby. Bayangkan Anda sedang menulis server web Ruby sederhana di file 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

Kode ini akan mengembalikan 200 tanggapan OK dengan badan Halo, Dunia untuk URL /; untuk alamat lain jawabannya 404. Bagaimana Anda menguji kode ini secara manual? Biasanya, beberapa kode ditambahkan untuk menjalankan server web secara lokal:

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

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

  #  
  server.start
end

Jika Anda menjalankan file ini di terminal, itu akan memuat server web pada port 8000:

$ 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

Untuk memeriksa operasi server ini, Anda dapat menggunakan browser atau ikal:

$ curl localhost:8000/
Hello, World

$ curl localhost:8000/invalid-path
Not Found

Sekarang bayangkan kita mengubah kode ini dengan menambahkan titik masuk / api ke dalamnya yang mengembalikan 201 Dibuat dan sebuah badan dalam format JSON:

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

Untuk menguji secara manual kode yang diperbarui ini, tekan Ctrl + C dan restart server web dengan menjalankan skrip lagi:

$ 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

Untuk memeriksa versi baru, Anda dapat kembali menggunakan perintah curl:

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

Dasar-Dasar Pengujian Manual


Seperti apakah pengujian manual ini nantinya di Terraform? Misalnya, dari bab-bab sebelumnya, Anda masih memiliki kode untuk menggunakan ALB. Berikut ini cuplikan dari file modules / networking / 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
}

# (...)

Jika Anda membandingkan cantuman ini dengan kode Ruby, Anda dapat melihat satu perbedaan yang sangat jelas: AWS ALB, grup target, pendengar, grup keamanan, dan sumber daya lainnya tidak dapat digunakan di komputer Anda sendiri.

Kesimpulan utama tentang pengujian No. 1 mengikuti dari ini: Pengujian kode Terraform tidak dapat dilakukan secara lokal.

Ini tidak hanya berlaku untuk Terraform, tetapi juga untuk sebagian besar alat IaC. Satu-satunya cara praktis untuk melakukan pengujian manual di Terraform adalah dengan menyebarkan kode di lingkungan nyata (mis. Di AWS). Dengan kata lain, meluncurkan terraform secara independen berlaku dan terraform menghancurkan perintah yang Anda kerjakan saat membaca buku ini adalah pengujian manual di Terraform.

Ini adalah salah satu alasan mengapa sangat penting untuk memiliki contoh yang mudah digunakan dalam folder contoh masing-masing modul (lihat bab 6). Untuk menguji modul alb, cara termudah adalah dengan menggunakan kode demo yang Anda buat dalam contoh / alb:

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
}

Untuk menerapkan contoh ini, Anda perlu menjalankan perintah terraform apply, seperti yang telah Anda lakukan berulang kali:

$ 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

Di akhir penyebaran, Anda dapat menggunakan alat seperti curl untuk, misalnya, memastikan bahwa ALB mengembalikan 404 secara default:

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

404

Pemeriksaan infrastruktur

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

Biarkan saya mengingatkan Anda: ALB mengembalikan 404 karena tidak adanya aturan pendengar lain dalam konfigurasi, dan tindakan default dalam modul alb memiliki respons 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
      }
   }
}

Jadi, Anda sudah tahu cara menjalankan dan menguji kode Anda. Sekarang Anda dapat mulai membuat perubahan. Setiap kali Anda mengubah sesuatu (sehingga, misalnya, tindakan default mengembalikan 401), Anda perlu menggunakan perintah terraform apply untuk menggunakan kode baru:

$ 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

Untuk memeriksa versi baru, Anda dapat memulai kembali ikal:

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

Setelah selesai, jalankan perintah penghancuran terraform untuk menghapus sumber daya:

$ terraform destroy

(...)

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

Dengan kata lain, ketika bekerja dengan Terraform, setiap pengembang membutuhkan sampel kode yang baik untuk pengujian dan lingkungan pengembangan nyata (seperti akun AWS), yang berfungsi sebagai setara dengan komputer lokal dan digunakan untuk menjalankan tes. Dalam proses pengujian manual, kemungkinan besar Anda harus membuat dan menghapus sejumlah besar komponen infrastruktur, dan ini dapat menyebabkan banyak kesalahan. Dalam hal ini, lingkungan harus sepenuhnya diisolasi dari lingkungan yang lebih stabil yang dimaksudkan untuk pengujian akhir dan khususnya untuk aplikasi industri.

Mengingat hal di atas, saya sangat menyarankan agar setiap tim pengembangan menyiapkan lingkungan yang terisolasi di mana Anda dapat membuat dan menghapus infrastruktur apa pun tanpa konsekuensi. Untuk meminimalkan kemungkinan konflik antara pengembang yang berbeda (bayangkan bahwa dua pengembang sedang mencoba membuat penyeimbang beban dengan nama yang sama), solusi ideal adalah dengan memberikan masing-masing anggota tim lingkungan terpisah yang sepenuhnya terisolasi. Misalnya, jika Anda menggunakan Terraform bersama dengan AWS, setiap pengembang idealnya memiliki akun sendiri di mana mereka dapat menguji semua yang mereka inginkan.

Pembersihan sumber daya setelah pengujian


Kehadiran banyak lingkungan yang terisolasi diperlukan untuk produktivitas pengembang yang tinggi, tetapi jika Anda tidak berhati-hati, Anda dapat mengumpulkan banyak sumber daya tambahan yang akan mengacaukan semua lingkungan Anda dan membuat Anda harus membayar sejumlah uang.
Untuk menjaga agar biaya tetap terkendali, bersihkan media yang terisolasi secara rutin. Ini adalah kesimpulan utama tentang pengujian nomor 2 .

Minimal, Anda harus membuat budaya seperti itu di tim ketika, setelah pengujian, pengembang menghapus semua yang mereka gunakan menggunakan perintah penghancuran terraform. Dimungkinkan untuk menemukan alat untuk membersihkan kelebihan atau sumber daya lama yang dapat dijalankan secara teratur (misalnya, menggunakan cron). Berikut adalah beberapa contoh untuk berbagai lingkungan penempatan.

  • 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). Ini adalah alat open source untuk menghapus semua konten akun AWS. Akun dan sumber daya yang akan dihapus ditentukan dalam file konfigurasi dalam format YAML:

    #   
    regions:
    - us-east-2
    
    #    
    accounts:
       "111111111111": {}
    
    #    
    resource-types:
       targets:
       - S3Object
       - S3Bucket
       - IAMRole

    Aws-nuke dimulai sebagai berikut:

    $ aws-nuke -5c config.yml

Tes Otomatis


Konsep pengujian otomatis adalah bahwa tes ditulis untuk menguji perilaku kode nyata. Dalam Bab 8, Anda akan belajar bahwa menggunakan server CI, tes ini dapat dijalankan setelah setiap individu melakukan. Jika tidak selesai, fiksasi dapat segera dibatalkan atau diperbaiki. Dengan demikian, kode Anda akan selalu operasional.

Ada tiga jenis tes otomatis.

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

Setiap jenis tes memiliki tujuannya sendiri, dan dengan bantuan mereka Anda dapat mengidentifikasi semua jenis kesalahan, sehingga harus digunakan bersama. Tes unit cepat dan memungkinkan Anda untuk segera mengetahui perubahan yang dibuat dan memeriksa berbagai kombinasi. Ini memberi Anda keyakinan bahwa komponen dasar kode Anda (modul individu) berperilaku seperti yang Anda harapkan. Namun, fakta bahwa modul bekerja dengan benar secara terpisah tidak berarti sama sekali bahwa mereka dapat bekerja bersama, oleh karena itu, untuk memastikan bahwa komponen dasar Anda kompatibel, tes integrasi diperlukan. Di sisi lain, perilaku yang benar dari berbagai bagian sistem tidak menjamin bahwa sistem ini akan berfungsi sebagaimana mestinya setelah ditempatkan di lingkungan industri, sehingga diperlukan pengujian untuk menguji kode Anda dalam kondisi yang dekat dengan yang asli.

»Informasi lebih lanjut tentang buku ini dapat ditemukan di situs web penerbit
» Isi
» Kutipan

Untuk Khabrozhiteley Diskon 25% untuk kupon - Terraform

Setelah pembayaran versi kertas buku, sebuah buku elektronik dikirim melalui email.

All Articles