Perangkap Terraform

Mari kita soroti beberapa kendala, termasuk yang terkait dengan loop, pernyataan if, dan teknik penerapan, serta masalah yang lebih umum yang memengaruhi Terraform secara umum:

• parameter count dan for_each memiliki batasan;
• membatasi penerapan zero downtime;
• bahkan rencana yang bagus pun bisa gagal;
• рефакторинг может иметь свои подвохи;
• koherensi yang ditangguhkan konsisten... dengan penundaan.

Parameter count dan for_each memiliki batasan

Contoh dalam bab ini banyak menggunakan parameter count dan ekspresi for_each dalam loop dan logika kondisional. Mereka berkinerja baik, namun mereka memiliki dua batasan penting yang perlu Anda waspadai.

• Count dan for_each tidak dapat mereferensikan variabel sumber daya keluaran apa pun.
• count dan for_each tidak dapat digunakan dalam konfigurasi modul.

count dan for_each tidak dapat mereferensikan variabel keluaran sumber daya apa pun

Bayangkan Anda perlu menerapkan beberapa server EC2 dan karena alasan tertentu Anda tidak ingin menggunakan ASG. Kode Anda bisa seperti ini:

resource "aws_instance" "example_1" {
   count             = 3
   ami                = "ami-0c55b159cbfafe1f0"
   instance_type = "t2.micro"
}

Mari kita lihat satu per satu.

Karena parameter count disetel ke nilai statis, kode ini akan berfungsi tanpa masalah: ketika Anda menjalankan perintah apply, tiga server EC2 akan dibuat. Namun bagaimana jika Anda ingin menerapkan satu server di setiap Availability Zone (AZ) dalam wilayah AWS Anda saat ini? Anda dapat membuat kode Anda memuat daftar zona dari sumber data aws_availability_zones dan kemudian mengulangi masing-masing zona dan membuat server EC2 di dalamnya menggunakan parameter count dan akses indeks array:

resource "aws_instance" "example_2" {
   count                   = length(data.aws_availability_zones.all.names)
   availability_zone   = data.aws_availability_zones.all.names[count.index]
   ami                     = "ami-0c55b159cbfafe1f0"
   instance_type       = "t2.micro"
}

data "aws_availability_zones" "all" {}

Kode ini juga akan berfungsi dengan baik, karena parameter count dapat mereferensikan sumber data tanpa masalah. Namun apa yang terjadi jika jumlah server yang perlu Anda buat bergantung pada keluaran suatu sumber daya? Untuk mendemonstrasikannya, cara termudah adalah dengan menggunakan sumber daya random_integer, yang, seperti namanya, mengembalikan bilangan bulat acak:

resource "random_integer" "num_instances" {
  min = 1
  max = 3
}

Kode ini menghasilkan angka acak antara 1 dan 3. Mari kita lihat apa yang terjadi jika kita mencoba menggunakan keluaran sumber daya ini dalam parameter count sumber daya aws_instance:

resource "aws_instance" "example_3" {
   count             = random_integer.num_instances.result
   ami                = "ami-0c55b159cbfafe1f0"
   instance_type = "t2.micro"
}

Jika Anda menjalankan terraform plan pada kode ini, Anda akan mendapatkan kesalahan berikut:

Error: Invalid count argument

   on main.tf line 30, in resource "aws_instance" "example_3":
   30: count = random_integer.num_instances.result

The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many instances will be created. To work around this, use the -target argument to first apply only the resources that the count depends on.

Terraform требует, чтобы count и for_each вычислялись на этапе планирования, до создания или изменения каких-либо ресурсов. Это означает, что count и for_each могут ссылаться на литералы, переменные, источники данных и даже списки ресурсов (при условии, что их длину можно определить во время планирования), но не на вычисляемые выходные переменные ресурса.

count dan for_each tidak dapat digunakan dalam konfigurasi modul

Suatu hari nanti Anda mungkin tergoda untuk menambahkan parameter count ke konfigurasi modul Anda:

module "count_example" {
     source = "../../../../modules/services/webserver-cluster"

     count = 3

     cluster_name = "terraform-up-and-running-example"
     server_port = 8080
     instance_type = "t2.micro"
}

Kode ini mencoba menggunakan count di dalam modul untuk membuat tiga salinan sumber daya cluster server web. Atau Anda mungkin ingin menghubungkan modul opsional berdasarkan beberapa kondisi Boolean dengan mengatur parameter count ke 0. Ini mungkin terlihat seperti kode yang masuk akal, tetapi Anda akan mendapatkan kesalahan ini saat menjalankan terraform plan:

