Pertanyaan-pertanyaan mengenai struktur kode Terraform sejauh ini merupakan hal yang paling sering ditemukan di dalam komunitas. Semua orang akan berpikir mengenai struktur kode terbaik untuk proyek mereka pada satu titik.

Bagaimana sebaiknya menstrukturkan konfigurasi Terraform?

Banyak jawaban yang tersedia untuk pertanyaan di atas dan sangat sulit untuk memberikan saran yang bersifat universal. Maka dari itu mari kita mulai dengan pemahaman terhadap apa yang sedang kita hadapi.

• Bagaimana tingkat kompleksitas dari proyek Anda?

  • Jumlah dari sumber daya yang terhubung

  • Jumlah dari penyedia Terraform (Lihat catatan di bawah mengenai penyedia-penyedia logis)

Memulai penstrukturan konfigurasi Terraform

Meletakan seluruh kode di dalam berkas main.tf merupakan ide yang baik ketika Anda baru memulai atau ketika menulis contoh kode. Pada kasus-kasus lainnya, Anda sebaiknya memisahkan konfigurasi secara logis ke dalam beberapa berkas sebagai berikut:

• main.tf - berisi modul-modul, locals, dan sumber data-sumber data untuk menciptakan seluruh sumber daya.

• variables.tf - berisi deklarasi variabel-variabel yang digunakan pada main.tf

terraform.tfvars sebaiknya tidak digunakan kecuali pada

Bagaimana cara pikir tentang struktur konfigurasi Terraform?

Rekomendasi umum struktur kode

• Lebih mudah dan lebih cepat bekerja dengan jumlah sumber daya yang lebih sedikit

  • terraform plan dan terraform apply keduanya memanggil API komputasi awan untuk memverifikasi status sumber daya

Di dalam buku ini, contoh proyek dikelompokan berdasarkan kompleksitas - dari infrastruktur yang kecil sampai sangat besar. Pemisahan ini tidak bersifat mutlak, jadi periksa juga struktur-struktur lainnya.

Orkestrasi modul infrastruktur dan komposisi

Memiliki infrastruktur skala kecil sama artinya dengan memiliki jumlah dependensi dan sumber daya yang sedikit. Seiring berkembangnya proyek maka kebutuhan untuk mengeksekusi konfigurasi Terraform secara berantai akan semakin jelas keliatan. Selain itu, kebutuhan untuk menghubungan modul-modul infrastruktur yang berbeda dan menyampaikan nilai di dalam komposisi menjadi semakin jelas juga.

Setidaknya ada 5 group solusi orkestrasi yang berbeda yang bisa digunakan oleh pengembang:

• Hanya Terraform. Sangat lugas, pengembang hanya perlu mengetahui Terraform untuk menyelesaikan pekerjaan.

• Terragrunt. Alat orkestrasi murni yang bisa digunakan untuk mengorkestrasi keseluruhan infrastruktur dan juga dependensinya. Terragrunt beroperasi dengan modul infrastruktur dan komposisi secara asli. Hal ini mengurangi jumlah duplikasi kode.

• Berkas buatan sendiri. Seringkali hal ini terjadi sebagai titik awal menuju orkestrasi dan sebelum menemukan Terragrunt.

Berdasarkan hal yang dijelaskan di atas, buku ini mengulas dua hal pertama dari solusi orkestrasi proyek yaitu hanya Terraform dan Terragrunt.

Lihat contoh struktur kode untuk atau pada bab selanjutnya.

Dokumentasi ofisial Terraform menjabarkan seluruh aspek konfigurasi secara detail. Bacalah secara seksama untuk memahami sisa dari bagian ini.

Bagian ini menjabarkan konsep-konsep dasar yang digunakan pada buku ini.

Sumber daya (resource)

Contoh dari sumber daya pada Terraform adalah aws_vpc, aws_db_instance, dan lain sebagainya. Sumber daya merupakan bagian dari penyedia (provider), menerima argumen-argumen, mengeluarkan atribut-atribut, dan memiliki siklus hidup. Sumber daya dapat diciptakan, diambil, diperbarui, dan dihapus.

Modul sumber daya

Modul sumber daya adalah sekumpulan sumber daya yang terhubung secara bersamaan untuk mencapai tujuan tertentu. Contohnya adalah . Modul ini menciptakan VPC, subnet, dan pintu gerbang NAT (NAT gateway). Modul sumber daya bergantung pada konfigurasi penyedia yang bisa didefinisikan pada module itu sendiri atau pada struktur lain yang lebih tinggi levelnya.

Modul infrastruktur

