Merepresentasikan infrastruktur sebagai kode dalam format teks berulang adalah praktik terbaik yang sederhana untuk sistem yang tidak perlu mengutak-atik mouse. Praktek ini memiliki nama - , dan sejauh ini ada dua alat populer untuk mengimplementasikannya, khususnya di AWS: и .
Membandingkan pengalaman dengan Terraform dan CloudFormation
Sebelum datang ke (Aka ) Saya telah bekerja dan menggunakan Terraform selama tiga tahun. Di tempat baru, saya juga menggunakan Terraform dengan sekuat tenaga, dan kemudian perusahaan mendorong transisi ke segala hal ala Amazon, termasuk CloudFormation. Saya telah dengan tekun mengembangkan praktik terbaik untuk keduanya, dan telah menggunakan kedua alat tersebut dalam alur kerja yang sangat kompleks di seluruh organisasi. Belakangan, setelah mempertimbangkan dengan cermat implikasi migrasi dari Terraform ke CloudFormation, saya menjadi yakin bahwa Terraform mungkin adalah pilihan terbaik bagi organisasi.
Terraform Mengerikan
Perangkat lunak beta
Terraform bahkan belum merilis versi 1.0, yang merupakan alasan bagus untuk tidak menggunakannya. Ini telah banyak berubah sejak saya pertama kali mencobanya sendiri, tetapi saat itu terraform apply sering rusak setelah beberapa kali pembaruan atau hanya setelah beberapa tahun digunakan. Saya akan mengatakan bahwa "semuanya berbeda sekarang," tapi... sepertinya semua orang mengatakan itu, bukan? Ada perubahan yang tidak kompatibel dengan versi sebelumnya, meskipun sesuai, dan bahkan sintaksis dan abstraksi penyimpanan sumber daya kini terasa seperti yang kita butuhkan. Instrumennya nampaknya menjadi lebih baik, tapi... :-0
Di sisi lain, AWS telah melakukan pekerjaan yang baik dalam menjaga kompatibilitas ke belakang. Hal ini mungkin karena layanan mereka sering kali diuji secara menyeluruh di dalam organisasi dan baru kemudian, setelah diganti namanya, dipublikasikan. Jadi “mereka berusaha keras” adalah sebuah pernyataan yang meremehkan. Mempertahankan kompatibilitas mundur dengan API untuk sistem yang beragam dan rumit seperti AWS sangatlah sulit. Siapa pun yang harus memelihara API publik yang digunakan secara luas harus memahami betapa sulitnya melakukan hal tersebut selama bertahun-tahun. Namun perilaku CloudFormation, dalam ingatan saya, tidak pernah berubah selama bertahun-tahun.
Temui kakinya... itu peluru
Sejauh yang saya tahu, hapus sumber dayanya orang luar Tumpukan CloudFormation dari tumpukan CF Anda tidak dimungkinkan. Hal yang sama berlaku dengan Terraform. Ini memungkinkan Anda untuk mengimpor sumber daya yang ada ke dalam tumpukan Anda. Fungsinya bisa dikatakan luar biasa, namun dengan kekuatan yang besar datang pula tanggung jawab yang besar. Anda hanya perlu menambahkan sumber daya ke tumpukan, dan saat Anda bekerja dengan tumpukan, Anda tidak dapat menghapus atau mengubah sumber daya ini. Suatu hari hal itu menjadi bumerang. Suatu hari di Twitch, seseorang secara tidak sengaja mengimpor grup keamanan AWS orang lain ke dalam tumpukan Terraform mereka sendiri tanpa melakukan kerusakan apa pun. Saya memasukkan beberapa perintah dan... grup keamanan (bersama dengan lalu lintas masuk) menghilang.
Terraform Hebat
Pemulihan dari keadaan yang tidak lengkap
Terkadang CloudFormation gagal melakukan transisi sepenuhnya dari satu keadaan ke keadaan lainnya. Pada saat yang sama, dia akan mencoba untuk kembali ke masa lalu. Sayangnya hal ini tidak selalu dapat dilakukan. Men-debug apa yang terjadi kemudian bisa jadi sangat menakutkan - Anda tidak pernah tahu apakah CloudFormation akan senang karena diretas - bahkan hanya untuk memperbaikinya. Apakah mungkin untuk kembali ke keadaan sebelumnya atau tidak, dia benar-benar tidak tahu bagaimana menentukannya dan, secara default, hang berjam-jam menunggu keajaiban.
Terraform, di sisi lain, cenderung pulih dari transisi yang gagal dengan lebih baik dan menawarkan alat debugging tingkat lanjut.
Perubahan yang lebih jelas pada status dokumen
“Oke, penyeimbang beban, Anda berubah. Tapi bagaimana caranya?"
—Insinyur yang cemas, siap menekan tombol “terima”.
Terkadang saya perlu melakukan beberapa manipulasi dengan penyeimbang beban di tumpukan CloudFormation, seperti menambahkan nomor port atau mengubah grup keamanan. ClouFormation menampilkan perubahan dengan buruk. Saya, dengan pin dan jarum, memeriksa ulang file yaml sepuluh kali untuk memastikan bahwa saya belum menghapus apa pun yang diperlukan dan tidak menambahkan apa pun yang tidak perlu.
Terraform jauh lebih transparan dalam hal ini. Kadang dia malah terlalu transparan (baca: menyebalkan). Untungnya, versi terbaru menyertakan tampilan perubahan yang lebih baik sehingga kini Anda dapat melihat dengan tepat apa yang berubah.
Keluwesan
Tulis perangkat lunak secara terbalik.
Terus terang, karakteristik paling penting dari perangkat lunak yang berumur panjang adalah kemampuan untuk beradaptasi terhadap perubahan. Tulis perangkat lunak apa pun secara terbalik. Paling sering saya membuat kesalahan dengan menggunakan layanan "sederhana", dan kemudian mulai menjejalkan semuanya ke dalam satu tumpukan CloudFormation atau Terraform. Dan tentu saja, berbulan-bulan kemudian terungkap bahwa saya telah salah memahami segalanya, dan layanannya sebenarnya tidak sederhana! Dan sekarang saya perlu memecah tumpukan besar menjadi komponen-komponen kecil. Saat Anda bekerja dengan CloudFormation, ini hanya dapat dilakukan dengan terlebih dahulu membuat ulang tumpukan yang ada, dan saya tidak melakukan ini dengan database saya. Terraform, sebaliknya, memungkinkan untuk membedah tumpukan dan memecahnya menjadi bagian-bagian kecil yang lebih mudah dipahami.
Modul di git
Berbagi kode Terraform ke beberapa tumpukan jauh lebih mudah daripada berbagi kode CloudFormation. Dengan Terraform, Anda dapat memasukkan kode Anda ke dalam repositori git dan mengaksesnya menggunakan kontrol versi semantik. Siapa pun yang memiliki akses ke repositori ini dapat menggunakan kembali kode bersama. Setara dengan CloudFormation adalah S3, tetapi tidak memiliki manfaat yang sama, dan tidak ada alasan mengapa kita harus meninggalkan git demi S3 sama sekali.
Organisasi berkembang dan kemampuan untuk berbagi tumpukan umum mencapai tingkat kritis. Terraform membuat semuanya mudah dan alami, sedangkan CloudFormation akan membuat Anda melewati rintangan sebelum Anda dapat membuat sesuatu seperti ini berfungsi.
Operasi sebagai kode
“Mari kita buat skripnya dan oke.”
—seorang insinyur 3 tahun sebelum menemukan sepeda Terraform.
Dalam hal pengembangan perangkat lunak, Go atau program Java bukan sekadar kode.
Kode sebagai Kode
Ada juga infrastruktur tempat ia bekerja.
Infrastruktur sebagai Kode
Tapi dari mana asalnya? Bagaimana cara memantaunya? Di mana kode Anda berada? Apakah pengembang memerlukan izin akses?
Operasi sebagai Kode
Menjadi pengembang perangkat lunak tidak hanya berarti menulis kode.
AWS bukan satu-satunya: Anda mungkin menggunakan penyedia lain. SignalFx, PagerDuty atau Github. Mungkin Anda memiliki server Jenkins internal untuk CI/CD atau dasbor Grafana internal untuk pemantauan. Infra sebagai Kode dipilih karena alasan yang berbeda-beda, dan masing-masing sama pentingnya untuk segala hal yang berkaitan dengan perangkat lunak.
Ketika saya bekerja di Twitch, kami mempercepat layanan di dalam sistem tertanam campuran dan sistem AWS Amazon. Kami mengembangkan dan mendukung banyak layanan mikro, sehingga meningkatkan biaya operasional. Diskusinya berlangsung seperti ini:
- Я: Sial, banyak sekali isyarat untuk melakukan overclock pada satu layanan mikro. Saya harus menggunakan sampah ini untuk membuat akun AWS (kami menggunakan 2 akun layanan mikro), lalu yang ini untuk menyiapkan peringatan, yang ini untuk penyimpanan kode, dan yang ini untuk daftar email, lalu yang ini...
- Memimpin: Mari kita buat skripnya dan oke.
- Я: Oke, tapi skripnya sendiri akan berubah. Kami memerlukan cara untuk memeriksa apakah semua alat bawaan Amazon ini mutakhir.
- Memimpin: Kedengarannya bagus. Dan kami akan menulis naskah untuk ini.
- Я: Besar! Dan skrip mungkin masih perlu mengatur parameter. Akankah dia menerimanya?
- Memimpin: Biarkan dia membawa kemana dia pergi!
- Я: Prosesnya mungkin berubah dan kompatibilitas ke belakang akan hilang. Beberapa jenis kontrol versi semantik akan diperlukan.
- Memimpin: Ide yang hebat!
- Я: Alat dapat diubah secara manual, di dalam antarmuka pengguna. Kami memerlukan cara untuk memeriksa dan memperbaikinya.
…3 tahun kemudian:
- Memimpin: Dan kami mendapatkan terraform.
Pesan moral dari cerita ini adalah: meskipun Anda jungkir balik dalam segala hal di Amazon, Anda masih menggunakan sesuatu yang bukan dari AWS, dan layanan ini memiliki status yang menggunakan bahasa konfigurasi untuk menjaga status tersebut tetap sinkron.
Lambda CloudFormation vs modul git terraform
lambda adalah solusi CloudFormation untuk masalah logika khusus. Dengan lambda Anda bisa или . Pendekatan ini menimbulkan kompleksitas tambahan yang tidak ada dalam versi semantik modul git Terraform. Bagi saya, masalah yang paling mendesak adalah mengelola izin untuk semua lambda pengguna ini (dan ini adalah lusinan akun AWS). Masalah penting lainnya adalah masalah “apa yang lebih dulu, ayam atau telur?”: masalah ini berkaitan dengan kode lambda. Fungsi ini sendiri adalah infrastruktur dan kode, dan memerlukan pemantauan dan pembaruan. Paku terakhir di peti mati adalah kesulitan dalam memperbarui perubahan kode lambda secara semantik; kami juga harus memastikan bahwa tindakan tumpukan tanpa perintah langsung tidak berubah saat dijalankan.
Saya ingat suatu kali saya ingin membuat penerapan canary untuk lingkungan Elastic Beanstalk dengan penyeimbang beban klasik. Hal termudah untuk dilakukan adalah melakukan penerapan kedua untuk EB di samping lingkungan produksi, dan melangkah lebih jauh: menggabungkan grup penerapan canary penskalaan otomatis dengan penerapan LB ke dalam lingkungan produksi. Dan sejak Terraform menggunakan , ini memerlukan 4 baris kode tambahan di Terraform. Ketika saya bertanya apakah ada solusi serupa di CloudFormation, mereka mengarahkan saya ke seluruh repositori git dengan pipeline penerapan dan semuanya, semuanya demi sesuatu yang dapat dilakukan oleh 4 baris kode Terraform yang buruk.
Ini mendeteksi penyimpangan dengan lebih baik
Pastikan kenyataan sesuai dengan harapan.
adalah fitur operasi sebagai kode yang sangat kuat karena membantu memastikan bahwa kenyataan sesuai dengan harapan. Ini tersedia dengan CloudFormation dan Terraform. Namun seiring bertambahnya tumpukan produksi, pencarian penyimpangan di CloudFormation menghasilkan lebih banyak deteksi palsu.
Dengan Terraform Anda memiliki kait siklus hidup yang lebih canggih untuk deteksi penyimpangan. Misalnya, Anda memasukkan perintah langsung dalam ketentuan tugas ECS jika Anda ingin mengabaikan perubahan pada ketentuan tugas tertentu tanpa mengabaikan perubahan pada seluruh penerapan ECS Anda.
CDK dan masa depan CloudFormation
CloudFormation sulit dikelola pada skala lintas infrastruktur yang besar. Banyak dari kesulitan ini yang dikenali dan alat tersebut memerlukan hal-hal seperti itu , kerangka kerja untuk mendefinisikan infrastruktur cloud dalam kode dan menjalankannya melalui AWS CloudFormation. Akan menarik untuk melihat masa depan aws-cdk, tetapi akan sulit bersaing dengan kekuatan Terraform lainnya; untuk memperbarui CloudFormation, diperlukan perubahan global.
Agar Terraform tidak mengecewakan
Ini adalah “infrastruktur sebagai kode”, dan bukan “sebagai teks”.
Kesan pertama saya terhadap Terraform agak buruk. Saya rasa saya tidak memahami pendekatannya. Hampir semua insinyur tanpa sadar menganggapnya sebagai format teks yang perlu diubah menjadi infrastruktur yang diinginkan. JANGAN LAKUKAN DENGAN CARA INI.
Kebenaran tentang pengembangan perangkat lunak yang baik juga berlaku untuk Terraform.
Saya telah melihat banyak praktik yang diadopsi untuk membuat kode yang baik diabaikan di Terraform. Anda telah belajar selama bertahun-tahun untuk menjadi programmer yang baik. Jangan menyerah pada pengalaman ini hanya karena Anda bekerja dengan Terraform. Kebenaran dari pengembangan perangkat lunak yang baik berlaku untuk Terraform.
Bagaimana kodenya tidak didokumentasikan?
Saya telah melihat tumpukan Terraform yang sangat besar tanpa dokumentasi sama sekali. Bagaimana Anda bisa menulis kode dalam halaman - tanpa dokumentasi sama sekali? Tambahkan dokumentasi yang menjelaskan Anda kode Terraform (penekanan pada kata "kode"), mengapa bagian ini sangat penting, dan apa yang Anda lakukan.
Bagaimana kita bisa menerapkan layanan yang dulunya merupakan satu fungsi main() yang besar?
Saya telah melihat tumpukan Terraform yang sangat kompleks disajikan sebagai satu modul. Mengapa kita tidak menerapkan perangkat lunak dengan cara ini? Mengapa kita membagi fungsi besar menjadi fungsi yang lebih kecil? Jawaban yang sama berlaku untuk Terraform. Jika modul Anda terlalu besar, Anda perlu memecahnya menjadi modul-modul yang lebih kecil.
Bukankah perusahaan Anda menggunakan perpustakaan?
Saya telah melihat bagaimana para insinyur, saat membuat proyek baru menggunakan Terraform, dengan bodohnya menyalin-menempelkan sebagian besar proyek lain ke proyek mereka sendiri, dan kemudian mengutak-atiknya hingga mulai berfungsi. Apakah Anda akan bekerja seperti ini dengan kode “tempur” di perusahaan Anda? Kami tidak hanya menggunakan perpustakaan. Ya, tapi di manakah kita tanpa perpustakaan bersama pada prinsipnya?!
Apakah Anda tidak menggunakan PEP8 atau gofmt?
Sebagian besar bahasa memiliki skema pemformatan standar yang diterima. Dalam Python ini adalah PEP8. Di Go - gofmt. Terraform memilikinya sendiri: terraform fmt. Nikmati untuk kesehatan Anda!
Apakah Anda akan menggunakan React tanpa mengetahui JavaScript?
Modul Terraform dapat menyederhanakan beberapa bagian dari infrastruktur kompleks yang Anda buat, namun ini tidak berarti Anda tidak dapat mengotak-atiknya sama sekali. Ingin menggunakan Terraform dengan benar tanpa memahami sumber daya? Anda ditakdirkan: waktu akan berlalu, dan Anda tidak akan pernah menguasai Terraform.
Apakah Anda membuat kode dengan lajang atau injeksi ketergantungan?
Injeksi ketergantungan adalah praktik terbaik yang diakui untuk pengembangan perangkat lunak dan lebih disukai daripada lajang. Bagaimana ini berguna di Terraform? Saya telah melihat modul Terraform yang bergantung pada status jarak jauh. Daripada menulis modul yang mengambil status jarak jauh, tulislah modul yang mengambil parameter. Dan kemudian meneruskan parameter ini ke modul.
Apakah perpustakaan Anda melakukan sepuluh hal dengan baik atau satu hal hebat?
Perpustakaan yang berfungsi paling baik adalah perpustakaan yang fokus pada satu tugas dan mereka melakukannya dengan sangat baik. Daripada menulis modul Terraform besar yang mencoba melakukan semuanya sekaligus, buatlah bagian-bagiannya yang dapat melakukan satu hal dengan baik. Dan kemudian gabungkan sesuai kebutuhan.
Bagaimana Anda membuat perubahan pada perpustakaan tanpa kompatibilitas ke belakang?
Modul Terraform yang umum, seperti perpustakaan biasa, perlu mengkomunikasikan perubahan kepada pengguna tanpa harus kompatibel ke belakang. Sangat menjengkelkan ketika perubahan ini terjadi di perpustakaan, dan sama menjengkelkannya ketika perubahan yang tidak kompatibel dibuat di modul Terraform. Disarankan untuk menggunakan git tag dan semver saat menggunakan modul Terraform.
Apakah layanan produksi Anda berjalan di laptop atau di pusat data?
Hashicorp memiliki alat seperti untuk menjalankan terraform Anda. Layanan terpusat ini memudahkan pengelolaan, audit, dan persetujuan perubahan terraform.
Apakah kamu tidak menulis tes?
Insinyur menyadari bahwa kode tersebut perlu diuji, tetapi mereka sendiri sering lupa tentang pengujian saat bekerja dengan Terraform. Bagi infrastruktur, hal ini penuh dengan momen berbahaya. Saran saya adalah untuk “menguji” atau “membuat contoh” tumpukan menggunakan modul yang dapat diterapkan dengan benar untuk pengujian selama CI/CD.
Terraform dan layanan mikro
Hidup dan matinya perusahaan layanan mikro bergantung pada kecepatan, inovasi, dan gangguan pada tumpukan kerja layanan mikro baru.
Aspek negatif paling umum yang terkait dengan arsitektur layanan mikro, dan yang tidak dapat dihilangkan, terkait dengan pekerjaannya, bukan kodenya. Jika Anda menganggap Terraform hanya sebagai cara untuk mengotomatisasi sisi infrastruktur arsitektur layanan mikro saja, maka Anda kehilangan manfaat sebenarnya dari sistem tersebut. Sekarang sudah .
Sumber: www.habr.com