Menampilkan infrastruktur sebagai kode dalam format teks yang dapat diulang adalah praktik terbaik sederhana untuk sistem yang tidak perlu Anda bawa-bawa. Praktik ini memiliki nama - Infrastruktur sebagai Kode , dan sejauh ini ada dua alat yang populer untuk implementasinya, terutama di AWS: Terraform dan CloudFormation .
Bandingkan pengalaman dengan Terraform dan CloudFormation
Sebelum bergabung dengan Twitch (alias Amazon Jr. ), saya bekerja di satu startup dan menggunakan Terraform selama tiga tahun. Di tempat baru, saya juga menggunakan Terraform dengan kekuatan dan main, dan kemudian perusahaan mendorong transisi ke semuanya ala Amazon, termasuk CloudFormation. Saya bekerja keras untuk mengembangkan praktik terbaik untuk keduanya, dan saya menggunakan kedua alat dalam alur kerja yang sangat kompleks di seluruh organisasi. Kemudian, setelah mempertimbangkan dengan hati-hati konsekuensi dari beralih dari Terraform ke CloudFormation, saya menjadi yakin bahwa Terraform mungkin adalah pilihan terbaik untuk organisasi.
Perangkat Lunak Beta
Terraform bahkan belum merilis versi 1.0, dan ini adalah alasan bagus untuk tidak menggunakannya. Sejak saya pertama kali mengujinya sendiri, itu telah banyak berubah, tetapi kemudian terraform apply sering rusak setelah beberapa pembaruan atau hanya setelah beberapa tahun beroperasi. Saya akan mengatakan bahwa "sekarang semuanya berbeda", tapi ... jadi semua orang tampaknya mengatakan tidak? Ada perubahan yang tidak kompatibel dengan versi sebelumnya, meskipun mereka sesuai, dan bahkan perasaannya adalah bahwa sintaks dan abstraksi dari penyimpanan sumber daya sekarang apa yang Anda butuhkan. Alat itu sepertinya lebih baik, tapi ...: -0
AWS, di sisi lain, melakukan pekerjaan yang baik untuk menjaga kompatibilitas dengan versi sebelumnya. Semua, mungkin, karena layanan mereka sering diuji dengan baik dalam organisasi dan hanya kemudian, diganti namanya, diterbitkan. Jadi "berusaha keras" masih lemah kata. Mempertahankan kompatibilitas dengan versi API sebelumnya untuk sistem multivarian dan kompleks seperti AWS sangat sulit. Siapa pun yang harus mendukung API yang tersedia untuk umum yang digunakan secara luas harus memahami betapa sulitnya selama bertahun-tahun. Tetapi perilaku CloudFormation dalam ingatan saya tidak pernah berubah selama bertahun-tahun.
Temui kaki ... itu peluru
Sejauh yang saya tahu, tidak mungkin untuk menghapus sumber daya tumpukan CloudFormation pihak ketiga dari tumpukan CF saya. Situasinya mirip dengan Terraform. Ini memungkinkan Anda untuk mengimpor sumber daya yang ada ke tumpukan Anda. Fungsinya, bisa dikatakan, mengagumkan, tetapi dengan kekuatan besar datang tanggung jawab besar. Seseorang hanya perlu meletakkan sumber daya di tumpukan, dan saat Anda bekerja dengan tumpukan Anda, Anda tidak dapat menghapus atau mengubah sumber daya ini. Setelah itu muncul. Entah bagaimana, di situs Twitch, seseorang, tanpa merencanakan kesalahan, secara tidak sengaja mengimpor grup keamanan AWS ke tumpukan Terraform mereka sendiri. Saya memasukkan beberapa perintah dan ... grup keamanan (bersama dengan lalu lintas masuk) menghilang.
Pemulihan sebagian
Terkadang CloudFormation tidak dapat sepenuhnya beralih dari satu kondisi ke kondisi lain. Pada saat yang sama, ia akan mencoba untuk kembali ke yang sebelumnya. Maaf, ini tidak selalu layak. Kemudian men-debug apa yang terjadi menakutkan - Anda tidak pernah tahu apakah CloudFormation akan senang bahwa itu retak - bahkan untuk perbaikan. Tetapi apakah dia akan berhasil atau tidak kembali ke keadaan sebelumnya, dia benar-benar tidak tahu bagaimana menentukan, dan secara default dia berjam-jam menunggu keajaiban.
Terraform, sebaliknya, cenderung pulih dari transisi yang gagal jauh lebih elegan dan menawarkan alat debugging canggih.
Perubahan yang lebih jelas dalam status dokumen
"Oke, muat penyeimbang, kamu berubah. Tapi bagaimana?"
—Seorang insinyur yang khawatir siap untuk menekan tombol terima.
Kadang-kadang saya perlu melakukan beberapa manipulasi dengan penyeimbang beban di tumpukan CloudFormation - misalnya, menambahkan nomor port atau mengubah grup keamanan. Perubahan CloudFormation ditampilkan dengan lemah. Saya, seperti pada jarum, memeriksa ulang file yaml sepuluh kali untuk memastikan bahwa saya tidak menghapus apa pun yang saya butuhkan, dan saya tidak menambahkan terlalu banyak.
Terraform jauh lebih transparan dalam hal ini. Terkadang terlalu transparan (baca: mengerti). Untungnya, versi terbaru menyertakan tampilan perubahan yang ditingkatkan - sekarang Anda dapat dengan jelas melihat apa yang berubah.
Fleksibilitas
Tulis perangkat lunak dari arah sebaliknya.
Terus terang, fitur pembeda yang paling penting dari perangkat lunak berumur panjang adalah kemampuannya untuk beradaptasi terhadap perubahan. Tulis perangkat lunak apa pun dari sebaliknya. Saya sering menusuk bahwa saya mengambil layanan "sederhana", dan kemudian mulai mendorong semuanya menjadi satu CloudFormation atau tumpukan Terraform. Dan tentu saja, berbulan-bulan kemudian terungkap bahwa saya mengerti semuanya salah, dan layanan ini sebenarnya tidak sederhana! Jadi saya perlu memecah tumpukan besar menjadi komponen-komponen kecil. Ketika Anda bekerja dengan CloudFormation, dimungkinkan untuk melakukan ini hanya dengan terlebih dahulu menciptakan kembali tumpukan yang ada, tetapi saya tidak melakukan ini dengan database saya. Terraform, di sisi lain, memungkinkan untuk membedah tumpukan dan membaginya menjadi bagian-bagian kecil yang lebih dimengerti.
Modul dalam git
Berbagi kode Terraform di banyak tumpukan jauh lebih mudah daripada berbagi kode CloudFormation. Dengan Terraform, Anda dapat meletakkan kode di 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 keunggulan yang sama, dan tidak ada alasan tunggal mengapa kita harus benar-benar meninggalkan git yang mendukung S3.
Organisasi tumbuh dan kemampuan untuk berbagi tumpukan mencapai tingkat kritis. Dengan Terraform, semua ini mudah dan alami, sementara CloudFormation akan membuat Anda melompati cincin sebelum Anda mendapatkan sesuatu yang serupa.
Operasi sebagai kode
"Ayo skrip dan oke."
- Seorang insinyur 3 tahun sebelum menciptakan sepeda Terraform.
Ketika datang ke pengembangan perangkat lunak, Go atau program Java bukan hanya kode.
Kode sebagai Kode
Lagi pula, masih ada infrastruktur di mana ia bekerja.
Infrastruktur sebagai kode
Tapi dari mana asalnya? Bagaimana cara memantaunya? Di mana kode Anda berada? Apakah pengembang perlu izin untuk mengakses?
Operasi sebagai kode
Menjadi pengembang perangkat lunak bukan hanya tentang menulis kode.
Bukan AWS One: Anda harus menggunakan penyedia lain. SignalFx, PagerDuty, atau Github. Mungkin Anda memiliki server Jenkins internal untuk CI / CD atau panel kontrol Grafana internal untuk pemantauan. Infra as Code dipilih karena berbagai alasan, dan apa pun juga sama pentingnya untuk segala sesuatu yang berkaitan dengan perangkat lunak.
Ketika saya bekerja di Twitch, kami mempercepat layanan di dalam sistem embedded campuran Amazon dan sistem AWS. Kami mencap dan mendukung banyak layanan mikro, meningkatkan biaya operasi. Diskusi diadakan kira-kira sebagai berikut:
- SAYA : Sial, banyak gerakan untuk membubarkan satu layanan microser. Saya harus menggunakan sampah ini untuk membuat akun AWS (kami pergi ke 2 akun untuk layanan mikro ), lalu yang ini untuk mengatur notifikasi, yang ini untuk repositori kode, dan yang ini untuk daftar alamat email, dan yang ini .. .
- Pimpin : Mari kita skrip dan oke.
- Saya : Frets, tetapi skrip itu sendiri akan berubah. Anda perlu cara untuk memverifikasi bahwa semua alat amazon bawaan ini mutakhir.
- Timbal : Kedengarannya bagus. Dan untuk ini kami akan menulis skrip.
- Saya : Hebat! Dan skrip mungkin masih perlu mengatur parameter. Apakah dia akan menerimanya?
- Pimpin : Ya, dia akan, ke mana dia akan pergi!
- Saya : Proses dapat berubah, kompatibilitas mundur akan hilang. Ini akan mengambil beberapa kontrol versi semantik.
- Pimpin : Ide bagus!
- Saya : Alat dapat diubah secara manual, di dalam antarmuka pengguna. Kami membutuhkan cara untuk memverifikasi dan memperbaikinya.
... 3 tahun kemudian:
- Timbal : Dan kami mendapat terraform.
Moral dari dongeng adalah ini: bahkan jika Anda jungkir balik di semua amazon , Anda masih menggunakan sesuatu yang bukan dari AWS, dan layanan ini memiliki status yang digunakan bahasa untuk konfigurasi untuk menyinkronkan keadaan ini.
lambda adalah solusi CloudFormation untuk masalah logika kustom. Dengan lambda, Anda dapat membuat makro atau sumber daya khusus . Pendekatan ini menghadirkan kesulitan tambahan yang tidak dimiliki Terraform dalam kontrol semit versi modul git. Bagi saya, masalah yang paling mendesak adalah mengelola izin untuk semua lambda khusus ini (yang merupakan lusinan akun AWS). Yang penting lainnya adalah masalah seperti "apa yang terjadi sebelumnya - ayam atau telur?": Itu terkait dengan kode lambda. Fungsi ini sendiri adalah infrastruktur dan kode, dan itu sendiri membutuhkan pemantauan dan pembaruan. Sorotan terakhir dalam peti mati itu adalah kesulitan memperbarui perubahan kode lambda secara semantik; itu juga perlu untuk memastikan bahwa tindakan stack tanpa perintah langsung tidak berubah di antara mulai.
Saya ingat entah bagaimana saya ingin membuat penyebaran kenari untuk lingkungan Elastic Beanstalk dengan penyeimbang beban klasik. Cara termudah adalah dengan melakukan penyebaran kedua untuk EB di sebelah lingkungan produksi, mengambil langkah lain: dengan menggabungkan grup penyebaran kenari yang dapat diskalakan secara otomatis dengan penyebaran LB ke dalam lingkungan produksi. Dan karena Terraform menggunakan ASG beantalk sebagai output , ia akan membutuhkan 4 baris kode tambahan dalam Terraform. Ketika saya bertanya apakah ada solusi yang sebanding di CloudFormation, mereka menunjuk saya ke seluruh repositori di git dengan pipa penyebaran dan banyak lagi: semua ini demi apa yang bisa dilakukan oleh 4 baris kode Terraform yang malang.
Dia lebih baik mendeteksi drift
Pastikan kenyataan memenuhi harapan.
Deteksi drift adalah operasi yang sangat kuat sebagai kode, karena membantu memastikan bahwa kenyataan memenuhi harapan. Ini tersedia dengan CloudFormation dan Terraform. Tetapi ketika tumpukan kerja bertambah, pencarian drift CloudFormation semakin banyak menghasilkan false positive.
Dengan Terraform, Anda memiliki kait siklus hidup yang jauh lebih maju untuk deteksi drift. Misalnya, Anda memasukkan perintah ign_changes secara langsung dalam definisi tugas ECS jika Anda ingin mengabaikan perubahan dalam definisi tugas tertentu tanpa mengabaikan perubahan dalam seluruh penerapan ECS.
CloudFormation sulit dikelola pada skala lintas-infrastruktur yang besar. Banyak dari kesulitan ini yang dikenali, dan alat ini membutuhkan hal-hal seperti aws-cdk , kerangka kerja untuk mendefinisikan infrastruktur cloud dalam kode dan meneruskannya melalui AWS CloudFormation. Dia akan penasaran untuk melihat apa yang akan dimiliki aws-cdk di masa depan, tetapi akan sulit baginya untuk bersaing dengan manfaat lain dari Terraform; untuk mengencangkan CloudFormation, perubahan global akan diperlukan.
Ini adalah "infrastruktur sebagai KODE", bukan "sebagai teks."
Kesan pertama saya tentang Terraform sangat buruk. Saya pikir saya tidak mengerti pendekatannya. Hampir semua insinyur pada awalnya tanpa sadar menganggapnya sebagai format teks yang harus dikonversi ke infrastruktur yang diinginkan. JANGAN BEGITU.
Saya telah melihat berapa banyak praktik yang diadopsi untuk membuat kode yang baik diabaikan dalam Terraform. Anda belajar selama bertahun-tahun untuk menjadi programmer yang baik. Jangan menyerah pengalaman ini hanya karena Anda bekerja dengan Terraform. Kebenaran umum dari pengembangan perangkat lunak yang baik juga berlaku untuk Terraform.
Bagaimana kode tidak didokumentasikan?
Saya menemukan tumpukan Terraform besar tanpa dokumentasi sama sekali. Bagaimana saya bisa menulis kode di halaman - sepenuhnya tanpa dokumentasi? Tambahkan dokumentasi yang menjelaskan kode Terraform Anda (penekanan di sini pada kata "kode"), mengapa bagian ini sangat penting, dan apa yang Anda lakukan.
Bagaimana Anda bisa menggunakan layanan yang dulunya satu fungsi utama () besar?
Saya bertemu tumpukan Terraform yang sangat kompleks, disajikan sebagai satu modul. Mengapa kita tidak menggunakan perangkat lunak seperti ini? Mengapa memecah fungsi besar menjadi yang lebih kecil? Jawaban yang sama berlaku untuk Terraform. Jika modul Anda terlalu besar, Anda perlu memecahnya menjadi modul yang lebih kecil.
Bukankah perusahaan Anda menggunakan perpustakaan?
Saya melihat bagaimana para insinyur, memutar proyek baru menggunakan Terraform, dengan bodoh menyalin-menempelkan potongan-potongan besar dari proyek lain ke dalam proyek mereka sendiri, dan kemudian mengambilnya sampai mulai bekerja. Jadi, apakah Anda akan bekerja di perusahaan Anda dengan kode "pertarungan"? Kami tidak hanya menggunakan perpustakaan. Ya, tidak semuanya harus menjadi perpustakaan, tetapi di mana kita pada prinsipnya tanpa perpustakaan bersama?!
Apakah Anda tidak menggunakan PEP8 atau gofmt?
Sebagian besar bahasa memiliki skema pemformatan yang diterima standar. Dengan Python, ini adalah PEP8. Di Go - gofmt. Terraform memiliki sendiri: terraform fmt . Gunakan untuk kesehatan!
Apakah Anda akan menggunakan Bereaksi tanpa mengetahui JavaScript?
Modul-modul Terraform dapat menyederhanakan beberapa bagian dari infrastruktur kompleks yang Anda buat, tetapi ini tidak berarti Anda dapat mengabaikannya sama sekali. Ingin menggunakan Terraform dengan benar tanpa memahami sumber daya? Anda ditakdirkan: waktu akan berlalu, tetapi Anda tidak akan menguasai Terraform.
Apakah Anda kode singleton, atau memperkenalkan dependensi?
Ketergantungan injeksi adalah praktik terbaik yang diakui untuk pengembangan perangkat lunak, yang disukai oleh singleton. Bagaimana ini berguna dalam Terraform? Saya bertemu modul Terraform tergantung pada keadaan jauh. Alih-alih menulis modul yang mengekstrak dari keadaan jauh, tulis modul yang menerima parameter. Dan kemudian meneruskan parameter ini ke modul.
Apakah perpustakaan Anda melakukan sepuluh hal dengan baik, atau satu hal hebat?
Perpustakaan yang fokus pada satu tugas yang hanya melakukan pekerjaan terbaik. Alih-alih menulis modul Terraform besar yang mencoba melakukan semuanya sekaligus, buatlah bagian dari mereka yang melakukan satu hal dengan baik. Dan kemudian gabungkan mereka seperti yang Anda inginkan.
Bagaimana Anda membuat perubahan pada perpustakaan tanpa kompatibilitas ke belakang?
Modul Terraform umum, seperti perpustakaan biasa, perlu memberi tahu pengguna tentang perubahan tanpa kompatibilitas ke belakang. Ketika perubahan seperti itu terjadi di perpustakaan, itu menjengkelkan, dan sama menjengkelkan ketika perubahan tanpa kompatibilitas mundur dibuat dalam modul Terraform. Disarankan untuk menggunakan tag git dan semver saat menggunakan modul Terraform.
Apakah layanan produksi diluncurkan pada laptop Anda atau di pusat data?
Hashicorp memiliki alat seperti cloud terraform untuk meluncurkan terraform Anda. Layanan terpusat ini memfasilitasi manajemen, audit, dan persetujuan perubahan terraform.
Apakah kamu tidak menulis tes?
Insinyur mengakui bahwa kode perlu diuji, tetapi mereka sendiri sering kali mengecek saat bekerja dengan Terraform. Untuk infrastruktur, ini penuh dengan momen berbahaya. Saya menyarankan Anda untuk "menguji" atau "membuat contoh" tumpukan menggunakan modul yang dapat digunakan dengan benar untuk verifikasi selama CI / CD.
Kehidupan dan kematian perusahaan layanan mikro tergantung pada kecepatan, pembaruan, dan penghancuran tumpukan pekerjaan layanan mikro baru.
Titik negatif paling umum terkait dengan arsitektur layanan mikro dan yang tidak dapat dihilangkan dengan cara apa pun terkait dengan pekerjaan, dan bukan dengan kode. Jika Anda menggunakan Terraform, hanya sebagai cara untuk mengotomatisasi hanya sisi infrastruktur dari arsitektur layanan mikro, maka Anda merampas manfaat sebenarnya dari sistem ini. Sekarang semuanya seperti kode .