Memahami status dan backend Terraform

Salah satu konsep terpenting dalam infrastruktur sebagai kode (IAc) adalah konsep negara. Layanan IAc mempertahankan status, yang memungkinkan Anda mendeklarasikan sumber daya dalam file IAc tanpa membuatnya ulang setiap kali Anda menerapkan. File IAC mendokumentasikan status semua sumber daya pada akhir penerapan sehingga kemudian dapat membandingkan status itu dengan status target, seperti yang dinyatakan dalam penerapan berikutnya. Jadi, jika status saat ini berisi bucket Amazon Simple Storage Service (Amazon S3) my-s3-bucket bernama Simple Storage Service (Amazon S3) dan perubahan yang masuk juga berisi bucket yang sama, proses baru akan menerapkan perubahan apa pun yang ditemukan pada bucket yang ada daripada mencoba membuat bucket baru.

Tabel berikut memberikan contoh proses status IAc umum.

Keadaan saat ini	Status target	Tindakan
Tidak ada ember S3 bernama my-s3-bucket	Ember S3 bernama my-s3-bucket	Buat bucket S3 bernama my-s3-bucket
my-s3-buckettanpa pembuatan versi bucket yang dikonfigurasi	my-s3-buckettanpa pembuatan versi bucket yang dikonfigurasi	Tidak ada tindakan
my-s3-buckettanpa pembuatan versi bucket yang dikonfigurasi	my-s3-bucketdengan pembuatan versi bucket yang dikonfigurasi	my-s3-bucketKonfigurasikan untuk memiliki versi bucket
my-s3-bucketdengan pembuatan versi bucket yang dikonfigurasi	Tidak ada ember S3 bernama my-s3-bucket	Mencoba untuk menghapus my-s3-bucket

Untuk memahami berbagai cara di mana AWS CloudFormation dan status trek Terraform, penting untuk mengingat perbedaan dasar pertama antara kedua alat: CloudFormation di-host di dalam AWS Cloud, dan Terraform pada dasarnya jarak jauh. Fakta ini memungkinkan CloudFormation untuk mempertahankan keadaan secara internal. Anda dapat pergi ke CloudFormation konsol dan melihat riwayat peristiwa dari tumpukan tertentu, tetapi CloudFormation layanan itu sendiri memberlakukan aturan status untuk Anda.

Tiga mode yang CloudFormation beroperasi di bawah untuk sumber daya tertentu adalahCreate,Update, danDelete. Mode saat ini ditentukan berdasarkan apa yang terjadi pada penerapan terakhir, dan tidak dapat dipengaruhi sebaliknya. Anda mungkin dapat memperbarui CloudFormation sumber daya secara manual untuk memengaruhi mode mana yang ditentukan, tetapi Anda tidak dapat meneruskan perintah CloudFormation yang mengatakan “Untuk sumber daya ini, operasikan dalam Create mode.”

Karena Terraform tidak di-host di AWS Cloud, proses pemeliharaan status harus lebih dapat dikonfigurasi. Untuk alasan ini, status Terraform dipertahankan dalam file status yang dibuat secara otomatis. Pengembang Terraform harus berurusan dengan status jauh lebih langsung daripada yang mereka lakukan. CloudFormation Yang penting untuk diingat adalah bahwa status pelacakan sama pentingnya untuk kedua alat.

Secara default, file status Terraform disimpan secara lokal di tingkat atas direktori utama yang menjalankan tumpukan Terraform Anda. Jika Anda menjalankan terraform apply perintah dari lingkungan pengembangan lokal Anda, Anda dapat melihat Terraform menghasilkan file terraform.tfstate yang digunakannya untuk mempertahankan status secara real time. Baik atau buruk, ini memberi Anda lebih banyak kendali atas negara bagian di Terraform daripada yang Anda miliki. CloudFormation Meskipun Anda tidak boleh memperbarui file status secara langsung, ada beberapa perintah CLI Terraform yang dapat Anda jalankan yang akan memperbarui status di antara penerapan. Misalnya, terraform import memungkinkan Anda menambahkan sumber daya yang dibuat di luar Terraform ke dalam tumpukan penerapan Anda. Sebaliknya, Anda dapat menghapus sumber daya dari status dengan menjalankan terraform state rm.

Fakta bahwa Terraform perlu menyimpan statusnya di suatu tempat mengarah ke konsep lain yang tidak berlaku untuk CloudFormation: backend. Backend Terraform adalah tempat tumpukan Terraform menyimpan file statusnya setelah penerapan. Ini juga di mana ia mengharapkan untuk menemukan file status ketika penerapan baru dimulai. Saat Anda menjalankan tumpukan secara lokal, seperti dijelaskan di atas, Anda dapat menyimpan salinan status Terraform di direktori lokal tingkat atas. Ini dikenal sebagai backend lokal.

Saat mengembangkan untuk integrasi berkelanjutan dan lingkungan penerapan berkelanjutan (CI/CD), file status lokal umumnya disertakan dalam file.gitignore untuk menjauhkannya dari kontrol versi. Maka tidak ada file status lokal yang ada di dalam pipeline. Agar berfungsi dengan baik, tahap pipeline itu perlu menemukan file status yang benar di suatu tempat.Inilah sebabnya mengapa file konfigurasi Terraform sering berisi blok backend. Blok backend menunjukkan ke tumpukan Terraform bahwa ia perlu mencari di suatu tempat selain direktori tingkat atasnya sendiri untuk menemukan file status.

Backend Terraform dapat ditemukan hampir di mana saja: bucket Amazon S3, titik akhir API, atau bahkan ruang kerja Terraform jarak jauh. Berikut ini adalah contoh backend Terraform yang disimpan di bucket Amazon S3.

terraform {
  backend "s3" {
    bucket = "my-s3-bucket"
    key    = "state-file-folder"
    region = "us-east-1"
  }
}

Untuk menghindari penyimpanan informasi sensitif dalam file konfigurasi Terraform, backend juga mendukung konfigurasi sebagian. Pada contoh sebelumnya, kredensional yang diperlukan untuk mengakses bucket tidak ada dalam konfigurasi. Kredensi dapat diperoleh dari variabel lingkungan atau dengan menggunakan cara lain, seperti. AWS Secrets Manager Untuk informasi selengkapnya, lihat Mengamankan data sensitif dengan menggunakan AWS Secrets Manager dan HashiCorp Terraform.

Skenario backend yang umum adalah backend lokal yang digunakan di lingkungan lokal Anda untuk tujuan pengujian. File terraform.tfstate disertakan dalam file.gitignore sehingga tidak didorong ke repositori jarak jauh. Kemudian, setiap lingkungan dalam pipa CI/CD akan mempertahankan backendnya sendiri. Dalam skenario ini, beberapa pengembang mungkin memiliki akses ke status jarak jauh ini, jadi Anda ingin melindungi integritas file status. Jika beberapa penerapan berjalan dan memperbarui status pada saat yang sama, file status dapat menjadi rusak. Untuk alasan ini, dalam situasi dengan backend non-lokal, file status biasanya dikunci selama penerapan.