Banyak orang mengetahui dan menggunakan Terraform dalam pekerjaan sehari-hari, namun praktik terbaiknya belum terbentuk. Setiap tim harus menemukan pendekatan dan metodenya sendiri.
Infrastruktur Anda hampir pasti dimulai dengan sederhana: beberapa sumber daya + beberapa pengembang. Seiring waktu, ia tumbuh ke segala arah. Apakah Anda menemukan cara untuk mengelompokkan sumber daya ke dalam modul Terraform, mengatur kode ke dalam folder, dan kesalahan apa lagi yang mungkin terjadi? (kata-kata terakhir yang terkenal)
Waktu berlalu dan Anda merasa infrastruktur Anda adalah hewan peliharaan baru Anda, tapi mengapa? Anda khawatir tentang perubahan infrastruktur yang tidak dapat dijelaskan, Anda takut menyentuh infrastruktur dan kode - akibatnya, Anda menunda fungsionalitas baru atau mengurangi kualitas...
Setelah tiga tahun mengelola koleksi modul komunitas Terraform untuk AWS di Github dan pemeliharaan jangka panjang Terraform dalam produksi, Anton Babenko siap berbagi pengalamannya: cara menulis modul TF agar tidak merugikan di masa mendatang.
Di akhir pembicaraan, peserta akan lebih memahami prinsip pengelolaan sumber daya di Terraform, praktik terbaik yang terkait dengan modul di Terraform, dan beberapa prinsip integrasi berkelanjutan yang terkait dengan manajemen infrastruktur.
Penolakan: Saya perhatikan laporan ini bertanggal November 2018—2 tahun telah berlalu. Versi Terraform 0.11 yang dibahas dalam laporan tidak lagi didukung. Selama 2 tahun terakhir, telah dirilis 2 rilis baru yang berisi banyak inovasi, perbaikan dan perubahan. Harap perhatikan ini dan periksa dokumentasinya.
Ссылки:
- +
- — kode dan dokumentasi pemformatan otomatis
- — generator modul Terraform (WIP)
- — Generator kode terraform dari diagram visual (WIP)
- www.terraform-best-practices.com
- (Postingan baru ada di situs pribadi saya www.antonbabenko.com/)
- @antonbabenko - Twitter, dan sejumlah Slack lainnya
Nama saya Anton Babenko. Beberapa dari Anda mungkin menggunakan kode yang saya tulis. Sekarang saya akan membicarakan hal ini dengan lebih percaya diri daripada sebelumnya, karena saya memiliki akses terhadap statistik.
Saya bekerja di Terraform dan telah menjadi peserta aktif dan kontributor sejumlah besar proyek sumber terbuka terkait Terraform dan Amazon sejak tahun 2015.
Sejak itu saya telah menulis cukup banyak kode untuk membuatnya menarik. Dan saya akan mencoba memberi tahu Anda tentang hal ini sekarang.
Saya akan berbicara tentang seluk-beluk dan spesifik bekerja dengan Terraform. Tapi itu sebenarnya bukan topik HighLoad. Dan sekarang Anda akan mengerti alasannya.
Seiring waktu, saya mulai menulis modul Terraform. Pengguna menulis pertanyaan, saya menulis ulang. Kemudian saya menulis berbagai utilitas untuk memformat kode menggunakan pre-commit hook, dll.
Ada banyak proyek menarik. Saya suka pembuatan kode karena saya suka komputer melakukan lebih banyak pekerjaan untuk saya dan programmer, jadi saat ini saya sedang mengerjakan generator kode Terraform dari diagram visual. Mungkin sebagian dari Anda pernah melihatnya. Ini adalah kotak-kotak indah dengan panah. Dan menurut saya akan sangat bagus jika Anda dapat mengklik tombol “Ekspor” dan mendapatkan semuanya sebagai kode.
Saya dari Ukraina. Saya telah tinggal di Norwegia selama bertahun-tahun.
Selain itu, informasi untuk laporan ini dikumpulkan dari orang-orang yang mengetahui nama saya dan menemukan saya di jejaring sosial. Saya hampir selalu mempunyai nama panggilan yang sama.
Как я упомянул, я являюсь главным мейнтейнером Terraform AWS modules, который является одной из самых больших репозиторий на GitHub, где мы хостим модули для самых распространенных задач: VPC, Autoscaling, RDS.
Dan apa yang Anda dengar sekarang adalah yang paling mendasar. Jika Anda ragu memahami apa itu Terraform, lebih baik habiskan waktu Anda di tempat lain. Akan ada banyak istilah teknis di sini. Dan saya tidak segan-segan menyatakan tingkat laporannya paling tinggi. Ini berarti saya dapat berbicara menggunakan semua istilah yang mungkin tanpa banyak penjelasan.
Terraform muncul pada tahun 2014 sebagai utilitas yang memungkinkan Anda menulis, merencanakan, dan mengelola infrastruktur sebagai kode. Konsep kuncinya di sini adalah “infrastruktur sebagai kode.”
Вся документация, как я сказал, написана на . Saya harap sebagian besar orang mengetahui tentang situs ini dan telah membaca dokumentasinya. Jika iya, maka Anda berada di tempat yang tepat.
Seperti inilah tampilan file konfigurasi Terraform biasa, tempat kita pertama kali mendefinisikan beberapa variabel.
Dalam hal ini kita mendefinisikan "aws_region".
Kemudian kami menjelaskan sumber daya apa yang ingin kami buat.
Kami menjalankan beberapa perintah, khususnya “terraform init” untuk memuat dependensi dan penyedia.
Dan kami menjalankan perintah “terraform apply” untuk memeriksa apakah konfigurasi yang ditentukan cocok dengan sumber daya yang kami buat. Karena kita belum pernah membuat apa pun sebelumnya, Terraform meminta kita membuat sumber daya ini.
Kami mengkonfirmasi hal ini. Jadi kita membuat ember yang disebut seasnail.
Ada juga beberapa utilitas serupa. Banyak dari Anda yang menggunakan Amazon mengetahui AWS CloudFormation atau Google Cloud Deployment Manager atau Azure Resource Manager. Masing-masing dari mereka memiliki implementasi tersendiri untuk mengelola sumber daya dalam masing-masing penyedia cloud publik ini. Terraform sangat berguna karena memungkinkan Anda mengelola lebih dari 100 penyedia. (Keterangan lebih lanjut )
Tujuan yang dicapai Terraform sejak awal:
- Terraform menyediakan satu tampilan sumber daya.
- Memungkinkan Anda mendukung semua platform modern.
- Dan Terraform dirancang sejak awal sebagai utilitas yang memungkinkan Anda mengubah infrastruktur dengan aman dan dapat diprediksi.
Pada tahun 2014, kata “dapat diprediksi” terdengar sangat tidak biasa dalam konteks ini.
Terraform adalah utilitas universal. Jika Anda memiliki API, Anda benar-benar dapat mengontrol semuanya:
- Anda dapat menggunakan lebih dari 120 penyedia untuk mengelola semua yang Anda inginkan.
- Misalnya, Anda dapat menggunakan Terraform untuk menjelaskan akses ke repositori GitHub.
- Anda bahkan dapat membuat dan menutup bug di Jira.
- Anda dapat mengelola metrik New Relic.
- Anda bahkan dapat membuat file di Dropbox jika Anda benar-benar menginginkannya.
Это все достигается с помощью Terraform-провайдеров, у которых открытый API, которые можно описать на Go.
Katakanlah kita mulai menggunakan Terraform, membaca beberapa dokumentasi di situs, menonton beberapa video, dan mulai menulis main.tf, seperti yang saya tunjukkan pada slide sebelumnya.
Dan semuanya bagus, Anda memiliki file yang membuat VPC.
Jika Anda ingin membuat VPC, maka Anda tentukan kira-kira 12 baris ini. Jelaskan di wilayah mana Anda ingin membuat, cidr_block alamat IP mana yang akan digunakan. Itu saja.
Secara alami, proyek ini akan berkembang secara bertahap.
Dan Anda akan menambahkan banyak hal baru di sana: sumber daya, sumber data, Anda akan berintegrasi dengan penyedia baru, tiba-tiba Anda ingin menggunakan Terraform untuk mengelola pengguna di akun GitHub Anda, dll. Anda mungkin ingin menggunakan penyedia DNS yang berbeda, silangkan semuanya. Terraform membuat ini mudah.
Mari kita lihat contoh berikut.
Anda menambahkan internet_gateway secara bertahap karena Anda ingin sumber daya dari VPC Anda memiliki akses internet. Ini ide yang bagus.
Hasilnya main.tf ini:
Ini adalah bagian atas main.tf.
Ini adalah bagian bawah main.tf.
Kemudian Anda menambahkan subnet. Pada saat Anda ingin menambahkan gateway NAT, rute, tabel perutean, dan banyak subnet lainnya, Anda tidak akan memiliki 38 baris, tetapi sekitar 200-300 baris.
Artinya, file main.tf Anda berkembang secara bertahap. Dan seringkali orang memasukkan semuanya ke dalam satu file. 10-20 Kb muncul di main.tf. Bayangkan 10-20 Kb adalah konten teks. Dan semuanya terhubung dengan segalanya. Hal ini secara bertahap menjadi sulit untuk diatasi. 10-20 Kb adalah kasus pengguna yang bagus, terkadang lebih. Dan orang tidak selalu menganggap ini buruk.
Seperti dalam pemrograman biasa, yaitu bukan infrastruktur sebagai kode, kita terbiasa menggunakan sekumpulan kelas, paket, modul, pengelompokan yang berbeda. Terraform memungkinkan Anda melakukan banyak hal yang sama.
- Kode ini berkembang.
- Ketergantungan antar sumber daya juga semakin meningkat.
Dan kita mempunyai kebutuhan yang sangat besar. Kami memahami bahwa kami tidak dapat hidup seperti ini lagi. Kode kita menjadi sangat besar. 10-20 Kb, tentu saja, tidak terlalu luas, tetapi kita hanya berbicara tentang tumpukan jaringan, yaitu Anda hanya menambahkan sumber daya jaringan. Kami tidak berbicara tentang Application Load Balancer, penerapan cluster ES, Kubernetes, dll., di mana 100 Kb dapat dengan mudah digabungkan. Jika Anda menuliskan semua ini, Anda akan segera mengetahui bahwa Terraform menyediakan modul Terraform.
Modul Terraform adalah konfigurasi Terraform mandiri yang dikelola sebagai grup. Itu saja yang perlu Anda ketahui tentang modul Terraform. Mereka tidak pintar sama sekali, mereka tidak mengizinkan Anda membuat koneksi rumit apa pun bergantung pada sesuatu. Ini semua berada di pundak para pengembang. Artinya, ini hanyalah semacam konfigurasi Terraform yang sudah Anda tulis. Dan Anda cukup menyebutnya sebagai grup.
Jadi kami mencoba memahami bagaimana kami akan mengoptimalkan kode 10-20-30 Kb kami. Kami secara bertahap menyadari bahwa kami perlu menggunakan beberapa modul.
Jenis modul pertama yang Anda temui adalah modul sumber daya. Mereka tidak mengerti apa itu infrastruktur Anda, apa bisnis Anda, di mana dan bagaimana kondisinya. Ini adalah modul-modul yang saya, bersama dengan komunitas open source, kelola, dan kami kemukakan sebagai blok bangunan awal untuk infrastruktur Anda.
Contoh modul sumber daya.
Saat kita memanggil modul sumber daya, kita menentukan dari jalur mana kita harus memuat isinya.
Kami menunjukkan versi mana yang ingin kami unduh.
Kami menyampaikan banyak argumen di sana. Itu saja. Hanya itu yang perlu kita ketahui saat menggunakan modul ini.
Banyak orang yang mengira jika menggunakan versi terbaru maka semuanya akan stabil. Tapi tidak. Infrastruktur harus memiliki versi; kita harus menjawab dengan jelas pada versi mana komponen ini atau itu diterapkan.
Berikut adalah kode yang ada di dalam modul ini. Modul grup keamanan. Di sini gulungannya menuju ke baris ke-640. Membuat sumber daya croup keamanan di Amazon dalam setiap konfigurasi yang memungkinkan adalah tugas yang sangat tidak sepele. Tidaklah cukup hanya dengan membuat grup keamanan dan memberi tahu aturan apa yang harus diterapkan padanya. Ini akan sangat sederhana. Ada jutaan batasan berbeda di Amazon. Misalnya saja jika Anda menggunakan Titik akhir VPC, daftar awalan, berbagai API dan mencoba menggabungkan semua ini dengan yang lainnya, maka Terraform tidak mengizinkan Anda melakukan ini. Dan Amazon API juga tidak mengizinkan hal ini. Oleh karena itu, kita perlu menyembunyikan semua logika buruk ini dalam sebuah modul dan memberikan kode pengguna yang terlihat seperti ini.
Pengguna tidak perlu mengetahui cara pembuatannya di dalam.
Jenis modul kedua, yang terdiri dari modul sumber daya, telah memecahkan masalah yang lebih dapat diterapkan pada bisnis Anda. Seringkali ini adalah tempat yang merupakan perpanjangan dari Terraform dan menetapkan beberapa nilai kaku untuk tag, untuk standar perusahaan. Anda juga dapat menambahkan fungsionalitas di sana yang saat ini Terraform tidak izinkan untuk Anda gunakan. Ini adalah saat ini. Sekarang versi 0.11, yang akan menjadi masa lalu. Namun tetap saja, praprosesor, jsonnet, cookiecutter, dan banyak hal lainnya adalah mekanisme tambahan yang harus digunakan untuk pekerjaan penuh.
Selanjutnya saya akan menunjukkan beberapa contohnya.
Modul infrastruktur dipanggil dengan cara yang persis sama.
Sumber tempat mengunduh konten ditunjukkan.
Sekelompok nilai diteruskan dan diteruskan ke modul ini.
Selanjutnya, di dalam modul ini, sekumpulan modul sumber daya dipanggil untuk membuat VPC atau Application Load Balancer, atau untuk membuat grup keamanan atau untuk klaster Elastic Container Service.
Ada dua jenis modul. Hal ini penting untuk dipahami karena sebagian besar informasi yang saya kelompokkan dalam laporan ini tidak tertulis dalam dokumentasi.
Dan dokumentasi di Terraform saat ini cukup bermasalah karena hanya disebutkan ada fitur-fitur tersebut, Anda bisa menggunakannya. Namun dia tidak menjelaskan cara menggunakan fitur-fitur ini, mengapa lebih baik menggunakannya. Oleh karena itu, banyak sekali orang yang menulis sesuatu yang tidak dapat mereka jalani.
Mari kita lihat cara menulis modul ini selanjutnya. Kemudian kita akan melihat cara memanggilnya dan cara bekerja dengan kodenya.
Registri Terraform -
Tip #0 adalah jangan menulis modul sumber daya. Sebagian besar modul ini sudah ditulis untuk Anda. Seperti yang saya katakan, mereka open source, tidak mengandung logika bisnis Anda, tidak memiliki nilai hardcode untuk alamat IP, kata sandi, dll. Modul ini sangat fleksibel. Dan kemungkinan besar itu sudah ditulis. Ada banyak modul untuk sumber daya dari Amazon. Sekitar 650. Dan sebagian besar berkualitas baik.
Dalam contoh ini, seseorang mendatangi Anda dan berkata, “Saya ingin bisa mengelola database. Buat modul agar saya bisa membuat database." Orang tersebut tidak mengetahui detail implementasi Amazon atau Terraform. Dia hanya mengatakan: "Saya ingin mengelola MSSQL." Artinya, yang kami maksud adalah ia akan memanggil modul kami, meneruskan jenis mesin di sana, dan menunjukkan zona waktu.
Dan seseorang tidak boleh tahu bahwa kita akan membuat dua sumber daya berbeda di dalam modul ini: satu untuk MSSQL, yang kedua untuk yang lainnya, hanya karena di Terraform 0.11 Anda tidak dapat menentukan nilai zona waktu sebagai opsional.
Dan setelah keluar dari modul ini, seseorang cukup menerima alamat. Dia tidak akan tahu dari database mana, dari sumber mana kita membuat semua ini secara internal. Ini adalah elemen penyembunyian yang sangat penting. Dan ini berlaku tidak hanya untuk modul-modul yang bersifat publik dalam sumber terbuka, tetapi juga untuk modul-modul yang akan Anda tulis di dalam proyek dan tim Anda.
Ini adalah argumen kedua, yang cukup penting jika Anda sudah lama menggunakan Terraform. Anda memiliki repositori tempat Anda meletakkan semua modul Terraform untuk perusahaan Anda. Dan wajar jika seiring berjalannya waktu proyek ini akan berkembang hingga berukuran satu atau dua megabita. Ini baik-baik saja.
Namun masalahnya adalah bagaimana Terraform memanggil modul-modul ini. Misalnya, jika Anda memanggil modul untuk membuat setiap pengguna individual, Terraform pertama-tama akan memuat seluruh repositori dan kemudian menavigasi ke folder tempat modul spesifik tersebut berada. Dengan cara ini Anda akan mengunduh satu megabyte setiap kali. Jika Anda mengelola 100 atau 200 pengguna, maka Anda akan mengunduh 100 atau 200 megabyte, lalu masuk ke folder itu. Jadi tentu saja Anda tidak ingin mengunduh banyak hal setiap kali Anda menekan "Terraform init".
Ada dua solusi untuk masalah ini. Yang pertama adalah menggunakan jalur relatif. Dengan cara ini Anda menunjukkan dalam kode bahwa folder tersebut adalah lokal (./). Dan sebelum Anda meluncurkan apa pun, Anda melakukan klon Git dari repositori ini secara lokal. Dengan cara ini Anda melakukannya sekali.
Tentu saja ada banyak kerugiannya. Misalnya, Anda tidak dapat menggunakan pembuatan versi. Dan hal ini terkadang sulit untuk dijalani.
Solusi kedua. Jika Anda memiliki banyak submodul dan sudah memiliki semacam pipeline yang mapan, maka ada proyek MBT, yang memungkinkan Anda mengumpulkan banyak paket berbeda dari monorepositori dan mengunggahnya ke S3. Ini adalah cara yang sangat bagus. Jadi, file iam-user-1.0.0.zip hanya berbobot 1 Kb, karena kode untuk membuat resource ini sangat kecil. Dan itu akan bekerja lebih cepat.
Mari kita bicara tentang apa yang tidak bisa digunakan dalam modul.
Mengapa kejahatan ini ada dalam modul? Hal terburuk adalah menganggap pengguna. Asumsikan pengguna adalah opsi otentikasi penyedia yang dapat digunakan oleh orang yang berbeda. Misalnya, kita semua akan mengasimilasi peran tersebut. Artinya Terraform akan mengambil peran ini. Dan kemudian dengan peran ini ia akan melakukan tindakan lainnya.
Dan kejahatannya adalah jika Vasya suka terhubung ke Amazon dengan satu cara, misalnya menggunakan variabel lingkungan default, dan Petya suka menggunakan kunci bersama yang dia miliki di tempat rahasia, maka Anda tidak dapat menentukan keduanya di terraform. Dan agar mereka tidak mengalami penderitaan, tidak perlu menunjukkan blok ini di modul. Hal ini harus ditunjukkan pada tingkat yang lebih tinggi. Artinya, kita memiliki modul sumber daya, modul infrastruktur, dan komposisi di atasnya. Dan ini harus ditunjukkan di tempat yang lebih tinggi.
Kejahatan kedua adalah pemberi rezeki. Di sini kejahatannya tidak begitu sepele, karena jika Anda menulis kode dan itu berhasil untuk Anda, Anda mungkin berpikir jika itu berhasil, lalu mengapa mengubahnya.
Kelemahannya adalah Anda tidak selalu bisa mengontrol kapan penyedia ini akan diluncurkan. Dan kedua, Anda tidak mengontrol apa yang dimaksud dengan aws ec2, yaitu apakah kita sedang membicarakan Linux atau Windows sekarang. Jadi Anda tidak dapat menulis sesuatu yang berfungsi sama pada sistem operasi berbeda atau untuk kasus pengguna berbeda.
Contoh paling umum, yang juga ditunjukkan dalam dokumentasi resmi, adalah jika Anda menulis aws_instance dan menentukan sekumpulan argumen, maka tidak ada salahnya jika Anda menentukan penyedia “local-exec” di sana dan menjalankan kemungkinan- buku pedoman.
Sebenarnya ya, tidak ada yang salah dengan hal itu. Tetapi Anda akan segera menyadari bahwa hal lokal-exec ini tidak ada, misalnya, di launch_configuration.
Dan ketika Anda menggunakan launch_configuration, dan Anda ingin membuat grup penskalaan otomatis dari satu instance, maka di launch_configuration tidak ada konsep “penyedia”. Ada konsep “data pengguna”.
Oleh karena itu, solusi yang lebih universal adalah dengan menggunakan data pengguna. Dan itu akan diluncurkan baik pada instance itu sendiri, ketika instance tersebut diaktifkan, atau dalam data pengguna yang sama, ketika grup penskalaan otomatis menggunakan launch_configuration ini.
Jika Anda masih ingin menjalankan penyedia, karena merupakan komponen perekatan, ketika satu sumber daya dibuat, pada saat itu Anda perlu menjalankan penyedia, perintah Anda. Ada banyak situasi seperti itu.
Dan sumber daya yang paling tepat untuk ini disebut null_resource. Null_resource adalah sumber daya tiruan yang tidak pernah benar-benar dibuat. Itu tidak menyentuh apa pun, tidak ada API, tidak ada penskalaan otomatis. Tapi ini memungkinkan Anda mengontrol kapan harus menjalankan perintah. Dalam hal ini, perintah dijalankan selama pembuatan.
Link
Ada beberapa tanda. Saya tidak akan membahas semua tanda secara mendetail. Ada artikel tentang ini. Namun jika Anda pernah bekerja dengan Terraform atau menggunakan modul orang lain, Anda sering memperhatikan bahwa banyak modul, seperti kebanyakan kode sumber terbuka, ditulis oleh orang untuk kebutuhan mereka sendiri. Seorang pria menulisnya dan memecahkan masalahnya. Saya menempelkannya di GitHub, biarkan hidup. Itu akan hidup, tetapi jika tidak ada dokumentasi dan contoh di sana, maka tidak ada yang akan menggunakannya. Dan jika tidak ada fungsi yang memungkinkan Anda menyelesaikan lebih dari sekadar tugas spesifiknya, maka tidak ada yang akan menggunakannya juga. Ada banyak cara untuk kehilangan pengguna.
Jika Anda ingin menulis sesuatu agar orang dapat menggunakannya, saya sarankan mengikuti tanda-tanda berikut.
Ini adalah:
- Dokumentasi dan contoh.
- Fungsionalitas penuh.
- Default yang masuk akal.
- Kode bersih.
- Tes.
Tes adalah situasi yang berbeda karena cukup sulit untuk ditulis. Saya lebih percaya pada dokumentasi dan contoh.
Итак, мы посмотрели, как писать модули. Есть два аргумента. Первый, который наиболее важный, это не пиши, если можешь, т. к. кучу-куча людей уже сделали эти задачи до вас. И второй, если все-таки решился, то провайдеры в модулях и provisioner старайся не использовать.
Ini adalah bagian abu-abu dari dokumentasi. Anda sekarang mungkin berpikir: “Ada sesuatu yang tidak jelas. Tidak meyakinkan." Tapi kita akan lihat dalam enam bulan.
Sekarang mari kita bicara tentang cara memanggil modul-modul ini.
Kami memahami bahwa kode kami berkembang seiring waktu. Kami tidak lagi memiliki satu file, kami sudah memiliki 20 file. Semuanya ada dalam satu folder. Atau mungkin dalam lima folder. Mungkin kita mulai mengelompokkannya berdasarkan wilayah, berdasarkan beberapa komponen. Kemudian kami memahami bahwa sekarang kami memiliki beberapa dasar sinkronisasi dan orkestrasi. Artinya, kita harus memahami apa yang harus kita lakukan jika kita mengubah sumber daya jaringan, apa yang harus kita lakukan dengan sumber daya lainnya, bagaimana menyebabkan ketergantungan ini, dll.
Ada dua ekstrem. Ekstrem pertama adalah semuanya menjadi satu. Kami memiliki satu file induk. Untuk saat ini, ini adalah praktik terbaik resmi di situs Terraform.
Tapi sekarang ditulis sudah usang dan dihapus. Seiring waktu, komunitas Terraform menyadari bahwa ini bukanlah praktik terbaik, karena orang-orang mulai menggunakan proyek ini dengan cara yang berbeda. Dan ada masalah. Misalnya, ketika kita mencantumkan semua dependensi di satu tempat. Ada situasi ketika kita mengeklik “Rencana Terraform” dan hingga Terraform memperbarui status semua sumber daya, banyak waktu dapat berlalu.
Waktu yang banyak misalnya 5 menit. Bagi sebagian orang, ini adalah waktu yang lama. Saya pernah melihat kasus yang memerlukan waktu 15 menit. API AWS menghabiskan waktu 15 menit untuk mencoba mencari tahu apa yang terjadi dengan status setiap sumber daya. Ini adalah wilayah yang sangat luas.
Dan, tentu saja, masalah terkait akan muncul ketika Anda ingin mengubah sesuatu di satu tempat, lalu Anda menunggu 15 menit, dan ini memberi Anda gambaran tentang beberapa perubahan. Anda meludah, menulis "Ya", dan ada yang tidak beres. Ini adalah contoh yang sangat nyata. Terraform tidak mencoba melindungi Anda dari masalah. Artinya, tulis apa yang Anda inginkan. Akan ada masalah – masalah Anda. Meskipun Terraform 0.11 tidak mencoba membantu Anda dengan cara apa pun. Ada tempat menarik tertentu di 0.12 yang memungkinkan Anda berkata: "Vasya, kamu benar-benar menginginkan ini, bisakah kamu sadar?"
Cara kedua adalah dengan memperkecil area ini, yaitu panggilan dari suatu tempat bisa jadi kurang terkoneksi dari tempat lain.
Satu-satunya masalah adalah Anda perlu menulis lebih banyak kode, yaitu Anda perlu mendeskripsikan variabel dalam sejumlah besar file dan memperbaruinya. Beberapa orang tidak menyukainya. Ini normal bagi saya. Dan beberapa orang berpikir: “Mengapa menulis ini di tempat yang berbeda, saya akan meletakkan semuanya di satu tempat.” Hal ini mungkin saja terjadi, tetapi ini adalah pilihan ekstrem kedua.
Siapa yang tinggal di satu tempat? Satu, dua, tiga orang, yaitu seseorang yang menggunakannya.
Dan siapa yang memanggil satu komponen tertentu, satu blok atau satu modul infrastruktur? Lima hingga tujuh orang. Ini keren.
Jawaban paling umum ada di tengah-tengah. Jika proyeknya besar, maka Anda akan sering menghadapi situasi di mana tidak ada solusi yang cocok dan tidak semuanya berhasil, sehingga Anda berakhir dengan campuran. Tidak ada yang salah dengan hal ini, asalkan Anda memahami bahwa keduanya memiliki kelebihan.
Jika ada sesuatu yang berubah di tumpukan VPC dan Anda ingin menerapkan perubahan ini ke EC2, yaitu Anda ingin memperbarui grup penskalaan otomatis karena Anda memiliki subnet baru, maka saya menyebutnya orkestrasi ketergantungan semacam ini. Ada beberapa solusi: siapa yang menggunakan apa?
Saya dapat menyarankan solusi apa yang ada. Anda dapat menggunakan Terraform untuk melakukan keajaiban, atau Anda dapat menggunakan makefile untuk menggunakan Terraform. Dan lihat apakah ada yang berubah di sana, Anda dapat meluncurkannya di sini.
Bagaimana Anda menyukai keputusan ini? Adakah yang percaya ini adalah solusi yang keren? Aku melihat senyuman, rupanya keraguan telah merayap masuk.
Tentu saja, jangan mencobanya di rumah. Terraform tidak pernah dirancang untuk dijalankan dari Terraform.
Dalam salah satu laporan mereka mengatakan kepada saya: “Tidak, ini tidak akan berhasil.” Intinya adalah itu tidak akan berhasil. Meskipun terlihat sangat mengesankan ketika Anda dapat meluncurkan Terraform dari Terraform, lalu Terraform, Anda tidak boleh melakukan itu. Terraform harus selalu dimulai dengan sangat mudah.
Jika Anda memerlukan orkestrasi panggilan ketika sesuatu berubah di satu tempat, maka ada Terragrunt.
Terragrunt adalah utilitas, tambahan untuk Terraform, yang memungkinkan Anda mengoordinasikan dan mengatur panggilan ke modul infrastruktur.
File konfigurasi Terraform pada umumnya terlihat seperti ini.
Anda menentukan modul spesifik mana yang ingin Anda panggil.
Ketergantungan apa yang dimiliki modul?
Dan argumen apa yang diterima modul ini. Itu saja yang perlu diketahui tentang Terragrunt.
Dokumentasinya ada di sana, dan ada 1 bintang di GitHub. Namun dalam banyak kasus, inilah yang perlu Anda ketahui. Dan ini sangat mudah diterapkan di perusahaan yang baru mulai bekerja dengan Terraform.
Jadi orkestrasinya adalah Terragrunt. Ada pilihan lain.
Sekarang mari kita bicara tentang cara bekerja dengan kode.
Jika Anda perlu menambahkan fitur baru ke kode Anda, dalam banyak kasus, hal ini mudah dilakukan. Anda sedang menulis sumber daya baru, semuanya sederhana.
Jika Anda memiliki beberapa sumber daya yang Anda buat sebelumnya, misalnya, Anda mempelajari Terraform setelah Anda membuka akun AWS dan ingin menggunakan sumber daya yang sudah Anda miliki, maka sebaiknya Anda memperluas modul Anda dengan cara ini, sehingga itu mendukung penggunaan sumber daya yang ada.
Dan mendukung pembuatan sumber daya baru menggunakan sumber daya blok.
Pada keluaran kami selalu mengembalikan id keluaran tergantung pada apa yang digunakan.
Masalah kedua yang sangat signifikan di Terraform 0.11 adalah bekerja dengan daftar.
Kesulitannya adalah jika kita memiliki daftar pengguna seperti itu.
Dan ketika kita membuat pengguna ini menggunakan sumber daya blok, semuanya berjalan dengan baik. Kami menelusuri seluruh daftar, membuat file untuk masing-masingnya. Semuanya baik-baik saja. Dan kemudian, misalnya, pengguna3 yang berada di tengah harus dihapus dari sini, maka semua sumber daya yang dibuat setelahnya akan dibuat ulang karena indeksnya akan berubah.
Bekerja dengan daftar dalam lingkungan stateful. Apa yang dimaksud dengan lingkungan stateful? Ini adalah situasi di mana nilai baru dibuat ketika sumber daya ini dibuat. Misalnya, AWS Access Key atau AWS Secret Key, yaitu saat kita membuat pengguna, kita menerima Access atau Secret Key baru. Dan setiap kali kami menghapus pengguna, pengguna tersebut akan memiliki kunci baru. Tapi ini bukan feng shui, karena pengguna tidak akan mau berteman dengan kita jika kita membuatkan pengguna baru untuknya setiap kali seseorang keluar dari tim.
Ini adalah solusinya. Ini adalah kode yang ditulis dalam Jsonnet. Jsonnet adalah bahasa templating dari Google.
Perintah ini memungkinkan Anda untuk menerima templat ini dan sebagai keluarannya ia mengembalikan file json yang dibuat sesuai dengan templat Anda.
Templatnya terlihat seperti ini.
Terraform memungkinkan Anda bekerja dengan HCL dan Json dengan cara yang sama, jadi jika Anda memiliki kemampuan untuk menghasilkan Json, Anda dapat memasukkannya ke Terraform. File dengan ekstensi .tf.json akan berhasil diunduh.
Dan kemudian kita mengerjakannya seperti biasa: terraform init, terramorm apply. Dan kami membuat dua pengguna.
Sekarang kami tidak takut jika ada yang keluar dari tim. Kami hanya akan mengedit file json. Vasya Pupkin pergi, Petya Pyatochkin tetap tinggal. Petya Pyatochkin tidak akan menerima kunci baru.
Mengintegrasikan Terraform dengan alat lain sebenarnya bukan tugas Terraform. Terraform dibuat sebagai platform untuk membuat sumber daya dan hanya itu. Dan segala sesuatu yang muncul kemudian bukanlah urusan Terraform. Dan tidak perlu menenunnya di sana. Ada Ansible, yang melakukan semua yang Anda butuhkan.
Namun situasi muncul ketika kita ingin memperluas Terraform dan memanggil beberapa perintah setelah sesuatu selesai.
Cara pertama. Kami membuat output tempat kami menulis perintah ini.
Dan kemudian kita memanggil perintah ini dari keluaran shell terraform dan menentukan nilai yang kita inginkan. Jadi, perintah dijalankan dengan semua nilai yang diganti. Sangat nyaman.
Cara kedua. Ini adalah penggunaan null_resource tergantung pada perubahan infrastruktur kami. Kita dapat memanggil exe lokal yang sama segera setelah ID beberapa sumber daya berubah.
Tentu saja, semua ini berjalan lancar di atas kertas, karena Amazon, seperti semua penyedia publik lainnya, memiliki banyak kasus tersendiri.
Kasus paling umum yang terjadi adalah ketika Anda membuka akun AWS, wilayah mana yang Anda gunakan menjadi penting; apakah fitur ini diaktifkan di sana; mungkin Anda membukanya setelah Desember 2013; mungkin Anda menggunakan default di VPC dll. Ada banyak batasan. Dan Amazon menyebarkannya ke seluruh dokumentasi.
Ada beberapa hal yang saya sarankan untuk dihindari.
Untuk memulai, hindari semua argumen non-rahasia di dalam paket Terraform atau Terraform CLI. Semua ini dapat dimasukkan ke dalam file tfvars atau ke dalam variabel lingkungan.
Namun Anda tidak perlu menghafal seluruh perintah ajaib ini. Rencana Terraform – var dan kita berangkat. Variabel pertama adalah var, variabel kedua adalah var, variabel ketiga, keempat. Prinsip terpenting dari infrastruktur sebagai kode yang paling sering saya gunakan adalah hanya dengan melihat kode tersebut, saya akan memiliki pemahaman yang jelas tentang apa yang diterapkan di sana, dalam kondisi apa, dan dengan nilai apa. Oleh karena itu, saya tidak perlu membaca dokumentasi atau bertanya kepada Vasya parameter apa yang dia gunakan untuk membuat cluster kami. Saya hanya perlu membuka file dengan ekstensi tfvars, yang sering kali cocok dengan lingkungannya, dan melihat semuanya di sana.
Selain itu, jangan gunakan argumen target untuk mengurangi cakupan. Untuk ini, lebih mudah menggunakan modul infrastruktur kecil.
Selain itu, tidak perlu membatasi dan meningkatkan paralelisme. Jika saya memiliki 150 sumber daya dan saya ingin meningkatkan paralelisme Amazon dari default 10 menjadi 100, kemungkinan besar ada yang tidak beres. Atau mungkin sekarang berjalan baik, tetapi ketika Amazon mengatakan Anda melakukan terlalu banyak panggilan, Anda akan mendapat masalah.
Terraform akan mencoba memulai ulang sebagian besar masalah ini, tetapi Anda hampir tidak mencapai apa pun. Parallelism=1 adalah hal penting untuk digunakan jika Anda menemukan beberapa bug di dalam API AWS atau di dalam penyedia Terraform. Dan kemudian Anda perlu menentukan: parallelism=1 dan menunggu hingga Terraform menyelesaikan satu panggilan, lalu panggilan kedua, lalu panggilan ketiga. Dia akan meluncurkannya satu per satu.
Orang sering bertanya kepada saya, “Mengapa menurut saya ruang kerja Terraform itu jahat?” Saya yakin prinsip infrastruktur sebagai kode adalah melihat infrastruktur apa yang telah dibuat dan apa nilainya.
Ruang kerja tidak dibuat oleh pengguna. Ini tidak berarti bahwa pengguna menulis masalah di GitHub bahwa kita tidak dapat hidup tanpa ruang kerja Terraform. Tidak, tidak seperti ini. Terraform Enterprise adalah solusi komersial. Terraform dari HashiCorp memutuskan bahwa kami membutuhkan ruang kerja, jadi kami menyimpannya. Saya merasa lebih mudah untuk meletakkannya di folder terpisah. Maka akan ada lebih banyak file, tetapi akan lebih jelas.
Bagaimana cara bekerja dengan kode tersebut? Faktanya, bekerja dengan daftar adalah satu-satunya hal yang menyusahkan. Dan gunakan Terraform dengan lebih mudah. Ini bukanlah hal yang akan melakukan segalanya dengan baik untuk Anda. Tidak perlu memasukkan semua yang tertulis dalam dokumentasi di sana.
Topik laporannya ditulis “untuk masa depan.” Saya akan membicarakan hal ini secara singkat. Untuk kedepannya berarti 0.12 akan segera dirilis.
0.12 adalah banyak hal baru. Jika Anda berasal dari pemrograman biasa, maka Anda melewatkan semua jenis blok dinamis, loop, operasi perbandingan yang benar dan bersyarat, di mana sisi kiri dan kanan tidak dihitung secara bersamaan, tetapi tergantung pada situasinya. Anda sangat merindukannya, jadi 0.12 akan menyelesaikannya untuk Anda.
Tetapi! Jika Anda menulis lebih sedikit dan lebih sederhana, menggunakan modul siap pakai dan solusi pihak ketiga, maka Anda tidak perlu menunggu dan berharap 0.12 akan datang dan memperbaiki segalanya untuk Anda.
Terima kasih atas laporannya! Anda berbicara tentang infrastruktur sebagai kode dan secara harfiah mengatakan satu kata tentang pengujian. Apakah tes diperlukan dalam modul? Tanggung jawab siapa ini? Apakah saya perlu menulisnya sendiri atau menjadi tanggung jawab modul?
Tahun depan akan diisi dengan laporan bahwa kami telah memutuskan untuk menguji semuanya. Apa yang harus diuji adalah pertanyaan terbesar. Ada banyak ketergantungan, banyak batasan dari penyedia yang berbeda. Ketika Anda dan saya sedang berbicara dan Anda berkata: "Saya perlu tes", maka saya bertanya: "Apa yang akan Anda tes?" Anda mengatakan bahwa Anda akan melakukan tes di wilayah Anda. Lalu saya katakan bahwa ini tidak berhasil di wilayah saya. Artinya, kita bahkan tidak akan bisa menyetujui hal ini. Belum lagi banyak kendala teknis. Artinya, bagaimana menulis tes tersebut agar memadai.
Saya aktif meneliti topik ini, yaitu cara menghasilkan pengujian secara otomatis berdasarkan infrastruktur yang Anda tulis. Artinya, jika Anda menulis kode ini, maka saya perlu menjalankannya, berdasarkan ini saya dapat membuat tes.
adalah salah satu perpustakaan yang paling sering disebutkan yang memungkinkan Anda menulis tes integrasi untuk Terraform. Ini adalah salah satu utilitasnya. Saya lebih suka tipe DSL, misalnya rspec.
Anton, terima kasih atas laporannya! Nama saya Valery. Izinkan saya mengajukan sedikit pertanyaan filosofis. Ada, secara kondisional, penyediaan, ada penerapan. Provisioning membuat infrastruktur saya, dalam deployment kita mengisinya dengan sesuatu yang berguna, misalnya server, aplikasi, dll. Dan di kepala saya Terraform lebih untuk provisi, dan Ansible lebih untuk deployment, karena Ansible juga untuk infrastruktur fisik. memungkinkan Anda menginstal nginx, Postgres. Namun pada saat yang sama, Ansible tampaknya mengizinkan penyediaan, misalnya, sumber daya Amazon atau Google. Namun Terraform juga memungkinkan Anda menerapkan beberapa perangkat lunak menggunakan modulnya. Dari sudut pandang Anda, apakah ada semacam batas antara Terraform dan Ansible, di mana dan apa yang lebih baik untuk digunakan? Atau misalnya menurut Anda Ansible sudah menjadi sampah, sebaiknya coba gunakan Terraform untuk semuanya?
Pertanyaan bagus, Valery. Saya yakin Terraform tidak berubah tujuannya sejak 2014. Itu diciptakan untuk infrastruktur dan mati untuk infrastruktur. Kami masih memiliki dan akan memerlukan manajemen konfigurasi. Tantangannya adalah ada data pengguna di dalam launch_configuration. Dan di sana Anda menarik Ansible, dll. Ini adalah perbedaan standar yang paling saya sukai.
Jika kita berbicara tentang infrastruktur yang indah, maka ada utilitas seperti Packer yang mengumpulkan gambar ini. Lalu Terraform menggunakan sumber data untuk menemukan gambar ini dan memperbarui konfigurasi_luncurannya. Artinya, dengan cara ini pipelinenya adalah kita menarik Tracker terlebih dahulu, lalu menarik Terraform. Dan jika terjadi build, maka terjadi perubahan baru.
Halo! Terima kasih atas laporannya! Nama saya Misha, perusahaan RBS. Anda dapat menghubungi Ansible melalui penyedia saat membuat sumber daya. Ansible juga memiliki topik yang disebut inventaris dinamis. Dan Anda dapat memanggil Terraform terlebih dahulu, lalu memanggil Ansible, yang akan mengambil sumber daya dari negara bagian dan menjalankannya. Apa yang lebih baik?
Orang-orang menggunakan keduanya dengan kesuksesan yang sama. Bagi saya, inventaris dinamis di Ansible adalah hal yang nyaman, jika kita tidak berbicara tentang grup penskalaan otomatis. Karena di grup autoscaling kita sudah memiliki toolkit sendiri yaitu launch_configuration. Di launch_configuration kami mencatat semua yang perlu diluncurkan saat kami membuat sumber daya baru. Oleh karena itu, dengan Amazon, menggunakan inventaris dinamis dan membaca file Terraform ts, menurut saya, berlebihan. Dan jika Anda menggunakan alat lain yang tidak memiliki konsep "grup penskalaan otomatis", misalnya, Anda menggunakan DigitalOcean atau penyedia lain yang tidak memiliki grup penskalaan otomatis, maka di sana Anda harus menarik API secara manual, mencari alamat IP, membuat file inventaris dinamis, dan Ansible sudah menjelajahinya. Artinya, untuk Amazon ada launch_configuration, dan untuk yang lainnya ada inventaris dinamis.
Sumber: www.habr.com