Modul infrastruktur adalah sekumpulan modul sumber daya yang mungkin saja tidak terhubung secara logis, tetapi memiliki fungsi yang sama pada situasi/proyek/susunan saat ini. Modul infrastruktur mendefinisikan konfigurasi penyedia-penyedia yang akan dialirkan ke modul-modul sumber daya dan sumber daya yang ada di hilir. Modul infrastruktur umumnya bekerja secara terbatas pada satu entitas yang terpisah secara logis. Contohnya wilayah AWS, atau proyek Google.

Kita ambil modul sebagai contoh. Modul ini menggunakan modul-modul sumber daya lain seperti dan untuk mengelola infrastruktur yang dibutuhkan dalam menjalankan pada .

Contoh lainnya adalah modul . Pada modul ini terdapat berbagai modul lain berasal dari yang digunakan secara bersamaan untuk mengelola infrastruktur. Selain itu module ini juga menggunakan sumber daya Docker untuk membangun, mendorong, dan mengelar gambar-gambar (image) Docker. Semuanya ada di dalam satu paket.

Komposisi

Komposisi adalah sekumpulan modul infrastruktur yang mencakup berbagai area yang terpisah secara logis (Contoh wilayah AWS, beberapa akun AWS). Komposisi digunakan untuk menjabarkan secara penuh infrastruktur yang dibutuhkan oleh seluruh organisasi atau proyek.

Komposisi terdiri dari modul-modul infrastruktur yang di dalamnya berisi modul-modul sumber daya yang pada hakikatnya berisi sumber daya - sumber daya individu.

Sumber data (data source)

Sumber data hanya melakukan operasi baca (read-only) dan bergantung pada konfigurasi penyedia. Sumber data digunakan oleh modul sumber daya dan modul infrastruktur.

Sumber data terraform_remote_state bertindak sebagai perekat untuk modul-modul dan komposisi-komposisi tingkat tinggi.

Sumber data memungkinkan program lain untuk bertindak sebagai sumber data, mengekspos data arbitrer untuk digunakan di tempat lain di dalam konfigurasi Terraform. Kita ambil contoh modul . Pada modul ini nama berkas dikomputasi dengan cara memanggil naskah Python eksternal.

Sumber data mengirimkan permintaan HTTP GET ke target URL dan mengekspor informasi seputar respons dari permintaan tersebut. Sumber data ini berguna untuk mendapatkan informasi dari titik akhir ketika tidak tersedianya penyedia asli Terraform untuk berkomunikasi dengan titik akhir tersebut.

Keadaan jarak jauh

Modul-modul infrastruktur dan komposisi-komposi sebaiknya menyimpan di lokasi jarak jauh dimana keadaan tersebut bisa diambil oleh pihak lain secara terkontrol (Misal dengan adanya ACL, pembuatan versi, dan pembuatan catatan).

Penyedia, pengada, dan lain-lain

Penyedia, pengada, dan beberapa istilah lainnya dijabarkan dengan baik pada dokumentasi resmi dan tidak ada gunanya dijabarkan ulang di sini. Menurut pendapat penulis, mereka tidak begitu berguna dalam kaitannya untuk menulis modul Terraform yang baik.

Kok susah ya?

Ketika sumber daya - sumber daya individu diandaikan seperti atom di infrastruktur, maka modul sumber daya adalah molekul. Modul adalah unit terkecil yang dapat diversikan dan dibagikan. Modul memiliki daftar argumen yang tepat dan mengimplementasi logik dasar untuk unit tersebut sehingga dapat menjalankan fungsinya. Contohnya adalah modul . Modul ini menciptakan sumber daya aws_security_group dan aws_security_group_rule berdasarkan masukan yang diberikan. Modul sumber daya ini sendiri bisa digunakan bersamaan dengan modul-modul lain untuk menciptakan modul infrastruktur.

Akses terhadap data lintas molekul (modul sumber daya dan infrastruktur) dilakukan menggunakan keluaran modul dan sumber data.

Akses antar komposisi seringkali dilakukan menggunakan sumber data jarak jauh. Ada .

Berikut contoh penjabaran konsep di atas dalam hubungan semu:

Berikut daftar artikel yang ada di bagian ini:

Terraform merupakan sebuah proyek (sebagaimana banyaknya alat-alat DevOps lainnya) yang relatif baru yang dimulai pada tahun 2014.

Terraform adalah alat yang ampuh (mungkin alat yang paling ampuh di luar sana saat ini) dan merupakan alat yang paling banyak digunakan untuk mengelola infrastruktur sebagai kode (Infrastructure as Code/IaC). Terraform memungkin pengembang untuk melakukan banyak hal dan tidak membatasi mereka melakukannya dengan cara yang akan sulit untuk didukung atau diintegrasi dengan sistem lain.

