Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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.
Sangat cocok untuk permulaan dan direstruktur seiring waktu
Sangat cocok untuk modul sumber daya kecil
Bagus untuk modul infrastruktur kecil dan linier (Contoh terraform-aws-atlantis)
Bagus untuk sumber daya ukuran kecil (lebih sedikit jumlahnya dari 20-30)
Berkas keadaan tunggal untuk semua sumber daya dapat memperlambat proses bekerja dengan Terraform bila jumlah dari sumber daya terus meningkat (Pertimbangkan untuk menggunakan argumen-target
untuk membatasi jumlah sumber daya)
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 Terraform Registry
Setiap lingkungan menggunakan versi yang sama dari modul internal modules/network
yang bersumber dari direktori lokal.
Pada proyek besar seperti yang dijabarkan di atas, manfaat dari penggunaan Terragrunt menjadi sangat jelas. Lihat Contoh struktur kode pada Terragrunt .
Sangat cocok untuk proyek dengan infrastruktur yang terpisah secara logis (akun AWS berbeda)
Cocok ketika tidak ada kebutuhan untuk mengubah sumber daya bersama antar akun AWS (satu lingkungan = satu akun AWS = satu berkas keadaan)
Bagus ketika tidak ada kebutuhan mengorkestrasi perubahan antar lingkungan
Bagus ketika sumber daya infrastruktur sengaja dibedakan untuk setiap lingkungan dan tidak bisa digeneralisasi (Contoh beberapa sumber daya tidak ada di satu lingkungan atau beberapa wilayah)
Seiring berkembangnya proyek, akan menjadi lebih sulit untuk menjaga supaya lingkungan-lingkungan tersebut mutakhir. Pertimbangkan untuk menggunakan modul infrastruktur (siap pakai atau internal) untuk pekerjaan yang berulang.
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 Terraform Registry
Setiap lingkungan menggunakan versi yang sama dari modul internal modules/network
yang bersumber dari direktori lokal.
Sangat cocok untuk proyek dengan infrastruktur yang terpisah secara logis (Akun AWS yang berbeda)
Cocok ketika tidak ada kebutuhan untuk mengubah sumber daya bersama antar akun AWS (satu lingkungan = satu akun AWS = satu berkas keadaan)
Bagus ketika tidak ada kebutuhan mengorkestrasi perubahan antar lingkungan
Bagus ketika sumber daya infrastruktur sengaja dibedakan untuk setiap lingkungan dan tidak bisa digeneralisasi (Contoh beberapa sumber daya tidak ada di satu lingkungan atau beberapa wilayah)
Seiring berkembangnya proyek, akan menjadi lebih sulit untuk menjaga supaya lingkungan-lingkungan tersebut mutakhir. Pertimbangkan untuk menggunakan modul infrastruktur (siap pakai atau internal) untuk pekerjaan yang berulang.
Contoh dan modul Terraform sebaiknya disertai dengan dokumentasi yang menjelaskan fitur-fitur dan cara penggunaannya.
Semua tautan pada berkas README.md sebaiknya menggunakan tautan absolut sehingga tautan akan ditampilkan dengan benar pada halaman Terraform Registry.
Dokumentasi bisa diisi dengan diagram yang dibuat menggunakan mermaid dan cetak biru buatan cloudcraft.co.
Gunakan kait-kait pre-commit Terraform untuk memastikan kode valid, diformat dengan benar, dan terdokumentasi secara otomatis sebelum dikirim ke git dan ditinjau oleh orang lain.
pre-commit 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 kait yang didukung).
Kita bisa menggunakan pre-commit
untuk memformat dan memvalidasi konfigurasi Terraform dan juga untuk memperbarui dokumentasi.
Periksa repository pre-commit-terraform untuk membiasakan diri Anda akan penggunaan pre-commit untuk Terraform. Beberapa repositori seperti terraform-aws-vpc 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 kait pre-commit-terraform untuk memperbarui dokumentasi secara otomatis.
@todo: Dokumentasikan versi modul, rilis, dan GH actions
Tulisan blog oleh Dean Wilson: pre-commit hooks and terraform - a safety net for your repositories
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.
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 adalah sekumpulan sumber daya yang terhubung secara bersamaan untuk mencapai tujuan tertentu. Contohnya adalah modul Terraform AWS VPC. 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 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 terraform-aws-atlantis sebagai contoh. Modul ini menggunakan modul-modul sumber daya lain seperti terraform-aws-vpc dan terraform-aws-security-group untuk mengelola infrastruktur yang dibutuhkan dalam menjalankan Atlantis pada AWS Fargate.
Contoh lainnya adalah modul terraform-aws-cloudquery. Pada modul ini terdapat berbagai modul lain berasal dari terraform-aws-modules 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 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 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 eksternal memungkinkan program lain untuk bertindak sebagai sumber data, mengekspos data arbitrer untuk digunakan di tempat lain di dalam konfigurasi Terraform. Kita ambil contoh modul terraform-aws-lambda. Pada modul ini nama berkas dikomputasi dengan cara memanggil naskah Python eksternal.
Sumber data http 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.
Modul-modul infrastruktur dan komposisi-komposi sebaiknya menyimpan keadaan Terraform 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 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.
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 terraform-aws-security-group. 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 beberapa cara untuk membagikan data antara konfigurasi.
Berikut contoh penjabaran konsep di atas dalam hubungan semu:
Contoh-contoh berikut menggunakan penyedia AWS tetapi sebagian besar prinsip yang digunakan pada contoh-contoh di bawah dapat diaplikasikan ke penyedia komputasi awan dan juga penyedia lainnya seperti DNS, Basis data, Pemantauan sistem, dan lain-lain.
Tipe | Deskripsi | Tingkat Kesiapan |
---|---|---|
Tipe | Deskripsi | Tingkat Kesiapan |
---|---|---|
Dokumen ini adalah upaya untuk menggambarkan secara sistematis praktik terbaik penggunaan Terraform dan menyediakan rekomendasi atas permasalahan yang sering kali dialami oleh pengguna Terraform.
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.
Please contact me if you want to become a sponsor.
Hubungi penulis jika Anda ingin membantu menerjemahkan buku ini ke dalam bahasa lainnya.
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 buat isu baru 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)
Buku ini dikelola oleh Anton Babenko dengan bantuan dari berbagai kontributor dan pengalih bahasa.
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.
Seharusnya tidak ada alasan untuk menolak mengikuti kaidah berikut :)
Sadarilah bahwa sumber daya awan seringkali memiliki keterbatasan tersendiri dalam pemberian nama. Sebagai contoh beberapa sumber daya tidak bisa menggunakan tanda hubung, atau harus menggunakan aturan penulisan huruf unta (camel case). Kaidah yang dimaksud dalam buku ini dimaksudkan untuk nama sumber daya Terraform itu sendiri.
Gunakan _
(garis bawah) daripada -
(tanda hubung) dimana saja (nama sumber daya, nama sumber data, nama variabel, keluaran, dan lain-lain)
Pilihlah penggunaan huruf kecil dan angka (walaupun ada dukungan UTF-8)
Hindari mengulang jenis sumber daya pada nama sumber daya (baik itu sebagian atau sepenuhnya):
resource "aws_route_table" "public" {}
resource "aws_route_table" "public_route_table" {}
resource "aws_route_table" "public_aws_route_table" {}
Sumber daya sebaiknya dinamakan this
jika tidak tersedia nama lain yang lebih deskriptif dan umum, atau jika modul sumber daya menciptakan sumber daya tunggal dari tipe tersebut. Sebagai contoh pada terdapat sebuah sumber daya dengan tipe aws_nat_gateway
dan beberapa sumber daya dengan tipe aws_route_table
. Maka dari itu sumber daya aws_nat_gateway
sebaiknya dinamakan this
dan aws_route_table
diberi nama yang lebih deskriptif seperti privat
, publik
, database
.
Selalu gunakan kata benda tunggal sebagai nama.
Gunakan -
pada nilai argumen dan ditempat-tempat lain dimana nilai akan dipaparkan ke orang lain (Contoh di dalam nama DNS sebuah RDS).
Letakan argumen count
/ for_each
pada baris pertama di dalam blok sumber daya atau sumber data dan tambahkan baris baru untuk memisahkan dengan argumen lainnya.
Letakan argumen tags
(jika sumber daya mendukung hal tersebut) sebagai argumen terakhir, diikuti oleh depends_on
dan lifecycle
jika diperlukan. Semua argumen tersebut sebaiknya dipisahkan oleh satu baris kosong.
Ketika menggunakan argumen count
/ for_each
sebagai pernyataan bersyarat, pilihlah nilai boolean dibandingkan length
atau ekspresi lainnya
count
/ for_each
tags
count
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.
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.
Gunakan bentuk jamak pada nama variabel dengan tipe list(...)
atau map(...)
.
Urutkan nama atribut di dalam blok variabel seperti berikut: description
, type
, default
, validation
Selalu sertakan description
disemua variabel walaupun menurut Anda hal tersebut sudah jelas (Anda akan membutuhkannya dimasa yang akan datang).
Pilihlah tipe-tipe sederhana (number
, string
, list(...)
, map(...)
, any
) daripada tipe yang lebih spesifik seperti object()
kecuali Anda memerlukan batasan ketat pada setiap atributnya.
Gunakan tipe spesifik seperti map(map(string))
jika seluruh elemen dari map
memiliki tipe yang sama (Contoh string
) atau bisa dikonversikan menjadi tipe tersebut (Contoh tipe number
bisa dikonversi menjadi string
).
Gunakan tipe any
untuk menonaktifkan validasi tipe mulai dari level tertentu atau ketika perlu mendukung berbagai tipe.
Nilai {}
bisa bertipe map
atau bisa juga bertipe object
. Gunakan tomap(...)
untuk konversi menjadi map karena tidak ada cara untuk mengubah menjadi object
.
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).
Nama keluaran sebaiknya menjelaskan properti yang dimiliki dan tidak terlalu menggunakan bentuk bebas yang biasa kita inginkan.
Struktur yang baik untuk nama keluaran berbentuk {name}_{type}_{attribute}
, dimana:
{name}
adalah nama sumber daya atau sumber data tanpa awalan penyedia. Sebagai contoh {name}
untuk aws_subnet
adalah subnet
, {name}
untuk aws_vpc
adalah vpc
.
{type}
adalah tipe dari sumber daya
{attribute}
adalah atribut dari nilai keluaran
Selalu sertakan description
untuk semua keluaran walaupun hal itu dirasa sudah jelas.
Hindari argumen sensitive
kecuali Anda mengontrol penuh penggunaan keluaran tersebut diseluruh tempat pada seluruh modul.
output
Kembalikan paling banyak satu ID dari security group::
Ketika bekerja dengan banyak sumber daya berjenis sama, this
sebaiknya diabaikan dari nama keluaran:
Berikut daftar artikel yang ada di bagian ini:
Ada banyak orang yang membuat konten bagus dan mengelola proyek sumber terbuka yang berkaitan dengan komunitas Terraform. Penulis berpendapat tidak ada struktur lain yang lebih baik untuk mendaftarkan tautan tanpa menyalin daftar seperti .
- Daftar orang yang bekerja dengan Terraform secara aktif dan dapat memberitahu banyak hal (tentunya jika Anda bertanya kepada mereka).
- Daftar terkurasi dari sumber daya pada Hashicorp Terraform.
- "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.
MUT (Masalah Umum Terraform)
- Tool orkestrasi
- Linter kode
- Pengelola versi
- Otomatisasi Pull Request
- Kumpan kait git untuk Terraform yang digunakan bersamaan dengan
Versi dari sumber daya dan modul infrastruktur sebaiknya menggunakan versi yang spesifik. Penyedia sebaiknya dikonfigurasi diluar modul tetapi hanya di dalam komposisi. Versi dari penyedia dan Terraform juga sebaiknya dikunci.
Tidak ada alat pengelola dependensi utama, tetapi ada beberapa tips untuk membuat dependensi menjadi lebih sedikit bermasalah. Sebagai contoh, bisa digunakan untuk mengotomatisasi perbaruan dependensi. Dependabot membuat permintaaan penarikan untuk menjaga dependensi tetap aman dan terbaru. Dependabot mendukung konfigurasi Terraform.
Lihat
Jika keluaran mengembalikan nilai dengan fungsi interpolasi dan banyak sumber daya maka {name}
dan {type}
sebaiknya dibuat seumum mungkin (this
sebagai prefiks sebaiknya diabaikan saja). Lihat .
Jika nilai kembalian adalah sebuah daftar maka gunakan bentuk jamak sebagai nama. Lihat .
Beberapa sumber daya, tanpa dependensi eksternal. Satu akun AWS. Satu wilayah. Lingkungan tunggal.
Ya
Beberapa lingkungan dan akun AWS, modul-modul infrastruktur siap pakai. Menggunakan Terraform.
Ya
Banyak akun AWS, banyak wilayah, kebutuhan yang mendesak untuk mengurangi salin tempel, modul infrastruktur pesanan, penggunaan komposisi kelas berat. Menggunakan Terraform.
Sedang dalam pengerjaan
Sangat besar
Beberapa penyedia (AWS, GCP, Azure). Penggelaran di banyak komputasi awan. Menggunakan Terraform.
Tidak
sedang
Beberapa akun AWS dan lingkungan, modul infrastruktur siap pakai, pola komposisi menggunakan Terragrunt.
Tidak
besar
Banyak akun AWS, banyak wilayah, kebutuhan mendesak untuk mengurangi salin tempel, penggunaan komposisi kelas berat. Menggunakan Terragrunt.
Tidak
sangat besar
Beberapa penyedia (AWS, GCP, Azure). Penggelaran di banyak komputasi awan. Menggunakan Terragrunt.
Tidak
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
locals
untuk menetapkan dependensi antar sumber daya secara eksplisitHal 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