Error: Reserved argument name in module block

   on main.tf line 13, in module "count_example":
   13: count = 3

The name "count" is reserved for use in a future version of Terraform.

Sayangnya, mulai Terraform 0.12.6, penggunaan count atau for_each pada sumber daya modul tidak didukung. Menurut catatan rilis Terraform 0.12 (http://bit.ly/3257bv4), HashiCorp berencana menambahkan kemampuan ini di masa mendatang, jadi bergantung pada kapan Anda membaca buku ini, kemampuan ini mungkin sudah tersedia. Untuk mengetahui secara pasti, baca log perubahan Terraform di sini.

Batasan Penerapan Nol Waktu Henti

Menggunakan blok create_before_destroy yang dikombinasikan dengan ASG adalah solusi bagus untuk membuat penerapan tanpa waktu henti, kecuali satu peringatan: aturan penskalaan otomatis tidak didukung. Atau lebih tepatnya, ini akan menyetel ulang ukuran ASG kembali ke min_size pada setiap penerapan, yang dapat menjadi masalah jika Anda menggunakan aturan penskalaan otomatis untuk menambah jumlah server yang berjalan.

Misalnya, modul webserver-cluster berisi sepasang sumber daya aws_autoscaling_schedule, yang pada jam 9 pagi meningkatkan jumlah server dalam cluster dari dua menjadi sepuluh. Jika Anda menerapkannya pada, katakanlah, pukul 11, ASG baru akan melakukan booting hanya dengan dua server, bukan sepuluh, dan akan tetap seperti itu hingga pukul 9 keesokan harinya.

Keterbatasan ini dapat diatasi dengan beberapa cara.

• Ubah parameter perulangan di aws_autoscaling_schedule dari 0 9 * * * (“jalankan jam 9 pagi”) menjadi seperti 0-59 9-17 * * * (“jalankan setiap menit dari jam 9 pagi sampai jam 5 sore”). Jika ASG sudah memiliki sepuluh server, menjalankan kembali aturan penskalaan otomatis ini tidak akan mengubah apa pun, itulah yang kami inginkan. Namun jika ASG baru saja dikerahkan, aturan ini akan memastikan maksimal dalam satu menit jumlah servernya akan mencapai sepuluh. Ini bukan pendekatan yang sepenuhnya elegan, dan lompatan besar dari sepuluh ke dua server dan sebaliknya juga dapat menimbulkan masalah bagi pengguna.
• Buat skrip khusus yang menggunakan API AWS untuk menentukan jumlah server aktif di ASG, panggil skrip tersebut menggunakan sumber data eksternal (lihat "Sumber Data Eksternal" di halaman 249), dan atur parameter kapasitas_yang diinginkan ASG ke nilai yang dikembalikan oleh naskah. Dengan cara ini, setiap instance ASG baru akan selalu berjalan pada kapasitas yang sama dengan kode Terraform yang ada dan membuatnya lebih sulit untuk dipelihara.

Tentu saja, Terraform idealnya memiliki dukungan bawaan untuk penerapan tanpa waktu henti, namun mulai Mei 2019, tim HashiCorp tidak memiliki rencana untuk menambahkan fungsi ini (detailnya - di sini).

Rencana yang benar mungkin tidak berhasil dilaksanakan

Terkadang perintah plan menghasilkan rencana penerapan yang benar-benar benar, namun perintah apply mengembalikan kesalahan. Coba, misalnya, menambahkan sumber daya aws_iam_user dengan nama yang sama dengan yang Anda gunakan untuk pengguna IAM yang Anda buat sebelumnya di Bab 2:

resource "aws_iam_user" "existing_user" {
   # Подставьте сюда имя уже существующего пользователя IAM,
   # чтобы попрактиковаться в использовании команды terraform import
   name = "yevgeniy.brikman"
}

Sekarang, jika Anda menjalankan perintah plan, Terraform akan menampilkan rencana penerapan yang tampaknya masuk akal:

Terraform will perform the following actions:

   # aws_iam_user.existing_user will be created
   + resource "aws_iam_user" "existing_user" {
         + arn                  = (known after apply)
         + force_destroy   = false
         + id                    = (known after apply)
         + name               = "yevgeniy.brikman"
         + path                 = "/"
         + unique_id         = (known after apply)
      }

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

Jika Anda menjalankan perintah terapkan, Anda akan mendapatkan kesalahan berikut:

Error: Error creating IAM User yevgeniy.brikman: EntityAlreadyExists:
User with name yevgeniy.brikman already exists.

   on main.tf line 10, in resource "aws_iam_user" "existing_user":
   10: resource "aws_iam_user" "existing_user" {

Masalahnya tentu saja pengguna IAM dengan nama tersebut sudah ada. Dan hal ini dapat terjadi tidak hanya pada pengguna IAM, namun pada hampir semua sumber daya. Mungkin saja seseorang membuat sumber daya ini secara manual atau menggunakan baris perintah, namun bagaimanapun juga, pencocokan ID akan menyebabkan konflik. Ada banyak variasi kesalahan ini yang sering kali mengejutkan pendatang baru di Terraform.

Poin utamanya adalah perintah terraform plan hanya memperhitungkan sumber daya yang ditentukan dalam file status Terraform. Jika sumber daya dibuat dengan cara lain (misalnya, secara manual dengan mengklik di konsol AWS), sumber daya tersebut tidak akan dimasukkan ke dalam file status dan oleh karena itu Terraform tidak akan memperhitungkannya saat menjalankan perintah rencana. Akibatnya, rencana yang sekilas tampak benar ternyata tidak berhasil.

Ada dua pelajaran yang dapat dipetik dari hal ini.

• Jika Anda sudah mulai bekerja dengan Terraform, jangan gunakan yang lain. Jika sebagian infrastruktur Anda dikelola menggunakan Terraform, Anda tidak dapat lagi mengubahnya secara manual. Jika tidak, Anda tidak hanya berisiko mengalami kesalahan Terraform yang aneh, tetapi Anda juga meniadakan banyak manfaat IaC karena kode tersebut tidak lagi menjadi representasi akurat dari infrastruktur Anda.
• Jika Anda sudah memiliki beberapa infrastruktur, gunakan perintah import. Jika Anda mulai menggunakan Terraform dengan infrastruktur yang ada, Anda dapat menambahkannya ke file status menggunakan perintah terraform import. Dengan cara ini Terraform akan mengetahui infrastruktur apa yang perlu dikelola. Perintah import membutuhkan dua argumen. Yang pertama adalah alamat sumber daya di file konfigurasi Anda. Sintaksnya di sini sama dengan tautan sumber daya: _. (seperti aws_iam_user.existing_user). Argumen kedua adalah ID sumber daya yang akan diimpor. Katakanlah ID sumber daya aws_iam_user adalah nama pengguna (misalnya, yevgeniy.brikman), dan ID sumber daya aws_instance adalah ID server EC2 (seperti i-190e22e5). Cara mengimpor sumber daya biasanya ditunjukkan dalam dokumentasi di bagian bawah halamannya.

  Di bawah ini adalah perintah impor yang menyinkronkan sumber daya aws_iam_user yang Anda tambahkan ke konfigurasi Terraform bersama dengan pengguna IAM di Bab 2 (tentu saja mengganti nama Anda dengan yevgeniy.brikman):

  $ terraform import aws_iam_user.existing_user yevgeniy.brikman

  Terraform akan memanggil API AWS untuk menemukan pengguna IAM Anda dan membuat asosiasi file status antara pengguna tersebut dan sumber daya aws_iam_user.existing_user di konfigurasi Terraform Anda. Mulai sekarang, saat Anda menjalankan perintah plan, Terraform akan mengetahui bahwa pengguna IAM sudah ada dan tidak akan mencoba membuatnya lagi.

  Perlu diperhatikan bahwa jika Anda sudah memiliki banyak sumber daya yang ingin diimpor ke Terraform, menulis kode secara manual dan mengimpornya satu per satu dapat merepotkan. Jadi ada baiknya mencari alat seperti Terraforming (http://terraforming.dtan4.net/), yang dapat secara otomatis mengimpor kode dan status dari akun AWS Anda.

  Refactoring mungkin mempunyai kelemahan

  Pemfaktoran ulang adalah praktik umum dalam pemrograman di mana Anda mengubah struktur internal kode sambil membiarkan perilaku eksternal tidak berubah. Hal ini untuk membuat kode lebih jelas, rapi, dan mudah dipelihara. Refactoring adalah teknik yang sangat diperlukan yang harus digunakan secara teratur. Namun jika menyangkut Terraform atau alat IaC lainnya, Anda harus sangat berhati-hati dengan apa yang Anda maksud dengan "perilaku eksternal" dari sebuah kode, jika tidak, masalah yang tidak terduga akan muncul.

  Misalnya, jenis pemfaktoran ulang yang umum adalah mengganti nama variabel atau fungsi dengan nama yang lebih mudah dipahami. Banyak IDE yang memiliki dukungan bawaan untuk pemfaktoran ulang dan dapat secara otomatis mengganti nama variabel dan fungsi di seluruh proyek. Dalam bahasa pemrograman tujuan umum, ini adalah prosedur sepele yang mungkin tidak Anda pikirkan, tetapi di Terraform Anda harus sangat berhati-hati dengan hal ini, jika tidak, Anda mungkin mengalami pemadaman listrik.

  Misalnya, modul cluster-server web memiliki variabel input cluster_name:

  variable "cluster_name" {
     description = "The name to use for all the cluster resources"
     type          = string
  }

  Bayangkan Anda mulai menggunakan modul ini untuk menerapkan layanan mikro bernama foo. Nanti, Anda ingin mengganti nama layanan Anda menjadi bar. Perubahan ini mungkin terlihat sepele, namun kenyataannya dapat menyebabkan gangguan layanan.

  Faktanya adalah modul cluster-server web menggunakan variabel cluster_name di sejumlah sumber daya, termasuk parameter nama dari dua grup keamanan dan ALB:

  resource "aws_lb" "example" {
     name                    = var.cluster_name
     load_balancer_type = "application"
     subnets = data.aws_subnet_ids.default.ids
     security_groups      = [aws_security_group.alb.id]
  }

  Jika Anda mengubah parameter nama pada sumber daya, Terraform akan menghapus versi lama sumber daya tersebut dan membuat versi baru sebagai gantinya. Namun jika sumber daya tersebut adalah ALB, antara menghapusnya dan mengunduh versi baru, Anda tidak akan memiliki mekanisme untuk mengarahkan lalu lintas ke server web Anda. Demikian pula, jika grup keamanan dihapus, server Anda akan mulai menolak lalu lintas jaringan apa pun hingga grup baru dibuat.

  Jenis pemfaktoran ulang lain yang mungkin Anda minati adalah mengubah ID Terraform. Mari kita ambil sumber daya aws_security_group di modul webserver-cluster sebagai contoh:

  resource "aws_security_group" "instance" {
    # (...)
  }

  Pengidentifikasi sumber daya ini disebut instance. Bayangkan selama pemfaktoran ulang Anda memutuskan untuk mengubahnya ke nama yang lebih mudah dipahami (menurut Anda) cluster_instance:

  resource "aws_security_group" "cluster_instance" {
     # (...)
  }

  Apa yang akan terjadi pada akhirnya? Itu benar: gangguan.

  Terraform mengaitkan setiap ID sumber daya dengan ID penyedia cloud. Misalnya, iam_user dikaitkan dengan ID pengguna AWS IAM, dan aws_instance dikaitkan dengan ID server AWS EC2. Jika Anda mengubah ID sumber daya (misalnya dari instance ke cluster_instance, seperti halnya aws_security_group), ke Terraform akan tampak seolah-olah Anda menghapus sumber daya lama dan menambahkan yang baru. Jika Anda menerapkan perubahan ini, Terraform akan menghapus grup keamanan lama dan membuat yang baru, sementara server Anda mulai menolak lalu lintas jaringan apa pun.

  Berikut empat pelajaran utama yang harus Anda ambil dari diskusi ini.

  • Selalu gunakan perintah rencana. Itu bisa mengungkap semua hambatan ini. Tinjau keluarannya dengan cermat dan perhatikan situasi ketika Terraform berencana menghapus sumber daya yang kemungkinan besar tidak boleh dihapus.
  • Buat sebelum Anda menghapus. Jika Anda ingin mengganti sumber daya, pikirkan baik-baik apakah Anda perlu membuat pengganti sebelum menghapus sumber daya asli. Jika jawabannya ya, create_before_destroy dapat membantu. Hasil yang sama dapat dicapai secara manual dengan melakukan dua langkah: pertama tambahkan sumber daya baru ke konfigurasi dan jalankan perintah terapkan, lalu hapus sumber daya lama dari konfigurasi dan gunakan kembali perintah terapkan.
  • Mengubah pengidentifikasi memerlukan perubahan status. Jika Anda ingin mengubah ID yang terkait dengan sumber daya (misalnya, mengganti nama aws_security_group dari instance menjadi cluster_instance) tanpa menghapus sumber daya dan membuat versi baru, Anda harus memperbarui file status Terraform yang sesuai. Jangan pernah melakukan ini secara manual - gunakan perintah terraform state sebagai gantinya. Saat mengganti nama pengidentifikasi, Anda harus menjalankan perintah terraform state mv, yang memiliki sintaks berikut:

    terraform state mv <ORIGINAL_REFERENCE> <NEW_REFERENCE>

    ASLI_REFERENCE adalah ekspresi yang mengacu pada sumber daya dalam bentuknya saat ini, dan NEW_REFERENCE adalah tempat Anda ingin memindahkannya. Misalnya, saat mengganti nama grup aws_security_group dari instans menjadi cluster_instance, Anda perlu menjalankan perintah berikut:

    $ terraform state mv 
       aws_security_group.instance 
       aws_security_group.cluster_instance

    Hal ini memberitahu Terraform bahwa keadaan yang sebelumnya dikaitkan dengan aws_security_group.instance sekarang harus dikaitkan dengan aws_security_group.cluster_instance. Jika setelah mengganti nama dan menjalankan perintah ini, terraform plan tidak menunjukkan perubahan apa pun, maka Anda melakukan semuanya dengan benar.

  • Beberapa pengaturan tidak dapat diubah. Parameter dari banyak sumber daya tidak dapat diubah. Jika Anda mencoba mengubahnya, Terraform akan menghapus sumber daya lama dan membuat sumber daya baru sebagai gantinya. Setiap halaman sumber daya biasanya menunjukkan apa yang terjadi ketika Anda mengubah pengaturan tertentu, jadi pastikan untuk memeriksa dokumentasinya. Selalu gunakan perintah plan dan pertimbangkan untuk menggunakan strategi create_before_destroy.

  Konsistensi yang ditangguhkan konsisten... dengan penundaan

  API beberapa penyedia cloud, seperti AWS, bersifat asinkron dan memiliki konsistensi yang tertunda. Asynchrony berarti antarmuka dapat segera mengembalikan respons tanpa menunggu tindakan yang diminta selesai. Konsistensi yang tertunda berarti bahwa perubahan mungkin memerlukan waktu untuk diterapkan ke seluruh sistem; saat hal ini terjadi, respons Anda mungkin tidak konsisten dan bergantung pada replika sumber data mana yang merespons panggilan API Anda.

  Bayangkan, misalnya, Anda melakukan panggilan API ke AWS yang memintanya untuk membuat server EC2. API akan mengembalikan respons "berhasil" (201 Dibuat) hampir seketika, tanpa menunggu server itu sendiri dibuat. Jika Anda mencoba menyambungkannya segera, hampir pasti akan gagal karena pada saat itu AWS masih menginisialisasi sumber daya atau, alternatifnya, server belum melakukan booting. Terlebih lagi, jika Anda melakukan panggilan lain untuk mendapatkan informasi tentang server ini, Anda mungkin menerima pesan kesalahan (404 Not Found). Masalahnya adalah informasi tentang server EC2 ini mungkin masih disebarkan ke seluruh AWS sebelum tersedia di mana-mana, Anda harus menunggu beberapa detik.

  При каждом использовании асинхронного API с отложенной согласованностью вы должны периодически повторять свой запрос, пока действие не завершится и не распространится по системе. К сожалению, AWS SDK не предоставляет для этого никаких хороших инструментов, и проект Terraform раньше страдал от множества ошибок вроде 6813 (https://github.com/hashicorp/terraform/issues/6813):

  $ terraform apply
  aws_subnet.private-persistence.2: InvalidSubnetID.NotFound:
  The subnet ID 'subnet-xxxxxxx' does not exist

  Dengan kata lain, Anda membuat sumber daya (seperti subnet) dan kemudian mencoba mendapatkan beberapa informasi tentangnya (seperti ID subnet yang baru dibuat), dan Terraform tidak dapat menemukannya. Sebagian besar bug ini (termasuk 6813) telah diperbaiki, namun bug tersebut masih muncul dari waktu ke waktu, terutama saat Terraform menambahkan dukungan untuk jenis sumber daya baru. Ini menjengkelkan, namun dalam banyak kasus tidak menimbulkan bahaya apa pun. Saat Anda menjalankan terraform apply lagi, semuanya akan berfungsi, karena saat ini informasi sudah menyebar ke seluruh sistem.

  Kutipan ini disajikan dari buku karya Evgeniy Brikman "Terraform: infrastruktur pada tingkat kode".

Sumber: www.habr.com