Beberapa informasi yang dijabarkan pada buku ini mungkin tampak tidak seperti praktik terbaik. Ini merupakan hal yang lumrah. Untuk membantu pembaca memisahkan antara praktik terbaik yang telah teruji atau cara dogmatis lainnya untuk melakukan hal yang sama, penulis sesekali menggunakan petunjuk untuk menyediakan konteks dan ikon-ikon untuk menentukan level kematangan dari setiap subbagian yang terkait dengan praktik terbaik.

Buku ini mulai ditulis di Madrid yang cerah pada tahun 2018. Buku ini tersedia secara gratis di https://www.terraform-best-practices.com/

Beberapa tahun kemudian buku ini telah diperbarui dengan konten praktik terbaik dari Terraform versi 1.0. Pada akhirnya, buku ini akan berisi sebagian besar dari praktik terbaik dan rekomendasi yang tidak terbantahkan bagi para pengguna Terraform.

Sponsor

Please if you want to become a sponsor.

Alih bahasa

Hubungi penulis jika Anda ingin membantu menerjemahkan buku ini ke dalam bahasa lainnya.

Kontribusi

Penulis ingin selalu mendapat umpan balik dan masukan terhadap buku ini sebagai komunitas yang matang dan ide-ide baru diimplementasikan dan diverifikasi dari waktu ke waktu.

Jika Anda tertarik pada topik tertentu, silakan atau acungkan jempol Anda pada isu yang paling ingin masuk cakupan. Jika Anda mempunyai konten dan Anda ingin berkontribusi, tulis draf dan kirimkan permintaan penarikan/pull request (Tidak perlu khawatir soal penulisan naskah yang baik pada titik ini)

Penulis

Buku ini dikelola oleh dengan bantuan dari berbagai kontributor dan pengalih bahasa.

Lisensi

Tulisan ini menggunakan lisensi Apache 2. Lihat berkas LICENSE untuk detail penuh.

Penulis dan kontributor konten ini tidak memberikan garansi akan validitas informasi yang ada di dalam tulisan ini. Pastikan Anda mengerti bahwa informasi yang disediakan pada tulisan ini bersifat gratis, dan tidak ada perjanjian atau kontrak yang dibuat antara Anda dan orang-orang yang terkait dengan konten atau proyek ini. Penulis dan kontributor tidak bertanggung jawab terhadap pihak manapun atas kerugian, kerusakan, dan gangguan yang ditimbulkan akibat kesalahan atau kelalaian informasi yang terkandung, terkait, ataupun dihubungan pada konten ini. Baik itu kesalahan atau kelalaian yang bersumber pada kelalaian, kecelakaan, atau penyebab-penyebab lainnya.

Hak cipta © 2018-2023 Anton Babenko.

https://twitter.com/antonbabenko/lists/terraform-experts - Daftar orang yang bekerja dengan Terraform secara aktif dan dapat memberitahu banyak hal (tentunya jika Anda bertanya kepada mereka).

https://github.com/shuaibiyy/awesome-terraform - Daftar terkurasi dari sumber daya pada Hashicorp Terraform.

http://bit.ly/terraform-youtube - "Your Weekly Dose of Terraform" Kanal YouTube milik Anton Babenko. Siaran langung dengan ulasan, wawancara, tanya jawab, memprogram langsung, dan utak-atik menggunakan Terraform.

- Nawala mingguan Terraform. Berbagai berita di dunia Terraform (proyek, pengumuman, diskusi) oleh Anton Babenko.

Sumber: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/medium-terraform

Contoh di atas berisi kode sebagai ilustrasi struktur konfigurasi Terraform untuk infrastruktur dengan ukuran medium yang menggunakan hal berikut:

• 2 buah akun AWS

• 2 lingkungan yang berbeda (prod dan stage yang tidak berbagi apa pun). Setiap lingkungan hidup di dalam akun AWS yang berbeda.

• Setiap lingkungan menggunakan versi yang berbeda dari modul infrastruktur siap pakai (alb) yang berasal dari

• Setiap lingkungan menggunakan versi yang sama dari modul internal modules/network yang bersumber dari direktori lokal.

Sumber: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/large-terraform

Contoh di atas berisi kode sebagai ilustrasi struktur konfigurasi Terraform untuk infrastruktur ukuran besar yang mengandung hal berikut:

• 2 akun AWS

• 2 wilayah

• 2 lingkungan terpisah (prod dan stage yang tidak berbagi apa pun). Setiap lingkungan hidup di akun yang berbeda dan menjangkau sumber daya di 2 wilayah

