Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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.
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 |
---|---|---|
Sumber:
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 )
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)
Berikut daftar artikel yang ada di bagian ini:
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
Compliance.tf — Terraform Compliance Simplified. Make your Terraform modules compliance-ready.
—
Sumber:
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.
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.
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.
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
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.
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)
Seberapa sering infrastruktur Anda berubah?
Dari sekali sebulan/seminggu/sehari
Sampai secara terus-menerus (setiap kali ada commit baru)
Inisiator perubahan kode? Apakah Anda memperbolehkan server CI memperbarui repositori ketika artifak baru dibangun?
Hanya para pengembang yang boleh mendorong ke dalam repositori infrastruktur
Semua orang bisa mengajukan perubahan terhadap segala sesuatu dengan membuka PR (termasuk tugas-tugas otomatis yang berjalan di server CI)
platform atau layanan penggelaran mana yang Anda gunakan?
AWS CodeDeploy, Kubernetes, atau OpenShift membutuhkan pendekatan yang berbeda
Bagaimana lingkungan dikelompokan?
Berdasarkan lingkungan, wilayah, proyek
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
outputs.tf
- berisi keluaran-keluaran dari sumber daya - sumber daya yang diciptakan pada main.tf
versions.tf
- berisi persyaratan versi untuk Terraform dan penyedia
terraform.tfvars
sebaiknya tidak digunakan kecuali pada komposisi
Pastikan Anda paham konsep-konsep dasar - modul sumber daya, modul infrastruktur, dan komposisi, karena konsep-konsep tersebut digunakan pada contoh-contoh berikut.
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
Jika seluruh infrastruktur Anda berada di dalam satu komposisi maka hal ini akan membuat operasi Terraform memakan waktu yang lama
Radius ledakan menjadi lebih kecil dengan sumber daya yang lebih sedikit
Mengisolasi sumber daya yang tidak saling berkaitan dengan cara meletakan mereka di komposisi yang berbeda mengurangi resiko ketika terjadi kesalahan
Mulai proyek Anda dengan menggunakan keadaan jarak jauh karena:
Laptop Anda bukanlah tempat sumber kebenaran infrastruktur Anda
Mengelola berkas tfstate
di dalam git merupakan mimpi buruk
Ketika nantinya lapisan-lapisan infrastruktur mulai berkembang ke berbagai arah (jumlah dependensi atau sumber daya) maka akan lebih mudah bagi Anda untuk mengontrolnya
Praktikan aturan penamaan dan struktur yang konsisten:
Seperti kode prosedural, kode Terraform sebaiknya ditulis dengan prinsip bawha kode akan dibaca oleh orang lain. Konsistensi akan membantu ketika perubahan terjadi di masa yang akan datang
Bukanlah hal yang mustahil untuk memindahkan sumber daya pada berkas keadaan Terraform. Tetapi hal tersebut mungkin sulit dilakukan jika Anda memiliki penamaan dan struktur yang tidak konsisten.
Jaga modul-modul sumber daya sesederhana mungkin
Jangan gunakan nilai kode keras (hard-coded) untuk nilai yang bisa diberikan sebagai variabel atau ditemukan menggunakan sumber data
Gunakan sumber data dan terraform_remote_state
secara khusus sebagai perekat antar modul infrastruktur di dalam komposisi
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.
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.
Ansible atau alat otomatisasi umum lainnya. Umumnya digunakan ketika Terraform diadopsi setelah Ansible atau ketika Ansible UI digunakan secara aktif.
Crossplane dan solusi lainya yang terinspirasi dari Kubernetes. Kadangkala, merupakan hal yang masuk akal untuk menggunakan ekosistem Kubernetes dan mempekerjakan fitur lingkaran rekonsiliasi untuk mencapai keadaan yang diinginkan dari konfigurasi Terraform. Tonton video Crossplane vs Terraform untuk informasi lebih lanjut.
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 Terraform atau Terragrunt pada bab selanjutnya.
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 modul AWS VPC 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