Tampaknya pengembang Terraform menawarkan praktik terbaik yang cukup nyaman untuk bekerja dengan infrastruktur AWS. Hanya ada nuansa. Seiring waktu, jumlah lingkungan bertambah, masing-masing dengan fiturnya sendiri. Hampir salinan tumpukan aplikasi muncul di wilayah tetangga. Dan kode Terraform perlu disalin dan diedit dengan hati-hati sesuai dengan persyaratan baru atau dibuat menjadi kepingan salju.
Laporan saya tentang pola di Terraform untuk memerangi kekacauan dan rutinitas manual pada proyek besar dan panjang.
Video:
Saya berusia 40 tahun, saya telah berkecimpung di bidang IT selama 20 tahun. Saya telah bekerja untuk Ixtens selama 12 tahun. Kami terlibat dalam pengembangan yang didorong oleh e-commerce. Dan saya telah mempraktikkan praktik DevOps selama 5 tahun.
Cerita saya akan tentang pengalaman saya dalam sebuah proyek di sebuah perusahaan yang namanya tidak akan saya sebutkan, bersembunyi di balik perjanjian kerahasiaan.
Angka-angka pada slide diberikan untuk memahami ruang lingkup proyek. Dan semua yang akan saya katakan selanjutnya berhubungan dengan Amazon.
Saya bergabung dengan proyek ini 4 tahun yang lalu. Dan pemfaktoran ulang infrastruktur berjalan lancar karena proyek telah berkembang. Dan pola-pola yang dulunya sudah tidak muat lagi. Dan mengingat pertumbuhan proyek yang direncanakan, sesuatu yang baru perlu diciptakan.
Terima kasih kepada Matvey yang kemarin menceritakan apa yang terjadi di Dodo Pizza. Inilah yang terjadi di sini 4 tahun lalu.
Pengembang datang dan mulai membuat kode infrastruktur.
Alasan paling jelas mengapa hal ini diperlukan adalah waktu untuk memasarkan. Penting untuk memastikan bahwa tim DevOps tidak mengalami hambatan saat diluncurkan. Dan antara lain, Terraform dan Puppet digunakan di level pertama.
Terraform adalah proyek sumber terbuka dari HashiCorp. Dan bagi yang belum tahu apa itu, beberapa slide berikutnya.
Infrastruktur sebagai kode berarti kita dapat mendeskripsikan infrastruktur kita dan meminta beberapa robot untuk memastikan bahwa kita mendapatkan sumber daya yang kita jelaskan.
Misalnya kita memerlukan mesin virtual. Kami akan menjelaskan, menambahkan beberapa parameter yang diperlukan.
Setelah itu, kami akan mengonfigurasi akses ke Amazon di konsol. Dan minta rencana Terraform. Rencana Terraform akan mengatakan: "Oke, untuk sumber daya Anda, kami dapat melakukan hal ini." Dan setidaknya satu sumber daya akan ditambahkan. Dan tidak ada perubahan yang diharapkan.
Setelah semuanya cocok untuk Anda, Anda dapat meminta Terraform melamar dan Terraform akan membuatkan instance untuk Anda, dan Anda akan mendapatkan mesin virtual di cloud Anda.
Selanjutnya, proyek kami berkembang. Kami menambahkan beberapa perubahan di sana. Kami meminta lebih banyak contoh, kami menambahkan 53 entri.
Dan kami ulangi. Silakan rencanakan. Kami melihat perubahan apa yang direncanakan. Menerapkan. Dan infrastruktur kita pun berkembang.
Terraform menggunakan yang namanya file status. Artinya, dia menyimpan semua perubahan yang masuk ke Amazon dalam sebuah file di mana untuk setiap sumber daya yang Anda jelaskan, terdapat sumber daya terkait yang dibuat di Amazon. Jadi, ketika deskripsi sumber daya berubah, Terraform tahu persis apa yang perlu diubah di Amazon.
File negara ini awalnya hanya file. Dan kami menyimpannya di Git, yang sangat merepotkan. Terus menerus ada yang lupa melakukan perubahan, dan banyak terjadi konflik.
Sekarang dimungkinkan untuk menggunakan backend, mis. Terraform ditunjukkan di keranjang mana, dengan kunci mana file status harus disimpan. Dan Terraform sendiri akan mengurus file status ini, melakukan semua keajaiban dan mengembalikan hasil akhirnya.
Infrastruktur kita semakin berkembang. Ini kode kami. Dan sekarang kami tidak ingin hanya membuat mesin virtual, kami ingin memiliki lingkungan pengujian.
Terraform memungkinkan Anda membuat sesuatu seperti modul, yaitu mendeskripsikan hal yang sama di beberapa folder.
Dan, misalnya, dalam pengujian, panggil modul ini dan dapatkan hal yang sama seperti jika kita menerapkan Terraform di modul itu sendiri. Berikut adalah kode untuk pengujian.
Untuk produksi, kami dapat mengirimkan beberapa perubahan ke sana, karena dalam pengujian kami tidak memerlukan instance besar, dalam produksi, instance besar akan berguna.
Dan kemudian saya akan kembali ke proyek. Itu tugas yang sulit, infrastruktur yang direncanakan sangat besar. Dan perlu untuk menempatkan semua kode sedemikian rupa sehingga nyaman bagi semua orang: bagi mereka yang melakukan pemeliharaan pada kode ini, dan bagi mereka yang membuat perubahan. Dan direncanakan bahwa pengembang mana pun dapat pergi dan memperbaiki infrastruktur sesuai kebutuhan untuk bagian platformnya.
Ini adalah pohon direktori yang direkomendasikan oleh HashiCorp jika Anda memiliki proyek besar dan masuk akal untuk membagi seluruh infrastruktur menjadi beberapa bagian kecil, dan mendeskripsikan setiap bagian dalam folder terpisah.
Memiliki perpustakaan sumber daya yang luas, Anda dapat melakukan hal yang sama dalam pengujian dan produksi.
Dalam kasus kami, ini tidak sepenuhnya cocok, karena tumpukan pengujian untuk pengembang atau pengujian perlu diperoleh dengan cara yang lebih sederhana. Dan saya tidak ingin menelusuri folder dan menerapkannya dalam urutan yang benar, dan khawatir basisnya akan naik, dan kemudian instance yang menggunakan basis ini akan naik. Oleh karena itu, semua pengujian diluncurkan dari satu folder. Modul yang sama dipanggil di sana, tetapi semuanya berjalan dalam satu kali proses.
Terraform menangani semua dependensi. Dan itu selalu membuat sumber daya dalam urutan itu sehingga Anda bisa mendapatkan alamat IP, misalnya, dari instance yang baru dibuat, dan mendapatkan alamat IP ini di entri rute53.
Apalagi platformnya sangat besar. Dan menjalankan test stack, meskipun selama satu jam, meskipun selama 8 jam, adalah bisnis yang cukup mahal.
Dan kami telah mengotomatiskan bisnis ini. Dan pekerjaan Jenkins memungkinkan tumpukan berjalan. Penting untuk meluncurkan permintaan tarik di dalamnya dengan perubahan yang ingin diuji oleh pengembang, menentukan semua opsi, komponen, dan ukuran yang diperlukan. Jika dia ingin pengujian kinerja, maka dia dapat mengambil lebih banyak contoh. Jika dia hanya perlu memeriksa apakah ada formulir yang terbuka, dia bisa mulai dengan upah minimum. Dan juga menunjukkan apakah sebuah cluster diperlukan atau tidak, dll.
Dan kemudian Jenkins memasukkan skrip shell yang sedikit mengubah kode di folder Terraform. Menghapus file yang tidak perlu, menambahkan file yang diperlukan. Dan kemudian, dengan satu kali penerapan Terraform, tumpukannya meningkat.
Lalu ada langkah lain yang tidak ingin saya lakukan.
Karena kenyataan bahwa untuk pengujian kami memerlukan lebih banyak opsi daripada dalam produksi, kami harus membuat salinan modul sehingga dalam salinan ini kami dapat menambahkan fitur-fitur yang hanya diperlukan dalam pengujian.
Dan kebetulan dalam pengujian, sepertinya Anda ingin menguji perubahan yang pada akhirnya akan masuk ke produksi. Namun kenyataannya, satu hal telah diuji, dan sesuatu yang sedikit berbeda digunakan dalam produksi. Dan terjadi sedikit terobosan pada pola sehingga dalam produksi semua perubahan diterapkan oleh tim operasi. Dan terkadang ternyata perubahan-perubahan yang seharusnya berlangsung dari pengujian hingga produksi tetap ada di versi yang berbeda.
Selain itu, ada masalah sehingga layanan baru ditambahkan, yang sedikit berbeda dari layanan yang sudah ada. Dan alih-alih memodifikasi modul yang sudah ada, Anda harus membuat salinannya dan menambahkan perubahan yang diperlukan.
Faktanya, Terraform bukanlah bahasa yang sebenarnya. Ini adalah sebuah deklarasi. Jika kita perlu mendeklarasikan sesuatu, maka kita mendeklarasikannya. Dan semuanya berhasil.
Pada titik tertentu, ketika membahas salah satu permintaan tarik saya, salah satu rekan saya mengatakan bahwa tidak perlu membuat kepingan salju. Aku bertanya-tanya apa maksudnya. Ada fakta ilmiah bahwa di dunia tidak ada dua kepingan salju yang identik, semuanya kecil, tetapi berbeda. Dan begitu saya mendengarnya, saya langsung merasakan beban penuh dari kode Terraform. Karena ketika diharuskan berpindah dari versi ke versi, Terraform memerlukan perubahan rantai pemutusan, yaitu kode tidak lagi kompatibel dengan versi berikutnya. Dan saya harus membuat permintaan tarik, yang mencakup hampir setengah file di infrastruktur, untuk membawa infrastruktur ke versi Terraform berikutnya.
Dan setelah kepingan salju muncul, semua kode Terraform yang kami miliki berubah menjadi tumpukan salju yang sangat besar.
Bagi pengembang eksternal yang berada di luar operasi, hal itu tidak terlalu menjadi masalah baginya, karena ia membuat permintaan tarik, sumber dayanya dimulai. Dan itu saja, itu bukan urusannya. Dan tim DevOps yang memastikan semuanya baik-baik saja perlu melakukan semua perubahan ini. Dan biaya dari perubahan ini meningkat sangat, sangat banyak dengan setiap tambahan kepingan salju.
Ada sebuah cerita tentang bagaimana seorang mahasiswa di sebuah seminar menggambar dua lingkaran sempurna dengan kapur di papan tulis. Dan sang guru terkejut bagaimana dia bisa menggambar dengan lancar tanpa kompas. Siswa tersebut menjawab: “Sederhana sekali, saya menghabiskan dua tahun di tentara untuk membuat penggiling daging.”
Dan dari empat tahun saya terlibat dalam proyek ini, saya telah mengerjakan Terraform selama sekitar dua tahun. Dan tentu saja saya punya beberapa trik, beberapa saran tentang cara menyederhanakan kode Terraform, bekerja dengannya seperti bahasa pemrograman, dan mengurangi beban pengembang yang harus selalu memperbarui kode ini.
Hal pertama yang ingin saya mulai adalah Symlinks. Terraform memiliki banyak kode berulang. Misalnya, menelepon penyedia di hampir setiap titik tempat kita membuat infrastruktur adalah hal yang sama. Dan masuk akal untuk menempatkannya di ayah yang terpisah. Dan dimanapun penyedia diharuskan membuat Symlinks ke file ini.
Misalnya, Anda menggunakan peran asumsi dalam produksi, yang memungkinkan Anda mendapatkan hak akses ke beberapa akun Amazon eksternal. Dan dengan mengubah satu file, semua file tersisa yang ada di pohon sumber daya akan memiliki hak yang diperlukan sehingga Terraform mengetahui segmen Amazon mana yang akan diakses.
Di mana Symlinks tidak berfungsi? Seperti yang saya katakan, Terraform memiliki file status. Dan mereka sangat, sangat keren. Namun faktanya Terraform menginisialisasi backend pada yang pertama. Dan dia tidak dapat menggunakan variabel apa pun dalam parameter ini, variabel tersebut harus selalu ditulis dalam teks.
Dan akibatnya, ketika seseorang membuat sumber daya baru, dia menyalin sebagian kode dari folder lain. Dan dia bisa membuat kesalahan dengan kunci atau embernya. Misalnya, dia membuat kotak pasir dari kotak pasir, lalu membuatnya dalam produksi. Jadi mungkin saja ember dalam produksi akan digunakan dari kotak pasir. Tentu saja mereka akan menemukannya dengan cepat. Ada kemungkinan untuk memperbaikinya, namun tetap saja ini hanya membuang-buang waktu dan, sampai batas tertentu, sumber daya.
Apa yang bisa kita lakukan selanjutnya? Sebelum bekerja dengan Terraform, Anda perlu menginisialisasinya. Saat inisialisasi, Terraform mengunduh semua plugin. Pada titik tertentu, mereka berpisah dari arsitektur monolit ke arsitektur layanan mikro. Dan Anda selalu perlu melakukan Terraform init agar dapat menarik semua modul, semua plugin.
Dan Anda bisa menggunakan skrip shell, yang pertama, bisa mendapatkan semua variabel. Skrip shell tidak terbatas. Dan yang kedua, jalannya. Jika kita selalu menggunakan jalur yang ada di repositori sebagai kunci ke file status, maka kesalahan akan dikecualikan di sini.
Di mana mendapatkan datanya? berkas JSON. Terraform memungkinkan Anda menulis infrastruktur tidak hanya dalam hcl (Bahasa Konfigurasi HashiCorp), tetapi juga dalam JSON.
JSON mudah dibaca dari skrip shell. Oleh karena itu, Anda dapat meletakkan file konfigurasi dengan ember di suatu tempat. Dan gunakan bucket ini dalam kode Terraform dan skrip shell untuk inisialisasi.
Mengapa penting untuk memiliki bucket untuk Terraform? Karena ada yang namanya file status jarak jauh. Artinya, ketika saya meningkatkan beberapa sumber daya, untuk memberi tahu Amazon: “Tolong tingkatkan instance,” saya perlu menentukan banyak parameter yang diperlukan.
Dan pengidentifikasi ini disimpan di beberapa folder lain. Dan saya dapat mengambilnya dan berkata: "Terraform, silakan jalankan file status dari sumber daya itu dan berikan saya pengidentifikasi ini." Dan dengan demikian terjadilah semacam penyatuan antar wilayah atau lingkungan yang berbeda.
Tidak selalu mungkin untuk menggunakan file status jarak jauh. Misalnya, Anda membuat VPC secara manual. Dan kode Terraform yang membuat VPC tersebut membuat VPC yang berbeda-beda sehingga membutuhkan waktu yang sangat lama dan harus menyesuaikan satu sama lain, sehingga Anda dapat menggunakan trik berikut.
Artinya, untuk membuat modul yang seolah-olah membuat VPC dan memberi Anda pengidentifikasi, namun sebenarnya hanya ada file dengan nilai hardcode yang dapat digunakan untuk membuat instance yang sama.
Tidak selalu perlu menyimpan file negara di cloud. Misalnya, saat menguji modul, Anda dapat menggunakan inisialisasi backend, ketika file akan disimpan hanya di disk pada saat pengujian.
Sekarang sedikit tentang pengujian. Apa yang bisa diuji di Terraform? Mungkin banyak kemungkinannya, tapi saya akan membahas 4 hal ini.
HashiCorp memiliki pemahaman tentang cara memformat kode Terraform. Dan Terraform fmt memungkinkan Anda memformat kode yang Anda edit sesuai dengan keyakinan ini. Oleh karena itu, pengujian harus memeriksa apakah formatnya sesuai dengan apa yang diwariskan HashiCorp, sehingga tidak perlu mengubah lokasi tanda kurung, dll.
Yang berikutnya adalah validasi Terraform. Ini melakukan lebih dari sekedar pemeriksaan sintaksis - ala, apakah semua tanda kurung dipasangkan. Apa yang penting di sini? Kami memiliki infrastruktur yang sangat lemah. Ini memiliki banyak folder berbeda. Dan di masing-masingnya Anda perlu menjalankan validasi Terraform.
Oleh karena itu, untuk mempercepat pengujian, kami menjalankan beberapa proses secara paralel menggunakan paralel.
Paralel adalah hal yang sangat keren, gunakanlah.
Namun setiap kali Terraform diinisialisasi, ia masuk ke HashiCorp dan bertanya, “Plugin terbaru apa? Dan plugin yang saya miliki di cache - apakah itu yang satu atau bukan? Dan itu melambat di setiap langkah.
Jika Terraform memberi tahu Anda di mana letak pluginnya, Terraform akan berkata: “Oke, ini mungkin yang terbaru. Saya tidak akan pergi ke mana pun, saya akan segera mulai memvalidasi kode Terraform Anda."
Untuk mengisi folder dengan plugin yang diperlukan, kami memiliki kode Terraform yang sangat sederhana yang hanya perlu diinisialisasi. Di sini, tentu saja, Anda perlu menentukan semua penyedia yang berpartisipasi dalam kode Anda, jika tidak, Terraform akan berkata: "Saya tidak tahu penyedia mana pun, karena tidak ada dalam cache."
Berikutnya adalah rencana Terraform. Seperti yang saya katakan, pembangunan bersifat siklus. Kami membuat perubahan pada kode. Dan kemudian Anda perlu mencari tahu perubahan apa yang direncanakan untuk infrastruktur tersebut.
Dan ketika infrastrukturnya sangat, sangat besar, Anda dapat mengubah satu modul, memperbaiki beberapa lingkungan pengujian atau wilayah tertentu, dan merusak lingkungan tetangga. Oleh karena itu, rencana Terraform harus dibuat untuk seluruh infrastruktur dan menunjukkan perubahan apa yang direncanakan.
Anda bisa melakukannya dengan cara yang cerdas. Misalnya, kami menulis skrip Python yang menyelesaikan dependensi. Dan bergantung pada apa yang telah diubah: modul Terraform atau hanya komponen tertentu, modul ini membuat rencana untuk semua folder yang bergantung.
Rencana Terraform harus dilakukan berdasarkan permintaan. Setidaknya itulah yang kami lakukan.
Pengujian, tentu saja, baik dilakukan untuk setiap perubahan, untuk setiap komitmen, namun rencana adalah hal yang cukup mahal. Dan kami mengatakan dalam permintaan tarik: "Tolong beri saya rencananya." Robot dimulai. Dan kirimkan ke komentar atau untuk melampirkan semua rencana yang diharapkan dari perubahan Anda.
Rencananya adalah hal yang agak mahal. Perlu waktu karena Terraform pergi ke Amazon dan bertanya, “Apakah instance ini masih ada? Apakah skala otomatis ini memiliki parameter yang persis sama?”. Dan untuk mempercepatnya, Anda bisa menggunakan parameter seperti refresh=false. Artinya Terraform akan menurunkan status S3. Dan akan percaya bahwa negara bagian tersebut akan sama persis dengan apa yang ada di Amazon.
Paket Terraform seperti itu jauh lebih cepat, tetapi statusnya harus sesuai dengan infrastruktur Anda, misalnya, di suatu tempat, suatu saat penyegaran Terraform harus dimulai. Penyegaran Terraform melakukan hal tersebut, sehingga statusnya sesuai dengan infrastruktur sebenarnya.
Dan saya harus katakan tentang keamanan. Di sinilah seharusnya hal itu dimulai. Saat Anda menjalankan Terraform dan Terraform berfungsi dengan infrastruktur Anda, terdapat kerentanan. Artinya, Anda pada dasarnya mengeksekusi kode. Dan jika permintaan penarikan berisi beberapa jenis kode berbahaya, maka permintaan tersebut dapat dieksekusi pada infrastruktur yang memiliki terlalu banyak akses. Oleh karena itu, berhati-hatilah saat Anda meluncurkan paket Terraform.
Hal berikutnya yang ingin saya bicarakan adalah pengujian data pengguna.
Apa itu data pengguna? Di Amazon, saat kita membuat sebuah instance, kita dapat mengirim surat tertentu dengan instance tersebut - meta data. Saat instance dimulai, biasanya cloud init selalu ada pada instance tersebut. Cloud init membaca surat ini dan berkata: “Oke, hari ini saya adalah penyeimbang beban.” Dan sesuai dengan perjanjian ini dia melakukan beberapa tindakan.
Namun sayangnya, saat kami menjalankan rencana Terraform dan menerapkan Terraform, data pengguna tampak seperti angka-angka yang tidak jelas. Artinya, dia baru saja mengirimi Anda hash. Dan yang bisa Anda lihat di rencananya adalah apakah akan ada perubahan atau hashnya akan tetap sama.
Dan jika Anda tidak memperhatikan hal ini, maka beberapa file teks usang mungkin masuk ke Amazon, ke infrastruktur sebenarnya.
Alternatifnya, Anda tidak dapat menentukan seluruh infrastruktur selama eksekusi, tetapi hanya templatenya. Dan di dalam kodenya, ucapkan: "Tolong tampilkan template ini untuk saya." Hasilnya, Anda bisa mendapatkan cetakan seperti apa data Anda di Amazon.
Pilihan lainnya adalah menggunakan modul untuk menghasilkan data pengguna. Anda akan menerapkan modul ini. Dapatkan file di disk. Bandingkan dengan referensi. Jadi, jika beberapa Juni memutuskan untuk memperbaiki sedikit data pengguna, pengujian Anda akan mengatakan: "Oke, ada beberapa perubahan di sana-sini - ini normal."
Hal berikutnya yang ingin saya bicarakan adalah penerapan Automate Terraform.
Tentu saja, penerapan Terraform dalam mode otomatis cukup menakutkan, karena siapa yang tahu perubahan apa yang terjadi di sana dan seberapa merugikannya hal tersebut terhadap infrastruktur kehidupan.
Untuk lingkungan pengujian, semuanya baik-baik saja. Artinya, pekerjaan yang menciptakan lingkungan pengujian adalah apa yang dibutuhkan semua pengembang. Dan ungkapan seperti "semuanya berhasil untuk saya" bukanlah meme yang lucu, tetapi bukti bahwa seseorang menjadi bingung, mengangkat tumpukan, meluncurkan beberapa tes pada tumpukan ini. Dan dia memastikan semuanya baik-baik saja di sana dan berkata: "Oke, kode yang saya rilis telah diuji."
Dalam produksi, sandbox, dan lingkungan lain yang lebih penting bagi bisnis, aman untuk menggunakan sebagian sumber daya karena tidak menyebabkan kematian siapa pun. Ini adalah: grup skala otomatis, grup keamanan, peran, rute53 dan daftarnya bisa sangat banyak. Namun perhatikan apa yang terjadi, baca laporan aplikasi otomatis.
Jika penggunaannya berbahaya atau menakutkan, misalnya jika ini adalah sumber daya yang persisten, dari database, maka dapatkan laporan bahwa ada perubahan yang belum diterapkan di beberapa bagian infrastruktur. Dan insinyur tersebut sudah diawasi menjalankan pekerjaan untuk melamar atau melakukannya dari konsolnya.
Amazon memiliki yang namanya Hentikan perlindungan. Dan dalam beberapa kasus, ini dapat melindungi dari perubahan yang tidak Anda perlukan. Jadi Terraform pergi ke Amazon dan berkata, "Saya harus mematikan instance ini untuk membuat instance lain". Dan Amazon berkata, “Maaf, tidak hari ini. Kami memiliki perlindungan Pengakhiran.”
Dan yang terpenting adalah optimasi kode. Saat kita bekerja dengan kode Terraform, kita harus meneruskan sejumlah besar parameter ke modul. Ini adalah parameter yang diperlukan untuk membuat beberapa jenis sumber daya. Dan kode tersebut berubah menjadi daftar besar parameter yang perlu diteruskan dari modul ke modul, dari modul ke modul, terutama jika modul tersebut bersarang.
Dan sangat sulit untuk membacanya. Sangat sulit untuk meninjau hal ini. Dan sering kali ternyata beberapa parameter sedang ditinjau dan ternyata tidak sesuai dengan kebutuhan. Dan ini membutuhkan waktu dan uang untuk memperbaikinya nanti.
Oleh karena itu, saya sarankan Anda menggunakan parameter kompleks yang mencakup pohon nilai tertentu. Artinya, Anda memerlukan semacam folder tempat Anda memiliki semua nilai yang ingin Anda miliki di lingkungan tertentu.
Dan dengan memanggil modul ini, Anda bisa mendapatkan pohon yang dihasilkan dalam satu modul umum, yaitu dalam modul umum yang berfungsi sama untuk seluruh infrastruktur.
Dalam modul ini, Anda dapat melakukan beberapa perhitungan menggunakan fitur baru di Terraform seperti penduduk lokal. Dan kemudian dalam satu keluaran, keluarkan beberapa jenis parameter kompleks, yang mungkin mencakup hash, array, dll.
Di sinilah semua penemuan terbaik saya berakhir. Dan saya ingin bercerita tentang Colombus. Ketika dia mencari uang untuk ekspedisinya menemukan India (seperti yang dia pikirkan saat itu), tidak ada yang mempercayainya dan percaya bahwa hal itu tidak mungkin. Lalu dia berkata: “Pastikan telurnya tidak jatuh.” Semua bankir, yang sangat kaya dan mungkin orang pintar, mencoba mengambil risiko dengan cara tertentu, dan hasilnya selalu gagal. Lalu Colombus mengambil telur itu dan menekannya sedikit. Cangkangnya kusut dan telurnya tetap tidak bergerak. Mereka berkata, "Oh, itu terlalu mudah!" Dan Columbus menjawab: “Ya, ini terlalu sederhana. Dan ketika saya membuka India, semua orang akan menggunakan jalur perdagangan ini.”
Dan apa yang baru saja saya sampaikan kepada Anda mungkin merupakan hal yang cukup sederhana dan sepele. Dan ketika Anda mengetahuinya dan mulai menggunakannya, itu sesuai urutannya. Jadi gunakanlah. Dan jika ini merupakan hal yang wajar bagi Anda, maka setidaknya Anda tahu cara menaruh telur agar tidak jatuh.
Mari kita meringkas:
- Cobalah untuk menghindari kepingan salju. Dan semakin sedikit kepingan salju, semakin sedikit sumber daya yang Anda perlukan untuk melakukan perubahan pada seluruh infrastruktur besar Anda.
- Perubahan yang konstan. Artinya, ketika beberapa perubahan terjadi pada kode, Anda perlu membuat infrastruktur Anda mematuhi perubahan tersebut secepat mungkin. Seharusnya tidak ada situasi di mana seseorang datang untuk melihat Elasticsearch dua atau tiga bulan kemudian, membuat rencana Terraform, dan ada banyak perubahan yang tidak dia duga. Dan butuh banyak waktu untuk mengembalikan semuanya ke keadaan semula.
- Tes dan otomatisasi. Semakin banyak kode yang Anda bahas dengan pengujian dan fitur, semakin besar keyakinan Anda bahwa Anda melakukan semuanya dengan benar. Dan pengiriman otomatis akan meningkatkan kepercayaan diri Anda berkali-kali lipat.
- Kode untuk lingkungan pengujian dan produksi harus hampir sama. Praktisnya, karena produksinya sedikit berbeda dan masih ada beberapa nuansa yang melampaui lingkungan pengujian. Namun demikian, plus minusnya bisa diberikan.
- Dan jika Anda memiliki banyak kode Terraform dan memerlukan banyak waktu untuk selalu memperbarui kode ini, maka tidak ada kata terlambat untuk melakukan refaktorisasi dan menjadikannya dalam kondisi yang baik.
- infrastruktur yang tidak dapat diubah. Pengiriman AMI sesuai jadwal.
- Struktur untuk rute53 ketika Anda memiliki banyak entri dan ingin agar entri tersebut berada dalam urutan yang konsisten.
- Melawan batasan tingkat API. Saat itulah Amazon berkata, "Itu saja, saya tidak dapat menerima permintaan apa pun lagi, harap tunggu." Dan separuh dari kantor sedang menunggu hingga infrastrukturnya dapat diluncurkan.
- contoh tempat. Amazon bukanlah acara yang murah dan tempat memungkinkan Anda menghemat cukup banyak. Dan di sana Anda dapat menceritakan keseluruhan laporan tentang hal itu.
- Peran keamanan dan IAM.
- Cari sumber daya yang hilang, ketika Anda memiliki contoh yang tidak diketahui asalnya di Amazone, mereka memakan uang. Meskipun biaya instansnya $100-150 per bulan, biayanya lebih dari $1 per tahun. Menemukan sumber daya tersebut adalah bisnis yang menguntungkan.
- Dan contoh yang dipesan.
Itu saja untukku. Terraform sangat keren, gunakanlah. Terima kasih!
pertanyaan
Terima kasih atas laporannya! Anda memiliki file status di S3, tetapi bagaimana Anda mengatasi masalah di mana beberapa orang dapat mengambil file status ini dan mencoba menyebarkannya?
Pertama, kami tidak terburu-buru. Kedua, ada tanda di mana kami melaporkan bahwa kami sedang mengerjakan beberapa bagian kode. Artinya, meski infrastrukturnya sangat luas, bukan berarti ada yang terus-menerus menggunakan sesuatu. Dan ketika ada fase aktif, ini masalah, kami menyimpan file status di Git. Ini penting, jika tidak, seseorang akan membuat file negara, dan kami harus mengumpulkannya secara manual untuk melanjutkan lebih jauh. Sekarang tidak ada masalah seperti itu. Secara umum, Terraform memecahkan masalah ini. Dan jika sesuatu terus berubah, Anda dapat menggunakan kunci yang mencegah apa yang Anda katakan.
Apakah Anda menggunakan open source atau perusahaan?
Tidak ada perusahaan, yaitu segala sesuatu yang dapat Anda buka dan unduh secara gratis.
Nama saya Stanislav. Saya ingin membuat sedikit tambahan. Anda berbicara tentang fitur Amazon yang memungkinkan Anda membuat sebuah instance tidak dapat dibunuh. Ini juga ada di Terraform sendiri, di blok Life Second, Anda dapat menentukan larangan perubahan, atau larangan penghancuran.
Terbatas dalam waktu. Poin bagus.
Saya juga ingin menanyakan dua hal. Pertama, Anda berbicara tentang pengujian. Apakah Anda menggunakan alat pengujian? Saya mendengar tentang plugin Test Kitchen. Mungkin ada hal lain. Dan saya juga ingin bertanya tentang Nilai-Nilai Lokal. Apa perbedaan mendasarnya dengan Variabel Input? Dan mengapa saya tidak bisa membuat parameter sesuatu hanya melalui Nilai Lokal? Saya mencoba memahami topik ini, tetapi entah bagaimana saya sendiri tidak dapat memahaminya.
Kita bisa berbicara lebih detail di balik aula ini. Alat pengujian kami lengkap buatan sendiri. Tidak ada yang perlu diuji di sana. Secara umum, ada opsi ketika pengujian otomatis meningkatkan infrastruktur di suatu tempat, memeriksa apakah semuanya baik-baik saja, dan kemudian menghancurkan semuanya dengan laporan bahwa infrastruktur Anda masih dalam kondisi baik. Kami tidak memilikinya karena tumpukan pengujian dijalankan setiap hari. Dan itu sudah cukup. Dan jika ada sesuatu yang mulai rusak, maka ia akan mulai rusak tanpa kita memeriksanya di tempat lain.
Soal Nilai Lokal, mari kita lanjutkan pembicaraan di luar audiensi.
Halo! Terima kasih atas laporannya! Sangat informatif. Anda mengatakan bahwa Anda memiliki banyak jenis kode yang sama untuk menggambarkan infrastruktur. Sudahkah Anda mempertimbangkan untuk membuat kode ini?
Pertanyaan bagus, terima kasih! Intinya adalah ketika kita menggunakan infrastruktur sebagai kode, kita berasumsi bahwa kita melihat kode tersebut dan memahami jenis infrastruktur apa yang ada di balik kode ini. Jika kode tersebut dihasilkan, maka kita perlu membayangkan kode apa yang akan dihasilkan agar dapat memahami infrastruktur seperti apa yang akan ada di sana. Atau kita membuat kodenya, mengkomitnya dan, faktanya, kita mendapatkan hal yang sama. Oleh karena itu, kami mengikuti cara kami menulis, kami mengerti. Ditambah lagi, generator muncul beberapa saat kemudian, ketika kami mulai membuat. Dan sudah terlambat untuk berubah.
Pernahkah Anda mendengar sesuatu tentang jsonnet?
Нет.
Lihat, ini barang yang sangat keren. Saya melihat kasus khusus di mana Anda dapat menerapkannya dan menghasilkan struktur data.
Generator bagus jika Anda memilikinya, seperti dalam lelucon tentang mesin cukur. Artinya, pada awalnya wajahnya berbeda, tetapi kemudian setiap orang mempunyai wajah yang sama. Generatornya sangat keren. Tapi sayangnya wajah kami sedikit berbeda. Ini masalah.
Hanya melihat. Terima kasih!
Nama saya Maxim, saya dari Bank Tabungan. Anda mengatakan sedikit bahwa Anda mencoba membawa Terraform ke analogi bahasa pemrograman. Bukankah lebih mudah menggunakan Ansible?
Ini adalah hal yang sangat berbeda. Ansible dapat membuat sumber daya, dan Puppet dapat membuat sumber daya di Amazon. Tapi Terraform benar-benar diasah.
Apakah Anda hanya memiliki Amazon?
Bukan berarti kita hanya punya Amazon. Kami hampir hanya memiliki Amazon. Namun fitur utamanya adalah Terraform mengingatnya. Di Ansible, jika Anda mengatakan: "Jemput saya 5 contoh", maka itu akan meningkat, dan kemudian Anda berkata: "Dan sekarang saya perlu 3". Dan Terraform akan berkata: “Oke, saya akan membunuh 2”, dan Ansible akan berkata: “Oke, ini 3 untuk Anda.” Jumlah 8.
Halo! Terima kasih atas laporan Anda! Sangat menarik mendengar tentang Terraform. Saya hanya ingin memberikan komentar kecil tentang fakta bahwa Terraform masih belum memiliki rilis stabil, jadi berhati-hatilah dengan Terraform.
Sendok yang bagus untuk makan malam. Artinya, jika Anda membutuhkan solusi, terkadang Anda menunda apa yang tidak stabil, dll, tetapi itu berhasil dan membantu kami.
Pertanyaannya adalah ini. Anda menggunakan backend jarak jauh, Anda menggunakan S 3. Mengapa Anda tidak menggunakan backend resmi?
Resmi?
Awan Terraform.
Kapan dia muncul?
4 bulan yang lalu.
Jika itu muncul 4 tahun yang lalu, mungkin saya akan menjawab pertanyaan Anda.
Sudah ada fungsi dan kunci bawaan, dan Anda dapat menyimpan file negara. Cobalah. Tapi saya juga belum mengujinya.
Kami bepergian dengan kereta api besar yang bergerak dengan kecepatan tinggi. Dan Anda tidak bisa hanya mengambil beberapa mobil dan membuangnya.
Anda berbicara tentang kepingan salju, mengapa Anda tidak menggunakan cabang? Mengapa hal itu tidak berhasil?
Kami memiliki pendekatan sedemikian rupa sehingga seluruh infrastruktur berada dalam satu repositori. Terraform, Puppet, semua skrip yang berhubungan dengan ini, semuanya ada dalam satu repositori. Dengan cara ini kami dapat memastikan bahwa perubahan bertahap diuji satu per satu. Jika itu adalah sekumpulan cabang, maka proyek seperti itu hampir mustahil untuk dipertahankan. Enam bulan berlalu, dan mereka sangat berbeda sehingga itu hanya semacam hukuman. Inilah yang ingin saya hindari sebelum melakukan refactoring.
yaitu tidak berhasil?
Itu tidak berhasil sama sekali.
Di cabang saya memotong folder slide. Artinya, jika Anda melakukan untuk setiap tumpukan tes, misalnya tim A punya ayahnya sendiri, tim B punya ayahnya sendiri, maka ini juga tidak berhasil. Kami membuat kode lingkungan pengujian terpadu yang cukup fleksibel untuk disesuaikan dengan semua orang. Artinya, kami menyajikan satu kode.
Halo! Namaku Yura! Terima kasih atas laporannya! Pertanyaan tentang modul. Anda mengatakan Anda menggunakan modul. Bagaimana Anda mengatasi masalah jika perubahan yang dilakukan pada satu modul tidak sesuai dengan perubahan orang lain? Entah bagaimana membuat versi modul atau mencoba menghadirkan keajaiban untuk memenuhi dua persyaratan?
Ini adalah masalah tumpukan salju yang besar. Inilah yang kita derita ketika perubahan kecil yang tidak disengaja dapat merusak sebagian infrastruktur. Dan itu baru akan terlihat setelah beberapa waktu lamanya.
Artinya, belum diputuskan?
Anda membuat modul universal. Hindari kepingan salju. Dan semuanya akan berhasil. Paruh kedua laporan ini membahas tentang cara menghindarinya.
Halo! Terima kasih atas laporannya! Saya ingin menjelaskan. Di balik layar ada tumpukan besar yang saya datangi. Bagaimana Wayang dan Distribusi Perannya Terintegrasi?
data pengguna.
Artinya, Anda baru saja mengeluarkan file tersebut dan menjalankannya?
Data pengguna adalah sebuah catatan, yaitu ketika kita membuat klon gambar, kemudian Daemon naik ke sana dan mencoba mencari tahu siapa dia, membaca catatan bahwa dia adalah penyeimbang beban.
Artinya, apakah ini semacam proses terpisah yang diberikan?
Kami tidak menciptakannya. Kami menggunakannya.
Halo! Saya hanya punya pertanyaan tentang Pengguna - data. Anda bilang ada masalah di sana, mungkin ada yang mengirim sesuatu ke tempat yang salah. Apakah ada cara untuk menyimpan data pengguna di Git yang sama, sehingga selalu jelas apa yang dimaksud dengan data Pengguna?
Kami menghasilkan data Pengguna dari templat. Artinya, sejumlah variabel tertentu ada di sana. Dan Terraform menghasilkan hasil akhir. Oleh karena itu, Anda tidak bisa hanya melihat template dan mengatakan apa yang terjadi, karena semua masalah terkait dengan fakta bahwa pengembang mengira dia meneruskan string ke variabel ini, dan kemudian array digunakan. Dan dia - bang dan saya - si anu, si anu, baris berikutnya, dan semuanya hancur. Jika ini adalah sumber daya baru dan seseorang memunculkannya, melihat ada sesuatu yang tidak berfungsi, maka ini akan segera diselesaikan. Dan jika grup skala otomatis ini telah diperbarui, maka suatu saat instance di grup skala otomatis mulai diganti. Dan tepuk tangan, ada sesuatu yang tidak berfungsi. Itu menyakitkan.
Ternyata satu-satunya solusi adalah dengan menguji?
Ya, Anda melihat masalahnya, Anda menambahkan langkah pengujian di sana. Artinya, keluarannya juga bisa diuji. Mungkin tidak begitu nyaman, tetapi Anda juga dapat memberi tanda - periksa apakah Data pengguna dipaku di sini.
Nama saya Timur. Sangat keren bahwa ada laporan tentang cara mengatur Terraform dengan benar.
Aku bahkan tidak memulainya.
Saya pikir pada konferensi berikutnya, mungkin akan ada. Saya punya sebuah pertanyaan sederhana. Mengapa Anda melakukan hardcoding nilai dalam modul terpisah daripada menggunakan tfvars, yaitu apakah modul dengan nilai lebih baik daripada tfvars ?
Artinya, saya harus menulis di sini (slide: Production/environment/settings.tf): domain = variabel, domain vpcnetwork, variabel vpcnetwork dan stvars - dapatkan hal yang sama?
Itulah tepatnya yang kami lakukan. Kami merujuk ke modul sumber pengaturan, misalnya.
Intinya, ini adalah tfvars tersebut. Tfvars sangat nyaman dalam lingkungan pengujian. Saya punya tfvars untuk instance besar, untuk instance kecil. Dan saya melemparkan satu file ke dalam folder tersebut. Dan saya mendapatkan apa yang saya inginkan. Ketika kita melihat infrastruktur, kita ingin bisa melihat dan langsung memahami semuanya. Jadi ternyata Anda perlu melihat ke sini, lalu melihat tfvars.
Ternyata semuanya ada di satu tempat?
Ya, tfvars adalah ketika Anda memiliki satu kode. Dan itu digunakan di beberapa tempat berbeda dengan nuansa berbeda. Kemudian Anda akan membuang tfvars dan mendapatkan nuansa Anda. Dan kami adalah infrastruktur sebagai kode dalam bentuknya yang paling murni. Melihat dan mengerti.
Halo! Pernahkah Anda menghadapi situasi di mana penyedia cloud mengganggu pembuatan Terraform Anda? Katakanlah kita mengedit metadata. Ada kunci ssh. Dan Google terus-menerus menempatkan metadata dan kuncinya di sana. Dan Terraform selalu menulis bahwa ada perubahan. Setelah setiap kali dijalankan, meskipun tidak ada perubahan, dia selalu mengatakan bahwa dia akan memperbarui bidang ini sekarang.
Dengan kunci, tapi - ya, bagian dari infrastruktur dipengaruhi oleh hal seperti itu, yaitu Terraform tidak dapat mengubah apa pun. Kita juga tidak bisa mengubah apa pun dengan tangan kita. Selama kita hidup bersamanya.
Artinya, Anda menemukan ini, tetapi tidak menemukan apa pun, bagaimana dia melakukannya dan melakukannya sendiri?
Sayangnya ya.
Halo! Nama saya Stanislav Starkov. Surat. id Grup. Bagaimana Anda memecahkan masalah dengan menghasilkan tag di ..., bagaimana Anda meneruskannya ke dalam? Seperti yang saya pahami, melalui Pengguna - data, untuk menentukan nama host, menghasut Wayang? Dan bagian kedua dari pertanyaan itu. Bagaimana Anda mengatasi masalah ini di SG, yaitu ketika Anda membuat SG, seratus instance dengan tipe yang sama, bagaimana cara memberi nama dengan benar?
Contoh-contoh yang sangat penting bagi kami, akan kami beri nama dengan indah. Yang tidak diperlukan, ada catatan tambahan bahwa ini adalah grup skala otomatis. Dan secara teori bisa dipaku, dan mendapat yang baru.
Sedangkan untuk masalah tag, tidak ada masalah seperti itu, tetapi ada tugas seperti itu. Dan kami sangat sering menggunakan tag, karena infrastrukturnya besar dan mahal. Dan kita perlu melihat untuk apa uang tersebut dibelanjakan, sehingga tag memungkinkan kita memilah untuk apa dan ke mana perginya uang tersebut. Dan karenanya, mencari sesuatu di sini menghabiskan banyak uang.
Pertanyaannya tentang apa lagi?
Ketika SG membuat seratus instance, apakah mereka perlu dibedakan?
Tidak, jangan. Setiap contoh memiliki agen yang memberi tahu saya bahwa saya mempunyai masalah. Jika agen melapor, maka agen tersebut mengetahui tentang dia dan, setidaknya, alamat IP-nya ada. Anda sudah bisa lari. Kedua, kami menggunakan Consul for Discovery, yang tidak memiliki Kubernetes. Dan Konsul juga menunjukkan alamat IP instance tersebut.
Artinya, Anda menargetkan IP secara tepat, dan bukan nama host?
Tidak mungkin untuk menavigasi berdasarkan nama host, yaitu ada banyak dari mereka. Ada pengidentifikasi instance - AE, dll. Anda dapat menemukannya di suatu tempat, Anda dapat memasukkannya ke dalam pencarian.
Halo! Saya menyadari bahwa Terraform adalah hal yang baik, disesuaikan dengan awan.
Tidak hanya
Pertanyaan inilah yang menarik minat saya. Jika Anda memutuskan untuk pindah, katakanlah, ke Bare Metal secara massal dengan semua instance Anda? Apakah akan ada masalah? Atau masih harus menggunakan produk lain, misalnya Ansible yang sama yang disebutkan di sini?
Ansible adalah sedikit tentang hal lain. Artinya, Ansible sudah berjalan ketika instance sudah dimulai. Dan Terraform berfungsi sebelum instance dimulai. Beralih ke Bare Metal tidak.
Tidak sekarang, tapi bisnis akan datang dan berkata: "Ayo."
Beralih ke cloud lain - ya, tetapi ada fitur yang sedikit berbeda di sini. Anda perlu menulis kode Terraform sedemikian rupa sehingga Anda dapat beralih ke cloud lain dengan lebih sedikit pertumpahan darah.
Awalnya, tugasnya adalah seluruh infrastruktur kami bersifat agnostik, yaitu cloud apa pun seharusnya baik-baik saja, tetapi pada titik tertentu bisnis tersebut menyerah dan berkata: “Oke, dalam N tahun ke depan kami tidak akan kemana-mana, Anda dapat menggunakan layanan dari Amazon".
Terraform memungkinkan Anda membuat pekerjaan Front-End, mengonfigurasi PagerDuty, dokumen data, dll. Ini memiliki banyak konsekuensi. Dia praktis bisa mengendalikan seluruh dunia.
Terima kasih atas laporannya! Saya juga telah memutar Terraform selama 4 tahun sekarang. Pada tahap transisi yang mulus ke Terraform, ke infrastruktur, ke deskripsi deklaratif, kami dihadapkan pada situasi di mana seseorang melakukan sesuatu dengan tangan, dan Anda mencoba membuat rencana. Dan saya mendapat beberapa kesalahan di sana. Bagaimana cara Anda mengatasi masalah seperti itu? Bagaimana Anda menemukan sumber daya yang hilang yang ditunjukkan?
Kebanyakan dengan tangan dan mata kita, jika kita melihat sesuatu yang aneh dalam laporan, maka kita menganalisis apa yang terjadi di sana, atau kita bunuh saja. Secara umum pull request merupakan hal yang lumrah.
Kalau ada error apakah bisa di rollback? Sudahkah Anda mencoba melakukan ini?
Tidak, ini adalah keputusan seseorang pada saat dia melihat masalahnya.
Sumber: www.habr.com