• Setiap lingkungan menggunakan versi yang berbeda dari modul infrastruktur siap pakai (alb) yang berasal dari

• Setiap lingkungan menggunakan versi yang sama dari modul internal modules/network yang bersumber dari direktori lokal.

Gunakan locals untuk menetapkan dependensi antar sumber daya secara eksplisit

Hal ini merupakan cara yang baik untuk memberi petunjuk kepada Terraform bahwa beberapa sumber daya seharusnya dihapus terlebih dahulu bahkan ketika tidak ada dependensi langsung di dalam konfigurasi Terraform.

https://raw.githubusercontent.com/antonbabenko/terraform-best-practices/master/snippets/locals.tf

Terraform 0.12 - Argumen wajib dan pilihan

1. Argumen wajib index_document harus diisi jika var.website bukanlah map kosong

2. Argumen pilihan error_document bisa diabaikan

Struktur kode Terraform

Alat-alat apa saja yang sebaiknya diketahui dan dipertimbangkan untuk digunakan?

• - Tool orkestrasi

Berikut ini adalah lokakarya untuk orang-orang yang ingin mempraktikan hal-hal yang dijabarkan pada panduan ini.

Konten tersedia pada - https://github.com/antonbabenko/terraform-best-practices-workshop

Dokumentasi

Dokumentasi secara otomatis

merupakan kerangka kerja untuk mengelola dan memelihara kait pre-commit multi bahasa. Pre-commit ditulis dalam bahasa Python dan merupakan alat ampuh untuk melakukan sesuatu secara otomatis pada mesin pengembang sebelum kode disimpan pada repositori git. Umumnya alat ini digunakan untuk menjalankan linter dan memformat kode (Lihat ).

Kita bisa menggunakan pre-commit untuk memformat dan memvalidasi konfigurasi Terraform dan juga untuk memperbarui dokumentasi.

Periksa untuk membiasakan diri Anda akan penggunaan pre-commit untuk Terraform. Beberapa repositori seperti sudah menggunakan pre-commit.

terraform-docs

merupakan alat untuk menciptakan dokumentasi modul Terraform dalam berbagai format keluaran. Kita dapat menjalankan terraform-docs secara manual (tanpa kait pre-commit) atau via untuk memperbarui dokumentasi secara otomatis.

@todo: Dokumentasikan versi modul, rilis, dan GH actions

Sumber daya

3. Tulisan blog oleh :

Sumber: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/small-terraform

Contoh ini mengandung kode sebagai ilustrasi dari struktur konfigurasi Terraform untuk infrastruktur berukuran kecil dimana tidak ada dependensi eksternal di dalamnya.

Kaidah umum

1. Gunakan _ (garis bawah) daripada - (tanda hubung) dimana saja (nama sumber daya, nama sumber data, nama variabel, keluaran, dan lain-lain)

2. Pilihlah penggunaan huruf kecil dan angka (walaupun ada dukungan UTF-8)

Argumen sumber daya dan sumber data

1. Hindari mengulang jenis sumber daya pada nama sumber daya (baik itu sebagian atau sepenuhnya):

   resource "aws_route_table" "public" {}

Contoh kode resource

Penggunaan count / for_each

Penempatan tags

Pernyataan bersyarat count

Variabel

1. Hindari membuat ulang secara mandiri (don't reinvent the wheel) pada modul sumber daya: gunakan name, description, dan nilai default untuk variabel seperti yang didefinisikan pada bagian "Referensi Argumen" untuk sumber daya yang Anda kerjakan.

2. Dukungan untuk validasi variabel bersifat terbatas (Contoh tidak bisa mengakses variabel lain atau melakukan pencarian). Buat perencanaan validasi dengan baik karena fitur ini tidak bisa digunakan pada beberapa kasus tertentu.

Keluaran

Buat keluaran konsisten dan mudah dipahami diluar cakupan mereka (Tipe dan atribut dari nilai yang dikembalikan harus jelas bagi pengguna modul ketika menggunakan modul tersebut).

1. Nama keluaran sebaiknya menjelaskan properti yang dimiliki dan tidak terlalu menggunakan bentuk bebas yang biasa kita inginkan.

2. Struktur yang baik untuk nama keluaran berbentuk {name}_{type}_{attribute}, dimana:

   1. {name}

Contoh kode output

Kembalikan paling banyak satu ID dari security group::

Ketika bekerja dengan banyak sumber daya berjenis sama, this sebaiknya diabaikan dari nama keluaran:

Gunakan bentuk jamak jika mengembalikan nilai yang berupa daftar